Giovanni Formentin

Hello,
I put a script in my .FEM file to calibrate parameters through the Python API.
In the script, I refer to the .FPI file using its full path to the master folder (e.g.  FPIFile = r'C:\Model\M1'  ).
I'm running PEST in parallel.

1. The FPI file is not present in the master folder. I can find it in the agent folders though. Is it a bug? If it happens, am I to put the .FPI manually into the master folder?
2. In some agents, FePEST issues an error that it cannot find that .FPI file (in the Result files panel)
3. Running in parallel, do agents use the .FPI file in the master folder, or do each agent work with the FPI file in each specific folder? In this case, shouldn't the path to the .FPI file be specific to each agent folder?

Thanks for any advice,
Giovanni

I agree with Carlos: FePEST speeds up dramatically the setup of a PEST problem.
You just have to take advantage of what comes with Feflow, also considering that knowing how to manage the original PEST files allows to flexibly choose the parameters and observations of interest (the last time I checked I couldn't choose, in FePEST, head differences as observations) and to build problems based on multiple models (e.g. a recharge estimation model followed by a gw model). Working in batch model may require some programming in order to manage the input and output from Feflow, which can eventually be avoided by using plugins (I'm guessing since I know too little about the API world).
A question to Carlos: can Feflow be parallelized with PEST in batch mode?
Thanks,

Giovanni

The batch mode keeps being the most powerful way, since FePEST is still limited in the parameters and observations you can use.
A .dar file is saved by inputing "feflow61c -dar filename.dar" (in you are running Feflow 6.1) in the command prompt.
Just type "feflow61c" in the command prompt to see all the options.
I hope I addressed your questions. Also consider contacting me privately, I may be of help since I struggled a lot around the coupling!

Giovanni

It seems that, both in the saturated and unsaturated simulations, you get an unreasonable high output head.
Maybe the recharge is too high?
And did you set in the only no-flow side a bc able to accept water?

You always input Darcy's flow, not groundwater velocity.

It just sounds strange to me that PEST compares two real numbers by simple equality, not considering a tolerance around the desired value.

If the vertical scale of your model is the same of the pictures you uploaded in your previous message (approx. 400 meters), one thing I'd suggest is to dramatically increase the number of layers, even I can't tell if that alone would help recovering those very negative concentrations you now find in your run (I haven't opened the .fem yet).
Bye,

Giovanni

I've been involved in a problem very similar to yours, except that the top of Unit A was a 1-direction slope.
We simulated the horizontal drains by assigning 3rd type (Cauchy) BCs with levels set using the actual drain elevation at every node.
This way, we got the drained flow rate and the water levels in Unit A as output under different rain events.
Hope this helps,

Giovanni Formentin

I wouldn't go through 1D discrete elements: means adding parameters (holes spatial density, cross-section area) and making an uncertainty assessment more difficult to accomplish. It looks better on simple problems.

You can bet layer thickness is among the factors potentially giving instability, but I always start optimistic with my models! The end is another story...  :)