PHAST: Transient boundary conditions during steady-state simulations

[Leo]

Hi David,

another PHAST question here: As I understand from the manual, it is possible to temporarily vary some of the boundary condition's parameters. My example here would be to vary the pumping rate of a WELL bc. Each time, such a change happens, a new "simulation period" is begun, according to the manual. This works fine if I choose to set "STEADY_FLOW true". However, if I choose to undertake a steady state simulation (I know... this goes against changing the pumping rate over time), I would assume PHAST to start a new simulation period as well, which doesn't happen. I'd assume another iterative flow run until steady state is reached again, allowing me to find e. g. head distribution in *.wt.xyz.tsv for all simulation perios.

Is it correct that PHAST only allows changing hydraulic properties if I choose "STEADY_FLOW false"?

Thanks,
Leo

[dlparkhurst]

You only get one steady flow condition. Flow is calculated at the beginning of the run and the velocity field is used throughout the transport calculations. Consequently, I think, and you confirm, you only get one pumping rate. If you define more pumping period, I expect they are ignored.

The velocity calculation is not that expensive relative to the multiple transport equations and chemical calculations, so if you want multiple pumping period, it should not slow the calculation too much.

One issue may be that if you change the pumping rate frequently, and you get output at the end of every stress period, you end up with a lot of output. There is an option to eliminate the end-of-stress-period default for output so that you will get output less often.

[Leo]

I tried a transient run and it works - without too much effort for the additional head/velocity calculations. However, I will have to rethink the conceptual model (average vs temporally varying properties). Thanks a lot for your help.

[Leo]

To open this topic up again...

I get an ERROR exit after the following console output (excerpt):

 

Code: [Select]

XP rerun: H -1.446941493614880E-008  2.425033861230591E-007
 -2.569728010592079E-007
 Failed in XP_asmslc, negative concentration: H -1.446941493614880E-008
 transport_component_thread failed, H                             .
Done with transient flow and transport simulation.
ERROR exit.
My model is set up somehow like this:

* Free Surface
* transient
* Recharge as FLUX_BC (fluxes varying yearly, defined in external text file)
* Several RIVERs
* Model boundary with fixed SPECIFIED_HEAD_BC
* Several pumping WELLs, varying pumping rates (yearly changes)

* relatively fine grid (few meters)
* time step 1 year, however, tested with smaller time steps down to 0.001 year
* upstream in space, backwards in time differencing

* Two modeling steps, the second starts with the corresponding restart files from the first simulation; first simulation ends 1996, second simulation starts 1996

I already spent quite some time to try and find the reason for this error, from varying the time steps to trying different KNOBS parameters in *.chem.dat. The transient flow runs through without any problem. The same goes for the first two years (to time steps if dt=1year) in case of solution transport and chemistry enabled. Afterwards however, above error occurs and I am not able to pinpoint the problem, why I'm getting negative concentrations that don't resolve. It seems that the problem occurs during the transport step - even before the chemistry calculation. I had a look at the source code and found where the error is generated but could not come up with a proper idea for a solution.

Any ideas?

[dlparkhurst]

You are right, the error is in the transport calculation, not the chemistry calculation. You don't say what weighting you are using, but I think you will need to use upstream and backward in time. It  will add numerical dispersivity to the solution, but it will avoid oscillations in the transport solution, which can cause negative concentrations.

Look at the appendix to estimate the numerical dispersivity due to time and space discretization.

[Leo]

I'm already using upstream in space, backward in time; I already tried using central differencing and the error persists. Also, in this case, PHAST outputs a hint to try using said upstream in space, backward in time differencing. Numerical dispersivity right now should not be too important as long as I can get the model to run. Or do you think, too large numerical dispersion would also contribute to negative concentrations?

[dlparkhurst]

The numerical dispersion should not be the issue. If you can start the transient simulation from a steady-state solution, it would probably help.

Otherwise, if you are willing to post or send your example, I will take a look.

[Leo]

Thank you for your offer. Unfortunately, it won't be possible to provide the whole model and I don't see a proper option to reduce it to a minimal example. What exactly do you mean by starting the transient simulation from a steady-state solution? The flow calculation itself isn't the problem and, as I understood, the solute transport and chemistry calculations are always transient.

[dlparkhurst]

There could be large transients in the velocity field that is then used in the transport calculation if you are starting with a head distribution that is far from steady state. Does your simulation run with steady flow?

There is an option to save the head distribution at the end of a simulation. You can save the heads from a steady-state flow simulation. Then you probably want to rename that file (so that it does not get inadvertently overwritten), and use the file as the initial head distribution for the transient calculation.

With P4W, if you can get me the .p4w file, probably with a link if it is large, I can look at it.

[Leo]

I'm already using the option to write the head.dat file and the subsequent run is using this file as HEAD_IC. I will try to successfully run a steady state variant and if this fails, I will see if I can somehow reduce the problem to maybe provide the p4w file. Thanks again!