Using SFT package with MODFLOW 6 unstructured

[GemGWmodeler]

Hi! Just wondering if anyone has successfully used the SFT package for a GWT model on an unstructured MF6 model. We have an SFT package that works with a structured MF6 model, but using the same file format seems to cause issues in our MF6 unstructured model. Is there something different I need to do in the set up of the SFT that I could be missing? Thanks! Gem

[emorway-usgs]

If you have a small reproducible example that you could share that demonstrates (reproduces) the issue you are reporting, that would be helpful. You could try using one of the DISV example models found here that includes DISV and SFR and try amending it with SFT to see if that helps in reproducing the error you are seeing.

Alternatively, there might be a small DISV model that includes SFR that could be amended with SFT to demonstrate the issue in the autotests folder. In other words, you might be able to use one of them to get you started in making a small, reproducible example.

[GemGWmodeler]

Hi again! We managed to get a simplified version of the MF6 flow and transport model running with an SFR package where all reaches are connected to a GWF node. However, when as a test we add in a reach which we specify as not connected to aquifer, (using a 0 as cell ID), then MF 6 is coming up with an access violation error. I am not permitted to upload our simplified model, but I could probably create a small test model and upload it to demonstrate the issue...Otherwise, maybe I am doing something wrong in the file format of the sft or sfr. I couldn't find in any of the disv examples any sfr files where there are reaches with no connection to an underlying GWF node to check my file format against. Does anyone have any examples of the format of sfr6 and sft files used with a .disu model where some of the stream reaches are connected to other stream reaches but not to a GWF node? I need to check with the main project modeller why this is the case in our model, but this is what I currently need to work with.

[emorway-usgs]

@GemGWmodeler, I may have come across a similar issue in SFT/SFE for models with only a single active reach (see #1815). I suspect the issue I'm working on is related to what you're seeing. To confirm, if would be helpful if you could pass along the small example that includes the basic elements of your setup.

[GemGWmodeler]

Hi Eric,
Thanks very much for the reply and sorry for the delay in getting back to you. We've made a version of the model with a simplified SFR package. It seems to run both flow and transport (using SFT) when we include 10 sfr reaches, all of which are connected to a GWF node. When I add in the extra sfr reach 11, which is not connected to GWF model, then the flow part of MF6 can run, but the transport part fails with an access violation error. I will share the example model with you via OneDrive. I would be very grateful if you could take a look. Thanks for the help!
Gemma

[GemGWmodeler]

To_send_to_USGS.zip

Hi again,

We’ve now made a very simple demo model which replicates the issue we are encountering. In the uploaded folder there are 3 runs to demo the problem and when it occurs. The model is now a simple line of cells with SFR reaches 1 to 10 flowing across it:

Demo 1b has all 10 SFR reaches connected to GWF nodes – This one runs ok for both flow and transport

Demo 2b is the same as 1b (flow and transport), but with the 2 most upstream (1,2) and 2 most downstream (9,10) SFR reaches as NONE streams (not connected to aquifer) – this one does not run

Demo 3b is the same as 2b but we ran the flow part only, without the transport and this runs successfully, suggesting the problem is occurring when we try to run the transport model where there are NONE streams.

It would be great if you could take a look and see if it is indeed a bug only encountered when using NONE streams with SFT6 and if anything can be done to resolve it.

Many thanks!

[emorway-usgs]

Hello @GemGWmodeler,

I was able to get your example titled "Demo 2b" to run with some fairly simple changes to the SFR input file that I think are in line with what you want to do (but let me know if not). I'm attaching the update SFR input file to the end of this reply for your reference and use.

The changes were simply to restore the integer values "1", "2", "9", and "10" in the PACKAGEDATA​ block (instead of the keyword NONE) and in the PERIOD​ block I changed the status of those reaches (1, 2, 9, & 10) to INACTIVE​ instead of SIMPLE.

Per the following note in the MF6io.pdf guide: "The keyword NONE can be still be specified to identify unconnected reaches for backward compatibility with previous versions of MODFLOW 6 but eventually NONE will be deprecated and will cause MODFLOW 6 to terminate with an error," it's probably best to move away from this approach anyway. Hopefully this will allow you to push ahead in a manner consistent with what you'd like to do, but if not, let me know.

demo2b.sfr6.txt

[GemGWmodeler]

Hi @emorway-usgs ,

Thanks for your help with this issue. Although those proposed changes will allow MF6 to run successfully, unfortunately they don't align with what we are trying to do conceptually...Please see the image below for an explanation of why we need to keep the NONE streams in our model.

Thanks!

[emorway-usgs]

@GemGWmodeler, I'm still working on the single, unconnected reach issue. However, I went back to the beginning of this thread and re-read the following from an earlier post:

We managed to get a simplified version of the MF6 flow and transport model running with an SFR package where all reaches are connected to a GWF node. However, when as a test we add in a reach which we specify as not connected to aquifer, (using a 0 as cell ID), then MF 6 is coming up with an access violation error.

Perhaps I should have caught this earlier, but I wonder if the access violation error is because you possibly used a single 0 for cellid? For a DISV grid type, I think you would need to enter ifno, 0, 0, rlen, rwid, ... From the mf6io, I see:

...For example, for a DIS grid a CELLID of 0 0 0 should be specified. ...

This would indicate that for a DISV grid, a CELLID of 0 0 should be specified. In re-reading your much earlier message, it seems you only added a single 0? If my understanding is correct, perhaps revisit the original issue you reported above and see if 0 0 for cellid fixes the memory access violation error.