PC-Progress Discussion Forums

Gentlemen,

I am using HYDRUS-1D (thanks for the improvements!) to estimate daily net infiltration rates (either + or -) at ground surface using daily precip and PE rates via the atmospheric boundary condition (0 surface layer and precip rates are too low to generate runoff). The results are to be used as inputs to a 3D variably-saturated model that does not offer an atmospheric boundary condition, but will use the same 60 year sequence of daily precip and PE values.

My first approach was to use the sum(vTop), sum(vBot), and Storage values, as presented in the T-Level.out file, to estimate a change in vTop, vBot, and Storage for each day. That is, I assumed that the change in Storage between day i and day i-1 = vTop(i) + vBot(i), all of which can be calculated from the T-Level.out rows corresponding to days i and i-1. However, I found that the discrepancies between the change in Storage and the incremnetal fluxes through the top and bottom boundaries between day i and i-1 are often 1-4% and can reach 12-38%, depending on the hydraulic properties used. The Balance.out WatBalR entries for those days are routinely < 0.01% and I believe spatial and temporal discretization are more than adequate. Why do the change in storage and change in influx+outflux, calculated for each day, differ by so much more (0.5-38%) than the WatBalR values (<0.01%) for the same days?

Another approach is to use the top flux entry from a Balance.out report for each day. However, I noticed the top flux for day i in the Balance.out is usually significantly less than the difference in sum(vTop) for days i and i-1 except after several continuous days of no rain (only evap). The disparities are greatest for rainy days and the drying days immediately following the precip events.

I am puzzled by these disparities in water mass fluxes between the T-Level.out and the Balance.out files. I shall be very grateful for your advice about which, if any, of these estimates I should use to specify net infiltration at the surface.

Thanks and regards,
John Sigda, Ph.D.

John,

WatBalT and WatBalR are calculated from the sum(vTop), sum(vBot), and sum(vRoot) internally in the program. Thus I do not see how there could be large differences in values you calculated and those reported. Except that these values are printed into t_Level.out only with a certain precision (only several valid numbers, not full float precision), and WatBal values are for the entire calculation period. Note that vTop or vBot values are not the average values for some time period, but actual values at a particular time. There can obviously be different values recorded during a particular time interval than at the end of that interval. This is obviously taken into account internally by the code.

Jirka

Water Balance Calculations

I’m trying to understand how the outputs in the BALANCE.OUT (B), ATMO.OUT (A) and T_LEVEL.OUT (T) files map to the water balance computation equations in the HYDRUS 1D Manual. The reason for doing this is that I would like to aggregate the model variables to different timescales.

Question: How can I calculate the Mass Balance Error from the Balance OUT and T_Level files? I am more interested in understanding the T_Level. (This echoes a question posted by John Sigda Jun 30, 2005 but after reading the reply, I was still not clear)

The picture below shows my understanding of the output files and possible ways to calculate the water mass balance. (I’m writing this out in greater detail, in case it may help others as I have found many of the questions on the forum useful when explained in detail.) For simplicity, there is no transpiration (only Bare Soil Evaporation). The manual equation for the mass balance error (without transpiration) is as follows, which means it’s a cumulative error from time 0 to time t.

WatBalT=V_t-V_0-∫_0^t▒〖(q_o 〗-q_n) dt
where Vt and V0 are the volumes of water in the flow domain and the integral is the net cumulative flux through both boundaries.


For the T_Level.OUT files I started with the cumulative values. These values are reported at variable time steps. I want the monthly aggregation so I differenced the cumulative values at the appropriate times to find the aggregated monthly fluxes. In other words, the cumulatives serve as the integral of the flux and I extract an approximate area under the integral for the timespan that I am interested in (daily, weekly, monthly, etc).

T_Level.OUT variables used: sum(RunOff) Cumulative surface runoff [L]
, sum(Evap) Cumulative evaporation [L]
, Volume Volume of water in the entire flow domain [L]., sum(vBot) Cumulative value of the actual flux across the bottom of the soil profile [L] (inflow/outflow: +/-). Also used ATMO.OUT Prec.

I attempted the mass balance as:
dt = 1 month;
dvdt = P_monthly-E_monthly-Q_monthly+R_monthly

where P is Precipitation, E is evaporation, Q is Runoff and R is bottom flux/recharge. Calculating the difference between the LHS and RHS of the mass balance, the errors are large (~30% of Precip).
I’ve confirmed that vTop = Evaporation (E)-Infiltrtion (I). (at any timescale- weekly, monthly)
But Infiltration is not equal to P-E-Q….why?!
Even if I use the following mass balance: I_monthly – E_monthly + R_monthly = dvdt. I get large errors. This is equivalent to using vTop_monthly-vBot_monthly = dvdt_monthly which should match the manual.
I suspect something is wrong with my understanding of the variables or the approach. Is it possible to compare any of these to the reported WBalT Error from Hydrus? Any advice is greatly appreciated.

