mnovotny

http://feflow.info/forum/index.php/topic,393.0.html

may help.

The specific issue discussed above should not be present in the free and moveable mesh solution, it is specific to the phreatic and unsaturated solution.

Though in the same principle, the model is probably mounding water because the system requires a higher gradient to transmit the recharge specified.  If you are using the free and moveable mesh then this suggests that the model is uncalibrated because recharge is too high or conductivity is too low or constant head too high.

HOWEVER...there are some issues specific to FEFLOW where constrained boundary conditions will 'flip' and change type when the constraint is not satisfied.

I can't speak to your 'net inflow' issue.

FEFLOW tech support felt this problem might be due to not having write permission on a specific drive where the data is being stored.  I have not been able to confirm this and I am not using 5.4 to reproduce error.

Also Gemma,
CPUs with various levels of cache are usually much faster.  For example an older 2.5GHz processor with little or no cache may be slower than a new 1.5GHz processor with 3 levels of cache.
The best way to know a computers performance is to benchmark it - run the same model on each and clock it.
Milos
SWS-Denver

Loic,
this sounds suspiciously like a problem I have encountered with recharge boundary condition.  Do you have recharge specified and is your model in unconfined mode?
Milos
SWS-Denver

The coworker was running 5.4 when the data was not being read.  She tried on another machine with 5.3, and was prompted to enter a location for time dependent material data (This seems to be the norm even if data is stored in the .fem file).  I instructed her to point the location to a dummy .pow file.  After she did this the simulation ran correctly in 5.3. 

This sounds like a bug in 5.4 where time dependent material data stored in the .fem file from the older 5.3 version is being read in the viewer but not during the simulation execution.

I have completed a model with time dependent material data (conductivity) and a remote coworker is having problems running the model on her machine.  It appears the data is not read during the actual simulation, and FEFLOW is instead reading the data that is not time-dependent (Non time-dependent data was set to '999').  However she is able to see the TLIST data existing in the problem editor.

The data is stored in the fem file, not a separate binary file.

Is there a setting selection she needs to make somewhere on her machine in order to read the time dependent data?

This isn't answering your question necessarily, but I like to imagine the discrete features as a secondary model domain.  The primary (elemental) and secondary (discrete) domains will have the same values of head and fluid flux at the nodes, but use different laws and properties to define flow between the nodes.

A vertical fracture, as you have described, will 'connect' the 4 nodes on the vertical face of an element (assuming in 3D), with properties specified by you, but depending upon what law you are using to describe the flow.  For Darcy, it is conductivity, thickness (aperture), etc.

I know there was a bug addressed in one of the FEFLOW patches recently, a bug that caused FEFLOW to crash after the file was saved several times.

There still appears to be an issue here.  I am finding that the reference distribution dataset is being replaced with some default (-9.999900e4) value after several saves.  Please see attached figure. 

Hi, I am re-posting this question as a new topic...

Am I correct in my understanding that in the phreatic mode the overall conductivity, including that in the z-direction, is scaled by the saturation or, at a minimum, the residual water depth?

I have had the experience that recharge (applied as inflow) seems to become trapped at the top of the aquifer if the layers below are dry, resulting in unrealistically high (10e8!) heads, and that this would occur if Kz were similarly scaled. 

The same model run in confined mode results in realistic head values.

Thanks!
Milos