MODFLOW-USG layer dependent discretization

[J.P. Brandenburg]

Hello, has anyone out there successfully made use of MODFLOW USG "layer dependent" discretization? If so, what was your tool of choice? That type of grid refinement is nicely described in this 2014 blog post from Waterloo Hydrogeologic:    

MODFLOW-USG Layer Dependent Discretization - Waterloo Hydrogeologic  

Any of the big software packages (Vistas, Visual Modflow Flex, GMS) can in theory work with such grids, but I've not found where the tools to *create* such a grid live. 

[Marcio Alberto]

Hi,

There’s one video of Waterloo Hydrogeologic showing the way to do it. 

https://youtu.be/RNBy-vWLtms

I think you just can use this if you select conceptual modeling. But, I’m not sure. 

Greetings!

Marcio Alberto 

--
You received this message because you are subscribed to the Google Groups "MODFLOW Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modflow+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/4ca496da-1ef1-4010-b0b2-e152a72f7280n%40googlegroups.com.

--

Marcio Alberto
Consultor em Gerenciamento de Áreas Contaminadas

+55 11 94970-2592

[damian....@hydroalgorithmics.com]

It depends on what you are trying to achieve. I can't speak for VMod or GMS, but both Groundwater Vistas (https://www.groundwatermodels.com/) and AlgoMesh (https://www.hydroalgorithmics.com/software/algomesh) have tools for creating layer-dependent discretisations in the form of spatially-confined vertical sub-layering and/or cell pinchouts. In AlgoMesh, for example, vertical sub-layering is done by setting up explicit Lateral Connection Groups (LCGs) - see section 5.3 of the user guide here: https://dl.hydroalgorithmics.com/AlgoMesh%20User%20Guide.pdf

Layer-dependent discretisation in a more general sense is problematic in layered prismatic grids like those used in MODFLOW-USG. If you think about the geometry of any partially-overlapping cells, e.g. in a quadtree/octree grid with four cells on one layer and a single cell covering the same space on the layer below: whenever you have this interface  between two adjacent layers where the elevations are not flat, there will be an overlap in cell volume. This is a problem because the model will effectively double-count any such overlapping volumes. The problem could be avoided by introducing an additional "buffer" layer on the upper side of the interface which repeats the fine mesh but has a uniform bottom elevation - but of course you are then adding potentially many more cells, which may eliminate the benefit of going to a coarser grid for lower layers anyway. Perhaps it could be effective in some settings. However, I suspect creating this sort of grid would be difficult in most, if not all, existing graphical modelling interfaces. An appropriate DISU file could be set up manually (or by a custom script), as a merger of multiple independent DISUs created by GUI for each of the different grids, by an appropriately adventurous modeller!

Regards,

Damian Merrick.

Disclaimer: I am the author of AlgoMesh.

[rcon...@gmail.com]

Its quite easy to set up a octree (different quadtree in each layer) in GWV8. However, working with disu grids really increases model complexity, and I would say to avoid it unless you really need it. 

Another option could be to use nested models via the exchange package. You could have a refined regular row column model nested (layer 1 only, at depth, where ever you want it, ect) in a larger row column model and get basically the same thing as an unstructured grid, but with models that are much easier to work with.