Jump to content
GMS, SMS, and WMS User Forum
James Ewart

bizzare behavior with the assignment of FEMWATER BCs

Recommended Posts

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.

Share this post


Link to post
Share on other sites

Hi James. I am also doing some work with a mesh that has irregular topography at the surface and a planar (inclined) lower boundary. I have been using GMS 6.5. and 7.0. I have not had any problems with specified or variable flux bcs being applied incorrectly to the top boundary nodes. Have you tried renumbering the nodes? In my model I also need to edit the nodal boundary conditions cards in the 3bc file (remove some of the Dirichlet nodes) and I do this using a Matlab script that rewrites the FEMWATER input files and makes corrections. I am not sure if this would help you but I would be happy to share the script with you. Simon

Share this post


Link to post
Share on other sites

Hi James. I am also doing some work with a mesh that has irregular topography at the surface and a planar (inclined) lower boundary. I have been using GMS 6.5. and 7.0. I have not had any problems with specified or variable flux bcs being applied incorrectly to the top boundary nodes. Have you tried renumbering the nodes? In my model I also need to edit the nodal boundary conditions cards in the 3bc file (remove some of the Dirichlet nodes) and I do this using a Matlab script that rewrites the FEMWATER input files and makes corrections. I am not sure if this would help you but I would be happy to share the script with you. Simon

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.

Share this post


Link to post
Share on other sites

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.

Hi James

Yes Matlab is both expensive and hard to learn (a bit like GMS!).

I imagine that when you set up a mesh in GMS there are linkages created between the mesh and the conceptual model. So if you import a map GMS might not be able to connect them properly. You might be right that it might be an issue of element orientation, GMS might assign the flux bcs to side "2" of the elements which might not be the top because your mesh has different orientation.

Apparently you can model pinchouts in GMS but I have not done it, and I do not know whether FEMWATER would accept them.

Simon

Share this post


Link to post
Share on other sites

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.

FEMWATER does not support 5 node elements but it does support 4 node tets. You can convert all of your elements to 4 node elements with a single command. Use the Mesh | Refine Elements command and select the All elements -> tets and the Course refinement. This should do the trick.

Also, you mentioned that GMS is unable to model your geology. Could you give more details on this? Have you tried using the "Horizons" method to generate a 3D Mesh?

Share this post


Link to post
Share on other sites

FEMWATER does not support 5 node elements but it does support 4 node tets. You can convert all of your elements to 4 node elements with a single command. Use the Mesh | Refine Elements command and select the All elements -> tets and the Course refinement. This should do the trick.

Also, you mentioned that GMS is unable to model your geology. Could you give more details on this? Have you tried using the "Horizons" method to generate a 3D Mesh?

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.

Share this post


Link to post
Share on other sites

Hi James

Yes Matlab is both expensive and hard to learn (a bit like GMS!).

I imagine that when you set up a mesh in GMS there are linkages created between the mesh and the conceptual model. So if you import a map GMS might not be able to connect them properly. You might be right that it might be an issue of element orientation, GMS might assign the flux bcs to side "2" of the elements which might not be the top because your mesh has different orientation.

Apparently you can model pinchouts in GMS but I have not done it, and I do not know whether FEMWATER would accept them.

Simon

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.

Share this post


Link to post
Share on other sites

FEMWATER does not support 5 node elements but it does support 4 node tets. You can convert all of your elements to 4 node elements with a single command. Use the Mesh | Refine Elements command and select the All elements -> tets and the Course refinement. This should do the trick.

Also, you mentioned that GMS is unable to model your geology. Could you give more details on this? Have you tried using the "Horizons" method to generate a 3D Mesh?

Hi Alan

Regarding refining the mesh, a feature request for GMS would be the ability to refine horizontally (i.e. halve the layer thickness). There are options for refining into vertical columns but I have also wanted to increase the number of mesh layers and I have to delete the mesh and start again to do this.

Thanks

Simon

Share this post


Link to post
Share on other sites

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.

James

In my simulations recharge always gets assigned to face number 2 of the elements (hexahedral or wedge) in the top layer, that's why I used this example.

I have also had some problems previously with the node orientation in GMS - I generated a regular 3D grid with GMS then converted it to a 3D mesh. When I tried to use this with FEMWATER, FEMWATER crashed (in the particle tracking code). But if I went into the 3dm file and rotated the element definitions 90 degrees (the nodes stay in the same places) FEMWATER worked! My guess is that FEMWATER has a bug/implicit assumption about mesh orientation that GMS doesn't know about. I have also had success with generating my own mesh using Matlab, but this is only practical for simple geometries.

Simon

Share this post


Link to post
Share on other sites

James

In my simulations recharge always gets assigned to face number 2 of the elements (hexahedral or wedge) in the top layer, that's why I used this example.

I have also had some problems previously with the node orientation in GMS - I generated a regular 3D grid with GMS then converted it to a 3D mesh. When I tried to use this with FEMWATER, FEMWATER crashed (in the particle tracking code). But if I went into the 3dm file and rotated the element definitions 90 degrees (the nodes stay in the same places) FEMWATER worked! My guess is that FEMWATER has a bug/implicit assumption about mesh orientation that GMS doesn't know about. I have also had success with generating my own mesh using Matlab, but this is only practical for simple geometries.

Simon

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

Share this post


Link to post
Share on other sites

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.

James

Your modeling problem sounds very interesting. Even though the mesh generation methods in GMS do use a 2D projection mesh, the layers that are being modeled do not have to span the entire model domain.

Alan

Share this post


Link to post
Share on other sites

James

Your modeling problem sounds very interesting. Even though the mesh generation methods in GMS do use a 2D projection mesh, the layers that are being modeled do not have to span the entire model domain.

Alan

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

Share this post


Link to post
Share on other sites

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

James

Sorry for the confusion. I should have been more specific. I didn't realize that you were using the fill between TINs command.

The horizons method can be used to generate solid models or finite element meshes. The current femwater tutorial shows one example of mesh generation using horizons. You can read more about horizons here and here. There is also a tutorial that shows how to use TINs to generate 3D finite element meshes here.

Alan

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...