Jump to content
GMS, SMS, and WMS User Forum
woodward

Fixing GMS:FEMWATER boundary conditions

Recommended Posts

Here are some things I have learned that might be helpful to others...

1. Recharge should be represented using variable flux boundary conditions. The FEMWATER manual explains this in detail. In particular, variable flux bcs correct for the angle of the surface relative to horizontal while specified flux bcs do not. Variable flux bcs also handle ponding and runoff.

2. Using variable flux bcs require the user to specify two global parameters: HCON = maximum ponding depth [L] and HMIN = minimum pressure head as soil dries [L]. These are sent to FEMWATER via the RS3 card in the 3bc file in the format RS3 HCON HMIN (e.g. RS3 0.35 -8.0). GMS provides a dialog box for the user to enter these parameters on the menu FEMWATER|Variable BC Options... Unfortunately the labels are reversed in this dialog box, so you have to enter HMIN in the top box and HCON in the bottom one. Check the RS3 card in the 3bc file to make sure you've got it right.

3. Specified head (Dirichlet) bcs do not work properly along unsaturated boundaries, because the specified head value is, incorrectly, applied to the unsaturated nodes as well as the saturated ones. This can be corrected (with some effort) by removing the DB1 cards for the unsaturated nodes from the 3bc file. The unsaturated nodes will then be assumed to be no flux boundaries (i.e. above the water table). Deciding which nodes to remove becomes more challenging in the transient case. It would be great if GMS allowed the user to specify a maximum elevation (or minimum phd) along with each specified head bc. Nodes above this elevation would remain as no flux (i.e. Flow bc = NONE, the default) and no DB1 cards would be written for these nodes.

4. FEMWATER linearly interpolates transient XY series data (eg. recharge, specified head values) through time. If you want step changes you have to put them in yourself.

5. Check the transient XY series data in the 3bc file, because sometimes GMS only writes the first value in the series.

6. FEMWATER will crash if transport bcs are encountered in a flow simulation. This can occur if you run a tranport or coupled simulation and then revert to running a flow only simulation. The crash can be avoided by changing the tranport bcs to NONE in the GMS conceptual model and then Map -> FEMWATER. But if you do this you lose all your transport bc data. It would be better if GMS removed the transport bc cards from the 3bc file.

Please let me know if any of this is incorrect. Cheers.

Edited by woodward

Share this post


Link to post
Share on other sites

1. Recharge should be represented using variable flux boundary conditions. The FEMWATER manual explains this in detail. In particular, variable flux bcs correct for the angle of the surface relative to horizontal while specified flux bcs do not. Variable flux bcs also handle ponding and runoff.

Thank you for this information. This option seems to be available in GMS.

2. Using variable flux bcs require the user to specify two global parameters: HCON = maximum ponding depth [L] and HMIN = minimum pressure head as soil dries [L]. These are sent to FEMWATER via the RS3 card in the 3bc file in the format RS3 HCON HMIN (e.g. RS3 0.35 -8.0). GMS provides a dialog box for the user to enter these parameters on the menu FEMWATER|Variable BC Options... Unfortunately the labels are reversed in this dialog box, so you have to enter HMIN in the top box and HCON in the bottom one. Check the RS3 card in the 3bc file to make sure you've got it right.

This has been submitted as a bug and has been fixed.

3. Specified head (Dirichlet) bcs do not work properly along unsaturated boundaries, because the specified head value is, incorrectly, applied to the unsaturated nodes as well as the saturated ones. This can be corrected (with some effort) by removing the DB1 cards for the unsaturated nodes from the 3bc file. The unsaturated nodes will then be assumed to be no flux boundaries (i.e. above the water table). Deciding which nodes to remove becomes more challenging in the transient case. It would be great if GMS allowed the user to specify a maximum elevation (or minimum phd) along with each specified head bc. Nodes above this elevation would remain as no flux (i.e. Flow bc = NONE, the default) and no DB1 cards would be written for these nodes.

We're having difficulty reproducing this error. Could you send an example of this to support@aquaveo.com?

4. FEMWATER linearly interpolates transient XY series data (eg. recharge, specified head values) through time. If you want step changes you have to put them in yourself.

Thanks for pointing this out. I have submitted this as a feature request to the GMS developers.

5. Check the transient XY series data in the 3bc file, because sometimes GMS only writes the first value in the series.

I also could not reproduce this bug. Again, if you run into this problem, please send the files to support@aquaveo.com so that we can investigate further.

