bug: flopy.utils.Mf6ListBudget get_dataframes incorrect if fluxes in budget reverse order

[laat0003]

Describe the bug Fluxes in the list budget reverse order after adding a MAW package to MF6 model. This makes the get_dataframes method for the flopy.utils.Mf6ListBudget object read the budget incorrectly because it appears to assume packages are listed in increasing order. Unsure if Flopy issue or MF6 issue.

flow_noMAW.lst.txt flow_withMAW.lst.txt

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context Add any other context about the problem here.

[langevin-usgs]

HI @laat0003, I read both of these files with flopy.utils.Mf6ListBudget and it looks good to me. Can you provide some more information on why you think there is a problem?

This is the order I see for the incremental budget for nomaw and maw:

df1_inc.columns, df2_inc.columns

(Index(['STO-SS_IN', 'STO-SY_IN', 'DRN_IN', 'DRN2_IN', 'DRN3_IN', 'DRN4_IN',
        'DRN5_IN', 'GHB_IN', 'GHB2_IN', 'RCHA_IN', 'EVTA_IN', 'TOTAL_IN',
        'STO-SS_OUT', 'STO-SY_OUT', 'DRN_OUT', 'DRN2_OUT', 'DRN3_OUT',
        'DRN4_OUT', 'DRN5_OUT', 'GHB_OUT', 'GHB2_OUT', 'RCHA_OUT', 'EVTA_OUT',
        'TOTAL_OUT', 'IN-OUT', 'PERCENT_DISCREPANCY'],
       dtype='object'),
 Index(['STO-SS_IN', 'STO-SY_IN', 'DRN_IN', 'DRN2_IN', 'DRN3_IN', 'DRN4_IN',
        'DRN5_IN', 'GHB_IN', 'GHB2_IN', 'RCHA_IN', 'EVTA_IN', 'MAW_IN',
        'TOTAL_IN', 'STO-SS_OUT', 'STO-SY_OUT', 'DRN_OUT', 'DRN2_OUT',
        'DRN3_OUT', 'DRN4_OUT', 'DRN5_OUT', 'GHB_OUT', 'GHB2_OUT', 'RCHA_OUT',
        'EVTA_OUT', 'MAW_OUT', 'TOTAL_OUT', 'IN-OUT', 'PERCENT_DISCREPANCY'],
       dtype='object'))

[laat0003]

Apologies I should have provided more detail. This is what I get when I run the MAW model followed by the get_dataframes method. Notice the actual list budget flux values compared with what the method returns as a dataframe. It seems as though the get_dataframes method is either getting the order of the DRN fluxes incorrect or the order of the names incorrect. The MF6 list file is definitely correct.

[langevin-usgs]

So I think the issue is that the column names that you see in the dataframe are not the package names that you see in the list file budget table. This is particularly confusing in your case, because you have numbered your packages and have listed them in the gwf name file in reverse order. I think the column names in the dataframe are numbered from 1 to n where n is the number of packages of that type (note it does not number the first one). So as you said the order in the list file budget does matter. In your list file budget, for example, the order is DRN5, DRN4, DRN3, DRN2, DRN1. But the flopy utility automatically labels these as DRN1, DRN2, DRN3, DRN4, DRN5.

One thing you might consider is using the BUDGETCSV option in the output control file to save the budget information to a csv file. This csv file will have all the budget information, even if PRINT_BUDGET is not specified for a period. Moreover, the BUDGETCSV information can be more easily accessed through the `.output approach described here: https://flopy.readthedocs.io/en/latest/Notebooks/mf6_output_tutorial01.html.

[laat0003]

Cheers for that @langevin-usgs. So, does this mean that the get_dataframes method is not supposed to use package names, but rather just number multiple packages of the same type sequentially?

I appreciate the heads up re BUDGETCSV. This sounds like a much better option. I don't suppose you can shed any light on why Flopy reversed the DRN package order after I added the MAW package. It's the same simulation and model object.

I'm working on some demonstration type notebooks for PhD students at Flinders Uni currently. The repo is public at https://github.com/laat0003/NCGRT_IntroFlopy and the notebook named Workshop_5 is specific to this problem - if that is of any use to you. It's a work in progress so no laughing please :)

Brilliant work from all you guys, as always.

flow_noMAW.nam.txt flow_withMAW.nam.txt

[wpbonelli]

While it seems like this is resolved (or at least worked around) I guess this can stay open as a case study for the next major version @langevin-usgs @laat0003? We will have the chance to rework the package internals and avoid any odd behaviors like this.

For now I will bump it along with the milestones.

[langevin-usgs]

I think this is resolved. @laat0003 happened upon a strange edge case. In general, I think we should be moving to use the BUDGETCSV option rather than parsing the tables written to the listing file.