WUFI 2D Rain Iteration vs. Driving Rain vs. Dws/r

[Bakonyi Daniel]

Dear WUFI staff,

I am working with a student on analyzing some WUFI 2D calculations and we encountered a phenomena we don't get. As we understand WUFI switches from Dwr to Dws (redistribution to suction) when there is some rain load, and it does so for all materials regardless whether it is in contact with the rain or not. During a rain event WUFI also performs an extra rain iteration loop to make sure the exposed surface does not suck up more rain than there is available by reducing the Dws on the surface if needed.

Our construction is a very simple wall with ETICS (effectively 1D for now with adiabatic bcs top and bottom and the mesh reduced to minimum in the y direction). The construction has an outer plaster layer exposed to rain, mineral wool insulation, and a concrete inner layer. Both the plaster and the concrete material (C35/45) has a much higher Dws (compared to their Dwr), as expected. There are no sources defined.

The phenomenon is as follows: during the simulation the concrete wall is gradually drying compared to the initial condition (fi0 = 0.8 ). For the concrete (C35/40) material capillary conduction plays a large role in this. When there is a rain event (timestep) WUFI switches Dwr to Dws in the concrete layer too (the difference is 2 orders of magnitude), so there is a sudden very large increase in the capillary flux in the concrete layer (as measured in its middle), but only for the duration of the rain. This is not strictly physical, as in this case the Mineral Wool is not capillary conductive and it decouples the wall from the plaster an the rain, but we understand that this is how WUFI is supposed to work. As a result, however, the number of rain events effects the moisture balance of the concrete layer. The more rain events there are, the longer is Dws used instead of Dwr, the quicker it dries out.

What we don't understand is the number of such events. We have parsed the preprocessed binary .bcli file for the outer boundary condition WUFI used for the simulation, and we also compared it to our own calculation for the driving rain load (they match perfectly). We can count 403 timesteps when the driving rain load is non-zero (for a single year). But when we look at the convergence analyzer WUFI only performed / or reported (?) 57 rain iterations. Looking at the capillary flux density plot in the concrete layer we can see the same number of 57 spikes: WUFI switching from Dwr to Dwr for the timestep increasing the capillary flux for exactly 57 timesteps.

Why did WUFI not perform a rain iteration for the rest of the 346 rain events (timesteps with a non-zero rain load)? Or is a rain iteration only necessary when the suction would otherwise be larger than the rain load? Or is there a cutoff for the smallest rain load?

Is the modification of Dws during a rain iteration strictly limited to the boundary cells?

Why is Dws not switched to Dwr for the rest of the 346 rain events in the concrete layer? Is there a connection between the rain iteration and the switch in Dw functions?

We ran the same simulation by modifying the C35/45 concrete so its Dws function matches its Dwr (bypassing the phenomena). The difference in the total water content (and the water content in the concrete layer) was significant compared to the original case (it dries slower). So how often the Dw function is switched (in the original case) does effect the result. Once again, we understand that this is a somewhat unphysical limitation of WUFI, but we don't get the exact number and nature of these events. Is this perhaps a bug or an undocumented feature?

Thank you in advance!

Daniel

[Christian Bludau]

Dear Daniel,
I could imagine that this is related to the output of the residuals in the iter.txt. Did you try to reduce the modulo to 1 for each step?

Code: Select all

Computational Parameters -> Enhanced -> Print residuals at iteration modulo

Please note: this might end in an "out of memory error" - If so, try a batch calculation.
Christian