6. FEMWATER will crash if transport bcs are encountered in a flow simulation. This can occur if you run a tranport or coupled simulation and then revert to running a flow only simulation. The crash can be avoided by changing the tranport bcs to NONE in the GMS conceptual model and then Map -> FEMWATER. But if you do this you lose all your transport bc data. It would be better if GMS removed the transport bc cards from the 3bc file.

I have tried multiple times to reproduce this crash in GMS 6.5 (build date of May 27, 2009) to no avail. If you get this crash again, please send us your files.

Todd

XMS Technical Support

Share this post


Link to post
Share on other sites

3. Specified head (Dirichlet) bcs do not work properly along unsaturated boundaries, because the specified head value is, incorrectly, applied to the unsaturated nodes as well as the saturated ones. This can be corrected (with some effort) by removing the DB1 cards for the unsaturated nodes from the 3bc file. The unsaturated nodes will then be assumed to be no flux boundaries (i.e. above the water table). Deciding which nodes to remove becomes more challenging in the transient case. It would be great if GMS allowed the user to specify a maximum elevation (or minimum phd) along with each specified head bc. Nodes above this elevation would remain as no flux (i.e. Flow bc = NONE, the default) and no DB1 cards would be written for these nodes.

We're having difficulty reproducing this error. Could you send an example of this to support@aquaveo.com?

This is not a bug, it is a modelling issue. Specified head bcs in the conceptual model are applied to all nodes underneath the boundary. However, the pressure head at unsaturated nodes is a function of the recharge. If there is recharge then the specified head should not be applied at the unsaturated nodes.

Share this post


Link to post
Share on other sites

Here are some things I have learned that might be helpful to others...

1. Recharge should be represented using variable flux boundary conditions. The FEMWATER manual explains this in detail. In particular, variable flux bcs correct for the angle of the surface relative to horizontal while specified flux bcs do not. Variable flux bcs also handle ponding and runoff.

2. Using variable flux bcs require the user to specify two global parameters: HCON = maximum ponding depth [L] and HMIN = minimum pressure head as soil dries [L]. These are sent to FEMWATER via the RS3 card in the 3bc file in the format RS3 HCON HMIN (e.g. RS3 0.35 -8.0). GMS provides a dialog box for the user to enter these parameters on the menu FEMWATER|Variable BC Options... Unfortunately the labels are reversed in this dialog box, so you have to enter HMIN in the top box and HCON in the bottom one. Check the RS3 card in the 3bc file to make sure you've got it right.

Please let me know if any of this is incorrect. Cheers.

Simon,

Your advice caused me to more closely examine the description of variable flux boundaries in the FEMWATER manual. I have been having considerable difficulty getting reasonable piezometric head output from a model I've been working on. The heads remain stubbornly close to the ground surface despite my having reduced the specified recharge rates to a small fraction of what I know they must be. I've also had very slow or nonconvergence (in spite of my setting iteration parameters much higher than the default values)with the nonlinear iterations. I now believe that both problems may be related to the way the minimum pressure head setting is implemented in FEMWATER. I originally set this to a small negative value, thinking it should be representative of suction in drying (but not completely so) soil. Having reread the manual it appears to me that during nonprecipitation periods FEMWATER resets the pressure head to the specified minimum at all surface nodes where the head has dropped below this pressure.

My question is whether my interpretaton is correct? If so, how can such a boundary condition ever be made representative of natural recharge? It appears to me (from the manual and my experience with my model) that in each nonprecipitation period FEMWATER resets the water table to the global minimum pressure head - in effect "artificially" adding whatever water is necessary to keep the water table at a uniform depth below the ground. The only solution I can think of is to make the minimum pressure head a physically unrealistic negative value to permit the water table to drop without interference from FEMWATER during the nonprecipitation periods. However, it seems to me that having large negative pressures would invalidate the unsaturated flow calculations.

Finally, I have question about how the specified variable flux is handled in a steady state model. I have been using GMS to set the single-valued variable flux, which I valued at what I think the steady state recharge rate should be. However, I am now puzzled whether FEMWATER is applying an evaporation/seepage face flux during the nonprecipitation periods, as described in the manual. If so, what value of flux would it use in the absence of any being specified in the boundary condtions? It wouldn't be reasonable to use the recharge flux as that would have no relationship to seepage or evaporation rates, but what other value is available? Should I be manually editing the 3bc file to add a negative flux to the xy series cards written by GMS? If so, what "time" should it be associated with?

Sorry for all the questions. Any thoughts you might have about any of this stuff is welcome.

Share this post


Link to post
Share on other sites

