Denim Umeshkumar Anajwala

If the transverse dispersivity is relatively large compared to the layer thickness, the travel times may be significantly influenced by boundary effects (particles are reflected at model boundaries), while in the LTE model this fact only leads to perfect vertical mixing. This difference is the reason for the observed behavior in this very thin aquifer.

Hi Stefan,

The most likely reason for this is that the LTE isolines are based on a transport calculation, i.e., they include the effects of diffusion and dispersion. If the layers are relatively thin, the default transverse dispersivity will lead to a similar distribution of LTE in the different layers. You can test this by applying the random-walk method as well (=pathlines with dispersion). I'd expect that the result will be somewhat similar to the LTE isolines. Another reason could be that the aquitards consist in only one layer. LTE concentration then can also be passed through the aquitard more easily than realistic.

To know what the 'real' distribution is, you'll have to apply realistic values for dispersivity plus a subdivision of the aquitard(s). Note that using small values for dispersivity may require a fine discritization, especially in vertical direction, in order to obtain a stable transport solution. This is similar to a mass or heat transport simulation.

Cheers,
Peter

Hi there,

does anybody in here have experience with Feflow 6.2 in a 4k-monitor environment? Is Feflow usable in Win 8 with a highDPI-panel, or are Buttons, Fonts etc too small? Is the Windows 8 scaling factor helpful for that issue? Any thoughts / experience welcome!

I am thinking about getting a 4k Display, but before want to know if that high Resolution is fine for using Feflow.

Thanks!!

In such a case, you'd set up two species: One in the fluid phase, one in the solid phase, and then define a reaction between them. One application of this could be non-equilibrium sorption.

It looks as if you start the model at 0m hydraulic head for some of the observation wells, while the observed values are much larger. There the initial condition does not seem appropriate. The second steep rising of the head in your diagrams actually leads to approximately correct values. Is this rise also caused by too low initial conditions, e.g., by water flowing in from a boundary?
In case you don't have better initial conditions, it may help to do a steady-state run first to obtain good initials, or to have a longer warm-up period.

Soon = in the next couple of months. Can't be more specific now as some things have to be sorted out still.

Zeno,

You can assign the temperature difference as a temperature differential or a power (time-constant or time-varying). It is not possible, however, to input a function. In older FEFLOW versions the user interface only allowed for a fixed/variable inlet temperature. For these, there is a free plug-in that provides the possibility to apply a temperature differential. To apply a specific function, you'd have to develop your own plug-in.

Ciao,
Peter

There are no strict limits on the polygon size or mesh items. However, a polygon needs to be suitable for generating a mesh. I recommend to check the polygon for vertices that are very close to each other. Typically those lead to problems in mesh generation as the algorithm will have to put mesh nodes at all polygon vertices. You  may also check if the polygon contains a very large number of not necessary vertices, e.g., along straight sections of the polygon border. These would also lead to a large number of mesh nodes along this border and can finally cause the mesh generator algorithm to fail.

Hi Guiseppe,

This sometimes happens in case of a relatively large abstraction for a single well. You probably see an overshoot of head values at the nodes around the well nodes - on regional scale then everything is OK again. The reason for this is in the default handling of storage, that involves the neighboring nodes. To fulfill the required steep gradient towards the extraction nodes, the solution then generates a higher water level at the surrounding nodes. You can try to switch to 'Lumped Mass' on the 'Numerical Parameters' page of the 'Problem Settings' dialog to overcome the problem.

Good luck!
Peter

... and then just use  'Save as' and choose .fem as the format.