Here is a picture of the LHS and RHS of the mass balance and the absolute errors. ////-------------------------------
I also tried using the Using BALANCE.OUT variables, I used:
time – printing times (every 30.5 days (~monthly))
W-Volume: Volume of water in the entire flow domain or in a specified subregion [L].
Top Flux: Actual surface flux [LT-1] (infiltration/evaporation: -/+).
Bot Flux: Actual flux across the bottom of the soil profile [LT-1] (inflow/outflow: +/-).
WatBalT Absolute error in the water mass balance of the entire flow domain [L].

To calculate the mass balance error using the BALANCE.OUT files, I tried the following:
IN = (abs(B.TopFlux).*(B.TopFlux<0)) + (abs(B.BotFlux).*(B.BotFlux>0)); %[mm/d]
OUT = (abs(B.TopFlux).*(B.TopFlux>0)) + (abs(B.BotFlux).*(B.BotFlux<0)); %[mm/d]
NET_Flux = (IN-OUT) %[mm/d] at the instant
Dt = 30.5; % days
DvDt = diff(B.Wvol1)/Dt % [mm/d]
Err = DvDt - NET_Flux(2:13) % [mm/d]

DvDt is quite close to zero, but NET_FLUX is very large. Consequently my absolute error is too large, and not comparable to the internal Hydrus calculation. Any advice on how to use the reported variables to calculate the mass balance would be helpful (particularly the T_Level data).


Thanks,
Anjuli

I am teaching this week a three-day HYDRUS course (with Rien van Genuchten) and a two-day HP1 course (with Diederik Jacque) in Prague. As a result, I will likely not have time to look at this (long) posting until I get back to Riverside. Anyone else is welcomed to answer it.

However, the approach should be simply as follows. The mass balance equation is:
Change is storage = sum of cumulative fluxes (surface (P, E, T, R) and bottom fluxes). It is important to use actual fluxes (for evaporation, transpiration, etc), not potential fluxes.

Change in storage can be obtained from the Balance.out file (at the initial and final time).
All cumulative fluxes are printed into the T_Level.out file.

J.

Dear Jirka,

Thanks for the reply. If anyone else gets a moment or whenever you get a chance, I appreciate your time. My question can boil down quite simply to the definition of infiltration. For my one year run, the annual infiltration exceeds the annual precipitation. This is why my balance with P does not work. When I ran some checks at the annual scale (1st and last lines of the TLevel.OUT file), I can confirm the balance Hydrus performs with vBot-vTop = dV. (I get close to the same value Hydrus reports in WatBalT). I can also confirm that vTop is Infiltration - Evaporation. I use the cumulatives and the actuals (not potentials) for all the calculations.

When I want to bring precipitation into the picture, I have problems. This balance does not work for me: dV = Precip-Evap+vBot-Runoff. I expect it should have been the same as those above as I expected I = P-Q, but Infiltration (I) does not equal Precip (P)-Runoff (Q). What is more, annual infiltration is larger than annual precipitation. Any advice is greatly appreciated.

Thanks,
Anjui

Hello,

I understand the issue now. In the precipitation inputs (ATMOSPH file), the Prec values are specified only at the times when there is a change. When pulling out the values from the file, I was making the mistake of assuming the inputs were zero in the times in-between, but in fact it should be constant through those times. This means I was undercounting Precip compared to how Hydrus counts it. This accounts for the water in the Infiltration and makes all the balances work out.

Thanks for hosting the forum. It seems writing out the problem helped clarify my thoughts and arrive at the issue.

Thanks,
Anjuli

Good to hear that you have resolved the problem. I’m still at the short course in Prague (HYDRUS and HPx). J.

Hello,

I would like to know how to solve this issue in terms of water balance, because i am studying groundwater recharge and I need my water budget to fit with the real precipitation values and not the way Hydrus counts infiltration. I am comparing different weather data source input to see the effect on groudwater recharge and evapotranspiration flux...So the numbers needs to be correspond with meteorological values. Even if I have a WatBalt of 34 mm when I'm trying to calculate de water balance I have an error of 203 mm for 4 years simulation...

Would you recommend a particular way to enter the input precipitation data in the model to solve this issue? I am currently entering daily values of P et ETP.

Thanks and regards,
Sabrina

HYDRUS-1D reports in the Balance.out and T-Level.out files all values that you need to close te mass balance. From your questions, I do not understand what else you would need. J.