gw transport model with mf6-gwt and mfusg-transport

[hjia1005]

I recently tried gwt on a mf6 model and also tried mfusg-transport on a usg model. Both have complex structures - 13 layers with different extents (number of nodes) in each layer. They are different models but simulating kind of the same area. Both groundwater flow models converge easily and are quite stable.

To make it simple, In both transport models, I only simulated the advection and dispersivity of a single contaminant specie, which was applied over some mine void pits as CNC in mf6 and PCB in mfusg-transport over the whole stress periods (99 for the mfusg model and 162 for the mf6 model). ATS has been used for both models. The transport part of the mfusg model runs very fast (less than 1 second for each time step) and I always get the expected result - no negative concentrations and very reasonable distribution. But the GWT model had many hiccups, it failed to converge at sp 27 after updating the length of timesteps for that sp many times. I used very similar settings of ims for gwf and gwt model but reduced the value of dvclose by one order in the gwt model. I then tried to modify the ims package but all went worse, some even stuck from sp 1. I then checked the concentration file and found that values start to get crazy when the model had to reduce the initial timestep to converge. The range of the concentration is from -614613.3034585962 to 652918.5279728356, which is apparently not right.

I don't have much experience in transport modeling. Wish someone who has similar experience can help a little bit.

[langevin-usgs]

For GWT, you should make sure that you do not use COMPLEX settings for IMS. We've found that the SIMPLE setting in IMS works the best for transport models.

It's difficult to know what's wrong with your model as there are many ways to get into trouble. I am out of the office but may be able to provide some assistance next week if you are still having trouble.

[emorway-usgs]

Might be worth double checking that you have good correspondence between the storage parameters in the flow model versus the specified porosity value in the transport model. Presumably you've also checked that the same cells active in GWF are active in GWT (or maybe GWT model checks for this automatically, I'm not sure).

[hjia1005]

Thanks @langevin-usgs @emorway-usgs for your suggestions. I tried the following:

1. I set the ims for the gwt model as "simple", which didn't change the convergency, still stuck at sp27.
2. I used fmi package to run only the transport model, but then the inconsistency of the time step between gwf and gwt caused the termination of the simulation. I have to run gwf and gwt together to avoid it.
3. I change the porosity value from a constant of 0.1 for the entire model to gwf.sto.sy.data x 2, this has led to the model to stuck at sp6 because of the low porosity I guess. I then changed it to gwf.sto.sy.data x 10, after which I had similar behavior as porosity=0.1 - sp27 is still the failing point.
4. I removed CNC in the pit since it doesn't make sense, because it's actually a dewatering process. I then applied SRC over the upper boundary cells of the model domain where the simulated heads are the highest, hoping the advection can take the contaminant to the whole model domain. The gwt model then stuck at a later stage sp 31, but the concentration still became crazy from sp27 though it converged at that step.
5. Instead of applying SRC for the whole model time, I decided to stop it at sp27 where it normally goes crazy. The model then passed both sp27 and sp31 (but struggled to reduce the initial time step again and again). I checked the simulated concentration, and even though I stopped the mass load from SP 28, it's still getting mad from there. I also checked both the water balance and mass balance from sp27 to sp29, see below:

I don't see any problem with the flow model, I cannot figure out what caused the sudden spike of mass in the storage around that time. I understand it can be many reasons - just share my experience. Anyway this is an experimental transport model, I would halt it if I can't get it right with my limited knowledge.

I really enjoy the super convenience of Flopy to create the gwt model files like magic. As end user we don't have to worry about all the flags and error checks. Thanks for all your hard work to make it happen. For the usg-transport model, I had to write the model files in an ugly format and need to be careful about all the flags and associated datasets in the bct file since no such package is available for now. Not sure if @cnicol-gwlogic has any plan for it?

[emorway-usgs]

Hello @hjia1005, you mentioned this is an "experimental transport" model. If you're comfortable sharing the input, or just the flopy script that generates the input, that would likely make it easier to assess what's going on. All the percent discrepancies in what you shared are 0.0 - a good thing.

[hjia1005]

Sorry to come back late here. My boss is not comfortable with sharing the model files as the client may have an issue with that. Thank you very much for your help.

[hjia1005]

Hi Eric, thank you. The gwt part of the model is experimental but the gwf is for a consulting project. I am not sure if my boss is comfortable with sharing it publicly. I set up the model in flopy with many supporting files - shp, csv, rasters, and some other tools have been used. Therefore it's not a single script of workflow. I checked the total size of model files, which is over 400M without resulting files (.hds, .cbc, .con, .lst). I will ask my boss on Monday, if he is OK I may share the model files with you.

…

On Fri, 21 Oct 2022 at 22:05, Eric Morway ***@***.***> wrote: Hello @hjia1005 <https://github.com/hjia1005>, you mentioned this is an "experimental transport" model. If you're comfortable sharing the input, or just the flopy script that generates the input, that would likely make it easier to assess what's going on. All the percent discrepancies in what you shared are 0.0 - a good thing. — Reply to this email directly, view it on GitHub <#1597 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH7GLMRYGEAQTO7Y2KRLR33WEKBJHANCNFSM6AAAAAARJWPTHU> . You are receiving this because you were mentioned.Message ID: ***@***.***>