Alexander Renz

Indeed is is hard to say what the actual cause of the model, however if the only observations PEST can calibrate against are hydraulic heads, its likely that the predictive performance for fluxes is poor.
If you can exclude that the model itself is causing the problem (especially water balance), these would be my steps:"

Check the balance items of the water balance. If 60% of recharge is going to the tunnel, where do the remaining 40% go to? These are likely the creeks; if so, these probably show less discharge than you would observe in the fields. One solution would then be to use the discharge in the creeks as an additional observation to PEST.

When working with PEST keep in mind, that it sees the FEFLOW model as a black box. The only thing it does is changing the parameters until the observatiosn (hopefully) match the observed values. So if the only observations are heads, this is the only thing it optimizes. If you expect PEST to achieve reasonable water balance, defining budget items such as river discharge will tell PEST what this actually means.

Does this help?

Hi Anthony,

DHI has developed such a solution and we are happy to share it with interested MSHE/FEFLOW users.
It has been applied in projects already, however we can only provide it as-is at this time as it is not part of any official release/

You may find using the DFS API in IFM not straight forward because of the different languages (C#/.net vs C++), which makes it necessary to use a CLR approach.

cheers,
Alex

Hi Quinn,

You will find a convenient installer of all required PEST tools (PEST, PLPROC and the groundwater utilities) in the donwnload section on our website. If using this installer after the FEFLOW installation, the required file paths will be set automatically.

If you have downloaded and installed PEST from the official PEST homepage (www.pesthomepage.org), you can manually define the installation locations in FePEST under Tools > Options.

Hi Jeff,
It should be possible to set the transformation to "none" instead of "log". When is the error message prompted exactly (e.g., after changing the setting, pressing OK in the dialog) and what is the exact text of the error message? Have any of the involved parameters been tied to other parameters?

Hi Adam,

Are you using the FePEST in-built parallelization feature? If so, it is not necessary to set up a network drive, FePEST uses an own network connection using the port you provided to transfer the files. You only need to take care that FEFLOW (incl. any plug-ins that might be in use) is installed on both Slave and Host machine.

The error itself comes from the FEFLOW kernel, and is probably related to the encryption mechanism that is used when the data is transmitted. The error message however does not say why this is happening. The FEFLOW support will be able to help you in better detail.

Under Windows, you find FePEST in the start menu (together with FEFLOW and other tools).
Look for MIKE by DHI 2014 > FEFLOW 6.2 > Parameter Estimation.

I think the best indication to check if water is actually infiltrating or not is to check the budget on the top slice. If water infiltrates you should see a response in the head/pressure/saturation. If it is significant however depends of course on other model properties, especially material parameters and boundary conditions.

The generator-inbuild refinement works on the specified (selected) lines/polygon edges only. At the current development state, the tools for selecting these lines are not very advanced, so you need to manually select the lines where you wish to apply refinement. A selection based on maps for generator-refinement is not available in FEFLOW 6.0.

Alternatively you can do a manual refinement later (after the mesh has been generated), here you can use the nodal/elemental selection tools of the selection toolbar, including selection by maps.

Concerning the error: Are there extreme contrasts of size (very small supermesh features in a very large supermesh)?

The reason for failures of Gridbuilder often lies in the geometry of the supermesh, especially if line features are used or of the vertexes of polygons are not regularly distributed along the polygon border.
Try to test-wise delete the lines and see if it works. If yes, try to identify the lines that are causing the failures. If not, check the supermesh borders for sharp kinks or sharp angles.
If all this does not help, switching to the triangle mesh generator can be a good alternative.

There are a number of potential reasons for this behaviour, which problem class is used for the model?
At first it should be made sure that the model is not unstable. Afterwards, try to change the numerical parameters (different initial time step size and the error tolerance).