-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ns flag of WB output causing crashes with vector-based setups #22
Comments
It's a generic routine to write the output provided any The option of ' |
I understand the routine is generic for both grid-based and vector-based setups. As I said, it ran fine for the same vector-based setup when I used 25 soil layers (with a dp-compiled version). It looks like a weird error - at one point it picks some wrong number from the memory causing a crash. I printed NAA and ina upon the routine call, and it gave an error for obviously, 1112486707 is out of range for the array and thus it crashes. Is "nr" an option for the WB flag? or is it activated via "REACHOUTFLAG"? How to use the "n" option? do we specify a list of ranks after it? |
seems it has something to do with the recent fixes - older compiled code works. That's weird because I did not touch this module in the recent fixes and
should we try to make it a global variable? |
I cannot understand it but it does have something to do with the LongSimFix. I reversed the fix and the code works in such a case. There is a hidden link between the rte variables (changing the 999999 to 1) and |
I have 38 gauges in the streamflow file. Printing after the parsing call, I get:
printing before the "write_water_balance" call
produces: the condition ">0" makes replacing bnoflg%wb%ns(n) with n fails for most gauges. What made the variable bnoflg%wb%ns change values? |
the only place where this variable is assigned is in the parsing step during initialization - I am puzzled and it is indeed looking like a weird memory thing. |
Did you rebuild this code in its entirety since you made the 'LongSimFix' changes? |
yes |
we need to make the |
@kasra-keshavarz has just reported the same issue for the Fraser setup using a serially-complied version with intel (2020) on Graham |
Zelalem reported it too for his setup. He did not get a crash but got output for some sub-basins and no output for others. |
This seems to have been forgotten. I have a fix but I did not upload it. The fix eliminates the use of "bnoflg%wb%ns(n)" and uses n directly - in all the cases I have, n = bnoflg%wb%ns(n) at the assignment time. As long as MESH prints WB for all sub-basins, the flag will be 1 for all. There is currently no option to select but maybe there was an idea to allow selecting. |
Should be resolved with dprincz/MESH-Dev@5fc2d3b, as documented in #56. |
This seems to be a weird error as it does not occur in all cases. For example, I ran the same setup successfully using 25 soil layers. When I switched to 4 layers, I got the error. The crash is thrown by this line 1376 (in
save_basin_output.f90
)ina = min(ina, shd%NAA)
because ina got assigned some strangely large number for the 3rd sub-basin and instead of being assigned 3.
This routine is called from line 766 (writing the WB output):
`
I printed
bnoflg%wb%ns(n)
upon assignment and it is always identical to "n", the loop counter. I printed it before calling the "write_water_balance" routine to and it came out as:1
2
1112486707
before it crashed at the added print line, simply because there is no rank for such subbasin - it should be 3.
As I mentioned, I had no issue with this before the recent changes and I have no issues for grid-based setup (as far as I see). The same setup ran with 25 soil layers without crashes.
if bnoflg%wb%ns(n) = n; why do we need to save it?
I also noticed options nr and n for WB and these are not documented - we talked about "nr" before but I did not know it got implemented. I could not figure out the "n" option.
The text was updated successfully, but these errors were encountered: