Jump to content
GMS, SMS, and WMS User Forum

James Ewart

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

3 Neutral

About James Ewart

  • Rank
    Member
  1. 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.
  2. 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.
  3. 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).
  4. 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.
  5. I'm adding this note for anyone following this thread, because of a similar problem. I've found that the FORTRAN compiler G95 seems to do a fine job of compiling the FEMWATER source code. Its free and available here: http://www.g95.org/index.shtml
  6. Simon, Thank you for the useful information. I neglected to mention that I also have a large number of wells in my simulation. These also contribute to the number of XY series cards in the .BC file. The wells are representative of an even larger number of domestic wells in the area being modeled.
  7. Simon, Thanks for the reply. Can you tell me which compiler you've used? What I am not sure of is whether the FEMWATER executable exchanges any information with GMS via binary files. I know from limited past experience that binary formats can be compiler specific. As for the number of XY series, it appears from my .BC file that they do indeed number over 250. Ironically for me, many are the consequence of FEMWATER's requirement that unsaturated zone parameters be defined for all materials. Most of these definitions are pointless in my model, because most of the materials should never become unsaturated. In fact, I would love to be able to bypass FEMWATER's unsaturated flow routines entirely. I have no interest in the unsaturated zone calculations and would be happier to be handling saturated zone recharge as an input (ala MODFLOW). However, as these can not be bypassed (as far as I know), I am obliged to define the materials with realistic unsaturated material properties.
  8. Does anyone know if there is a way to increase the value of the parameter MXXYS in a FEMWATER model file? I find that my model definition exceeds a limit of 250 for this parameter. From what I've been able to determine from the run log this parameter seems to be the maximum number of XY series definitions allowed in the ".bc" file. I am not sure of this as the parameter is not defined in the FEMWATER source code, but this appears to be how it is used in setting array dimensions. The value of the parameter is defined as 250 in the include file: gwpara.inc, which leads me to think that I may have to recompile FEMWATER to increase the value of MXXYS. If anyone can verify this or knows of another way to increase it, I will appreciate the info.
  9. Alan, I don't understand. I've been using the fill between tins method of mesh generation and whenever I've tried to use a tin that doesn't extend at least to the limits of the 2D projection mesh (in X-Y space) I've gotten an error message. While I haven't used the solids to 3D mesh projection method, the GMS documentation indicates "every layer in the 3D mesh must be present in the solids". I took this to mean that the solids must span the X-Y space occupied by the 2D projection mesh - similar to the tins. I this not the case? James
  10. Simon, The order of node assignments to the elements turned out to be the root cause of my problems with the selection of boundary faces and the assignment of fluxes to faces by mapping. So, apparently GMS does know about and use this ordering to determine how to map recharge to the mesh. Fortunately for me the misordering in my mesh definition file was systematic. So, all that was required (I think and continue to hope) was to write element definition part of the .3DM file into an Excel spreadsheet, reorder the columns, and write the result back into the .3DM file. It seems to have worked. I hope this will also make the mesh copacetic with FEMWATER. Your advice put me on to the right track - thank you! This didn't fix the issue with mesh refinement, as that process still creates 5-noded elements (I think because of the non-vertical alignment of my nodes). I think I will make do without that. James
  11. Simon, I was unaware about restrictions on the side number to which flux BCs can be assigned (or were you citing this as a hypothetical case?). However, your response caused me to recheck the FEMWATER documentation as regards the order of node assignments to elements. I now realize that the method I used to create my mesh (see my response to later post) has probably caused the sequence of node assignments to not be in the usual order. I think is probably what is interfering with the proper assigment of flux bcs (and who knows what else that I haven't yet discovered). The prospects of trying to correct this are daunting. However, I appreciate your input.
  12. The geometry of the hydro units is as I described in a previous post. Here are some more details: There is a sequence of sedimentary rock layers (constituting hydrostratigraphic units) that dip at approximately 40 degrees. These are overlain by an unconsolidated layer (a distinct hdyrostratigraphic unit) that is more or less horizontal. The unconsolidated layer is the only one that spans the X-Y extents of the model domain. The inclined sedimentary units exist only under portions of the model domain. If I were using MODFLOW I would use a "stair steping" definition of material properties to simulate the dipping units. However, the objectives of this model require a more accurate definition of the hydrostratigraphic boundaries than "stair stepping" would allow (without an immense overhead of dense discretization). I chose to use the finite element method (FEMWATER) to avoid this restriction and to gain access to a fully anisotropic conductivity tensor. However, the mesh generation methods I have been able to find in GMS seem to be limited to projections in the z-direction, which require that the "layer" or "horizon" boundaries (e.g. tins) span (at least at the time of projection) the X-Y extents of the model domain. The geometry of the units I am modeling deviate so dramatically from this assumption, that I found the process of creating pseudo layers and "pinching out" the unwanted parts an unworkable solution. There ended up being far too many unwanted layers of elements to remove from the resulting mesh. However, my material boundaries (with the exception of the unconsolidated layer) do very nearly span the X-Z space of my model domain. So, I transformed my tins so that the real world y-direction became the Z-direction in GMS. I then projected a mesh having the geometry I wanted for the inclined layers. Outside of GMS I transformed the nodal coordinates back to real world coordinates and wrote these new coordinates to the .3DM file. I also transformed the coordinates on the what was now the top of the mesh to match surface topography. While this approach created a mesh that has the correct geometry and passed muster with the FEMWATER simulation check, it does not appear to be compatible with at least some of the GMS automation tools (such as mesh refinement or Map to FEMWATER for areal properties). I suspect this is because my nodes are not vertically aligned. At your suggestion, I tried the mesh refinement to tetrahedra. The FEMWATER documentation recommends against these, but I am willing to give it a go if it might work. For some reason the coarse refinement is unavailable with my mesh (greyed out). The fine refinement to tetrahedra did indeed convert the 5-node elements (created by mesh refinement) to acceptable tetrahedra. However, the fine refinement has resulted in a substantially denser mesh than I think my computer can handle. Thanks for the suggestions, and sorry for the overly long reply.
  13. Simon, Thanks for your response. It is helpful to know that the problem I've encountered is not a known bug. Now I know that it probably has something to do with my mesh. It was necessary to create much of my mesh's geometry outside of GMS using other editing tools. Unfortunately, I am obliged to model a part of the world where formation boundaries are inclined to the horizontal and truncated by an overlying unconsolidated aquifer. Its not a particularly unusual situation in the real world, but one the tools in GMS are inadequate to replicate. I've subsequently discovered that the issue I raised in my message is the now the least of my worries. The GMS mesh refinement tools gave the appearance of working with my mesh, until I discovered much later that they created numerous elements that are incompatible with FEMWATER (e.g. five node elements). It has put me in a position of trying to recover several weeks of effort, assuming that I can work around the problem. It may be that a mesh having the geometry I intend is simply unworkable in GMS. Thank you for the offer of your Matlab script. Alas, I do not have that program.
  14. Has anyone encountered this issue with FEMWATER in GMS ver. 5.1? If so, I could use some advise. The issue is a failure of the Map to FEMWATER function to correctly assign nodal and element face boundary conditions to the upper boundary of the mesh. Instead, the function assigns the values to boundary nodes or faces on the bottom of the mesh. As a result I am forced to select boundary nodes or element faces in the 3D mesh view and manually assign head or flux boundary conditions in the FEMWATER menu. A bizzare, but perhaps related, issue is that I must view the mesh from its bottom for the select boundary node or select boundary face tool to select nodes or faces on the top (opposed) side of the mesh. If I try to select from a top view, the tools select nodes or faces on the bottom of my mesh. I wondered whether GMS is using a left handed coordinate system in its FEMWATER interface (i.e. Z positive downward), but this doesn't seem to be the case. Another aspect of my mesh, which doesn't strike me as unusual is that its top has topographic relief, while its bottom is flat. One consequence of this more than just frustrating, because any use of the Map to FEMWATER function that does work (e.g. assignment of point sinks/wells to nodes) wipes out the boundary conditions I painstakingly added by hand in the 3D mesh interface.
  15. I recently encountered a very similar problem in GMS version 5.1, so the bug has apparently been with GMS for a long while. What I found with ver. 5.1 is that material properties revert to the default unless that material is assigned to a mesh cell before saving. Materials that have been assigned retain their settings, while all others revert to the default values when the file is reopened. Curiously, it is the reopening of the file that seems to obliterate the values of unassigned materials, because I've discovered that they were saved in the original .bc file.
×
×
  • Create New...