View Full Version : Precision of H2ONET demands

February 21, 2014, 09:29 AM
My question is regarding H2ONET when editing the junction demands in the db editor. Generally when I enter demands I want to do so to at least one decimal place. H2ONET seems to allow this by changing the precision on the editor. However, when the db editor is closed and reopened everything is rounded to an integer. Also, all the demands are shown as an integer when the demands are selected individually.

After some exploring, it appears that even though the demands show as an integer, they are being treated to the precision entered. This is good except for the fact that the field statistics in the db editor can be misleading if the user does not know to change the precision before calculating the field statistics (the field statistics just sum everything up at the precision shown).

Is there any way to set the default precision in the db editor and for what is shown when the junctions are selected individually?

I have H2ONET 12.0 Update #5.

Shawn Huang
February 21, 2014, 11:17 AM
Go to Preferences, then click Display Settings, you will see the option to change decimal place.
The Statistics in the db editor is just based the numbers displayed in the table, which is affected by decimal place.

February 21, 2014, 11:25 AM
That worked perfectly. Thanks Shawn.

Patrick Moore
July 16, 2015, 03:23 PM

Although the software generally defaults to using 2 decimal places, it is often a good idea to increase the decimal places to 4 if you are performing scaling of the demands by using the block editing feature and the multiplier or divide all by feature. Whenever I keep results at 2 decimal places I would find that there would be some apparent "error" in the demand totals after multiplying that was simply due to the rounding error associated with the field statistics totals when calculating a multiplier.

However if I first changed to 4 decimal places , ran field statistics to get the total demand to calculate the multiplier (new demand total / old demand total = multiplier) and then multiplied by that value the demands were always accurate to three decimal places which would make my two decimal places I cared about right on the money.

Until I figured that out a few years back, I had a hard time getting much better than 1 place decimal accuracy and was often frustrated when totals were not matching.

For the last few years I have general just run models with 4 decimal place accuracy and found that I could pretty much guarantee results to 2 decimal places were almost always exact.

Pat Moore