1. Variable flux bcs in steady state model: I think what FEMWATER is doing is figuring out whether flux is inward or outward at each node. It could be outward if the water table comes near the surface so that net flux is outward. For some reason it (perversely) initially assumes it is outward everywhere.

2. Slow convergence: I found the cause behind my slow convergence was poor resolution in the van Genuchten curves. GMS produces curves that have poor resolution at the dry end of the curve. If you have the FEMWATER spline interpolation switched on, this can then produce curves that are non-monotonic I think, which screws up convergence. It worked better for me when I dramatically increased the number of points in the VG curves to 500 (I had increase MXSPMK and recompile FW to do this). Also note that the GMS preset VG curves are incorrect if your length scale is not centimetres.

3. Minimum pressure head: I think the only purpose of this parameter is to truncate the pressure head at the surface to limit how dry it can get, to avoid running off the end of the VG curves for instance. I am assuming this is only applied at the variable flux bc nodes but I am not sure.

  • Like 1

Share this post


Link to post
Share on other sites

Simon,

Thanks for your thoughts. I will have to digest this and run some more experiments. Perhaps I am misinterpreting how the variable flux equations in the FEMWATER manual are implemented. It appeared to me from these and my experiences (so far) that the minimum pressure head acts like a "floor" for the water table during the nonprecipitation period.

I think you must be correct about the way FEMWATER interprets the sign of the variable flux. The manual states that the variable flux must be specified as negative for groundwater discharge (outward flow) and positive for recharge (inward flow). But this can't be correct. If it were the single valued (positive) flux specified for steady state mode would force inward flow at all times, and I don't think that is occurring (based on the flow budgets). However, I'm still puzzled about what value FEMWATER would use for the outward seepage flux. It seems very odd to me that model would be restricted to using the recharge flux (which makes no sense to me).

Share this post


Link to post
Share on other sites

It is clear to me now that my speculations about the minimum pressure head and how it is implemented by FEMWATER were incorrect and should be disregarded by anyone following this thread. Instead of questioning whether the variable flux boundary condition works properly, I should have been looking more closely at other boundary conditions in my model. This became immediately apparent, when I belatedly made a model run simulating recharge with a specified flux condition rather than a variable flux condition. My problem was caused by boundary impediments to flow toward what should have been an area of groundwater discharge (a river). This problem was being partially masked by the compensating capactiy offered by the variable flux condition for groundwater to discharge to the ground surface. The lesson for me is that in the future I will always do initial trial runs simulating recharge with a specified flux condition before moving to the variable flux condition when I am certain that my other boundary conditions are in order.

Another minor note: The problem with the layout of the variable b.c. options dialog box is apparently specific to only some versions of GMS. I am using an older verion (5.1) that does not have this problem. The best approach, as indicated previously, is to check the .3bc file to see whether the RS3 card has been properly written.

Share this post


Link to post
Share on other sites

1. Variable flux bcs in steady state model: I think what FEMWATER is doing is figuring out whether flux is inward or outward at each node. It could be outward if the water table comes near the surface so that net flux is outward. For some reason it (perversely) initially assumes it is outward everywhere.

2. Slow convergence: I found the cause behind my slow convergence was poor resolution in the van Genuchten curves. GMS produces curves that have poor resolution at the dry end of the curve. If you have the FEMWATER spline interpolation switched on, this can then produce curves that are non-monotonic I think, which screws up convergence. It worked better for me when I dramatically increased the number of points in the VG curves to 500 (I had increase MXSPMK and recompile FW to do this). Also note that the GMS preset VG curves are incorrect if your length scale is not centimetres.

3. Minimum pressure head: I think the only purpose of this parameter is to truncate the pressure head at the surface to limit how dry it can get, to avoid running off the end of the VG curves for instance. I am assuming this is only applied at the variable flux bc nodes but I am not sure.

Simon,

Thank you for your warning ("Also note that the GMS preset VG curves are incorrect if your length scale is not centimetres"). I am indeed using a different length unit - archaic U.S. feet. I checked and the bug is also present in the old version (5.1) of GMS I use. I would have missed this if not for your warning.

Share this post


Link to post
Share on other sites

Simon,

Thank you for your warning ("Also note that the GMS preset VG curves are incorrect if your length scale is not centimetres"). I am indeed using a different length unit - archaic U.S. feet. I checked and the bug is also present in the old version (5.1) of GMS I use. I would have missed this if not for your warning.

The bug regarding the length unit has been fixed in the development version of GMS and version 7.1 beta (which is about to be released).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...