Exchange between two disv voronoi models

[RyanConway91]

I am getting started on a model which needs to simulate underground mine workings and some complex surface water features (connected network of wetlands). I want to have separate models simulating the watertable/surface water interaction and the underground mine workings, as the water table model will likely need to be calibrated to high frequency data and I don't want to carry around the overhead of the underground mine workings model. I will connect the two models using the exchange package.

In the past when I have done this sort of thing, I usually use a quad-tree .disv child model inset in a regular .dis parent model where the child grid nicely aligns with the parent grid. However, I want to use voronoi for the underground features because this is what a previous version of model used (and they play well with CVFD assumptions).

My current plan is also use voronoi for the watertable/surface water model. I know you can compute the exchange parameters for any type of grid, but wanted to get some feedback on this approach. Has anyone used exchange on two voronoi disvs? I would likely have pretty high-resolution in the watertable model overlaying pretty coarse resolution in the bedrock mine-workings model. Maybe making this all one model with an octree grid would be better for this?

[christianlangevin]

Hey @RyanConway91, I'm not sure I'm aware of anyone connecting up two different DISV models, though, as you mention, this should work fine in the MODFLOW 6 context. You'd need some tool to map up the exchanges, but I suspect you can write something in Python to help with that. It's unclear if an octree grid would be better for this; as you mention, the voronoi grids have some nice properties that make them appealing for CVFD models. Nothing much to add here, but let us know if you get the DISV voronoi grids connected up. Would be nice to see a picture of the resulting connected system.

[RyanConway91]

Thanks! I cant use GNC on just the exchange, correct? GNC is applied on the model level, not the simulation level? Would using XT3D on the exchange be recommended?

[aprovost-usgs]

@RyanConway91 you should be able to use either GNC or XT3D on just the exchange. (They're controlled though the gwf-gwf exchange input file.) I assume you're not using either of those corrections in the individual models themselves because, as you noted, the Voronoi grids are CVFD-friendly, so you don't really need a correction. You would need a correction at the exchange only if that CVFD-friendly geometry breaks down where cells connect across the exchange.

[RyanConway91]

thanks @aprovost-usgs, good to hear I can apply GNC to the exchange. Yes, I do not intend to use XT3D or GNC within the individual voronoi models.

The gridding of the glacial/surface water model would be refined around surface water features, where as the gridding of the bedrock model would be refined around mine workings, so the grids would not line up and would violate CVFD. So I think looking to GNC for the exchange makes sense.

Would this approach cause any issues with simulating transport?

[aprovost-usgs]

@RyanConway91 Using GNC at the flow model exchange (gwf-gwf) shouldn't cause any issues with simulating transport, assuming your correction results in reasonable flows. However, in the transport models, you'll typically want XT3D on to get an accurate concentration (or temperature) solution, and it's on by default. It's also on by default in the transport model exchange (gwt-gwt or gwe-gwe). The reason is that, except in some special cases, the principal directions of the dispersion tensor -- which are flow-direction dependent -- won't align with the model coordinate directions. It's analogous to having the principal anisotropy directions of the K tensor not align with your coordinate directions -- the two-point flow calculation (the water or solute flow between two cells being proportional to the head/concentration/temperature difference between those two cells) becomes inaccurate, and you need to take all components of the head/concentration/temperature gradient into account, which is what XT3D does. As you can imagine, it's a much more involved calculation, and it does slow things down. You can optionally shut off XT3D in the transport models and transport exchange and see what difference it makes in your application.

Btw, it would be ok to use GNC for flow and XT3D for transport -- they won't interfere with each other. You just can't use them both in the same model.

[mjr-deltares]

Hi @RyanConway91 , if you are going for GNC it could still be interesting to see the difference with XT3D enabled only at the exchange. I think that is easily done, if I am not mistaken, because all you need to do is set the XT3D option flag in the GWF-GWF exchange file(s) and temporarily remove the GNC from that same options block.