Mark Robertson

Partial Parallelization of the Lambda search doesn't appear to be active in FEPest under certain conditions.
I thought it worked previously when using super-parameters (which I am not currently using), but my recollection may be wrong.
Is this correct?  Can it be implemented?

The error bars which were evident in my model created in 7.0 do not show in 7.1?

Hi Peter,

Thank you for the clarification. 
My original query was about an apparent groundwater rise in the slice above the well boundary condition node.  Is this an artifact, which I can ignore, or should I be reducing the vertical element size?

Thanks,

Mark

Smaller elements doesn't necessarily result in more accuracy for a well node.  There should be a minimum element size below which the model over-estimates drawdown, just as a small diameter well will have a greater drawdown than a larger one, due to the smaller cylinder of surface area outside the bore that the water must flow through.

It would be helpful if there was more explanation about the 'ideal element size' and 'virtual radius'.

Mark

Hi Pete,

Thanks for the help.  When I use multi-layer well boundary conditions and select 'ideal element size' under attributes in the View Components Panel, Feflow draws a circle around the boundary node, which I am guessing is the size of the first ring of elements around the boundary condition node to be accurate. 

There was some discussion on this in another post, but it wasn't clear how to compare the elements to the 'ideal element size' circle.  It seems to be that if I match the 'virtual radius' circle to the actual bore casing diameter, the ideal element circle covered outside the nodes surrounding the BC, so in my example encapsulates 8 elements.

I previously used elements at wells so that there was nodes at the edges of the casing and one in the middle,  but this seemed to over-estimate the draw-down at the well, and the 'virtual radius' circle was smaller than the actual casing diameter.

Hi Pete,

Thanks for the help. 

The K (20m/d) and pumping rate (30L/s) are from typical site conditions, so I  can't change that.  I am using automatic time-steps.

If I split the model into 5 x 10m thick layers, I still get a water level rise in the slice above the pumping node(s).  For a larger regional model it may not be practical to use more layers. 

What I am concerned about it whether the water level at the pumping node is realistic?  The ideal element size (using the multlayer well boundary condition) is indicated to have a diameter of 1.6m, to match the 'virtual radius' circle to the size of my well (0.27m diameter).  I am not clear if I am doing that correctly.  It is called a radius, but I am assuming the circle shown is the diameter and the radius is half.  And for the 'ideal element size' is the circle meant to match the typical width of 1 element.  In my case to get the virtual radius circle to match the actual well diameter, the ideal element circle is approximately the width of 3 elements? 

Do I need to have the vertical size of the elements also matching the 'ideal element size'?

I have a similar issue,  When I apply a high yield well BC to the bottom slice of a 1 layer model, I get a increase in water level in the top slice near to the bore.  This also occurs in a 2 layer model where I use a multi-layer well over the lower two slices.  The inverted water table cone occurs in the top slice.  Further away the water levels in the top layer decline as expected. 
I changed to lumped mass, but that made no difference. 
I have attached a simple example.
I am wondering if this behaviour is normal, or is there a way to prevent this.
Thanks

I am modelling the filling of a lake/mine pit, as the watertable reaches the floor, I change the permeability and porosity to high values.
I don't worry about the porous media below the lake, as the high K and n of the lake control the behaviour.
Previously I have done this in two stages with two models, copying the head from the first to the second. 
I tried doing this in one model, using time varying K and porosity.  Changing the porosity appears to collapse the head to reflect the greater pore space to conserve water mass.  Is there a way to avoid this, by altering the water storage in the pore space by the correct amount to not change the hydraulic head?

Is there a way to export Flow-Rate and Flow-Volume Data for a defined domain of interest?

The patches are very large and the server is very slow (~60kb/s), so it takes up to 2 hours to download.  Often the download will crash and stop. 
Speed testing my service indicates 18Mb/s download, and I don't have troubles on any other sites, so I am thinking the problem is with the WASY server bandwidth or the overseas connection (I am in Australia).  Do others find the downloads slow?  Why do the patches have to be so big? Not really a patch, more like the full garment!  Are there mirror sites that can be used?