Bug in writing CSV2 file
langevin-usgs opened this issue · comments
I think we may have found a bug in zone budget (in zonbudusg, but also likely in structured zone budget), and I wanted to get your opinion to see if I am missing something obvious. Here is the situation:
- Compact budget option is NOT used
- Wells are on in stress period 1 but later, the number of active wells is specified as 0
- Zone budget is asked to write a CSV2 file
In this situation, the non-compact budget file has an entry for WELLS in stress period 1, but it does not have an entry later on. It appears that zone budget gets confused for the CSV2 case because the number of columns has changed.
Does this sound like something you have encountered or seen before? When I run the model with COMPACT BUDGET everything works as expected.
If this is a bug, it seems like a fix would be to read through the entire budget file and determine names for all of the columns, and then go back and process the file.
Chris,
I have not seen this before. Of course I would have fixed this had I seen it when I was working at USGS. I duplicated the problem here at home. I'd like to look at what a fix might be, but I can't work on it until later tonight. I should be able to send a suggestion for a fix tomorrow.
--Arlen
To refresh my memory, I've looked at the Zonebudget code and the MF2005 routines that write budget data for list budget terms. I believe that the problem with CSV2 files would occur for any of the list budget terms that change between 0 and greater than 0 terms during a simulation because the old style budget save routines don't write budget data in a time step where the list has 0 terms. Your example had a change from greater than 0 wells to 0 wells, but it would be just as bad if it changed from 0 wells to greater than 0 wells.
The CSV2 Zonebudget file was the last file type added to Zonebudget (a request from a USGS user), and I doubt that it is being used much. (It wasn't used much when I was there.) Further, the old style budget file structure is probably not used much. We left the old structure in MODFLOW for backward compatibility, but I can't think of any benefit from using this old structure except to resurrect an old model with minimal effort. So I am not surprised that the problem has not been reported previously. This makes me think that a good solution would be to detect the problem and stop Zonebudget when it occurs. It should be easy enough in the rare case where the problem occurs to have the user rerun the model using COMPACTBUDGET once Zonebudget tells the user that there is a problem.
Along this line, I modified Zonebudget 3.01 to detect the problem and stop. It is a really simple change. I am attaching the code in case you might want to go this way. I added an NL argument to BUDGETPRECISION to pass back the code that indicates whether or not the budget file includes budget data in the COMPACT format. NL is the number of model layers, except it is negative if COMPACT budget is used. The NLAY argument is the absolute value of NL. Then the Zonebudget main checks NL and IUCSV2 to see if a CSV2 output file is requested without COMPACTBUDGET. If so, an error message is printed and Zonebudget stops.
If you prefer to modify Zonebudget to fix the problem, you can certainly do what you suggested originally -- read the budget file up front, check for different numbers of list budget terms in different time steps, and always print a value even in time steps where the value is missing. That's conceptually very simple, but a lot of code for a minimal situation. I have always objected to this kind of code enhancement because I value code simplicity when possible. The complexity doesn't seem warranted for such a rare situation.
Another way to fix the code would be to write 2 lines every time a CSV2 buget is written to the file -- repeat the header each time step followed by the line of data. That way the header would always be correct even though the number of data values for each time step could vary. I think that this change would be as simple as the change I made to detect the problem; however, the CSV2 file would be cluttered up with all the extra headers.
Arlen, thank you for looking into the code. I agree that terminating with an error is the preferable way to go. Based on your suggestion, I wrote a small check subroutine to see if the number or type of budget entries has changed, and then terminate with an error if that condition it found. This way zonebudget will still work in CSV mode for non-compact budget files if the number and type of entries remain the same. This situation, which is fine for zonebudget, is probably more common than the case where the number of entries for a particular budget type changes between zero and non=zero.
Does this seem reasonable to you? Unfortunately, the check (which just stores VBNM into VBNM0 the first time through) is a little more complicated due to the possibility that 'STORAGE' may or may not be there, but at least it is containerized into a small subroutine. I've tested it for a variety of conditions and I think it works as expected, but if you have the time to give the attached source file a quick look, it would be greatly appreciated.
Merry Xmas!
-Chris
Chris,
I think your solution looks good. Prior to receiving your solution, I had not thought about the possibility that the number of terms could stay the same while some names could change. Your routine catches both situations.
Merry Christmas.
--Arlen