-
Notifications
You must be signed in to change notification settings - Fork 10
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
IOSTAT variable needs initializing #44
Comments
ios is initialized in the variable declarations on each call to the subroutine, then is only assigned by the read statements and checked for each readline to see if one has failed (ie non-zero return value). are you sure this doesn't work? |
@andywood the ios assignment works for the initial invocation of read_snow17_parameters() but not successive calls. For example, adding a print statement before the input file is read has ios=-1 during the 2nd invocation:
|
ok, that suggests the line 27 initialization doesn't work. I wonder if that is compiler dependent? (e.g., declaration+assignment is not supported). Anywhere between line 27 and 37, every time the subroutine is called, ios should have a value of 0. |
Yes, assignment at declaration is usually a no-no in Fortran. A simple change to the following should suffice.
@drakest123 do you see assignment at declaration anywhere else in the code? Additionally, can someone explain line 41 to me:
If the do loop only runs when |
I think the practice of assigning simple vars at declaration is not uncommon - maybe grew out of card reader days when you could save a line by doing so. after googling it, I do see it's frowned upon. we can add revising these assignments where we find them to the code cleanup list if it's not already there. I think the logic you mention is a clunky way to exit the case loop when you hit the end of the file (or some other error) -- ie the last attempt to read a line fails, no cases are triggered, and you don't go through it again. perhaps otherwise you need a break statement. I agree there are other ways you could set this up. |
btw -- that is in other subroutines as well, even in that same module (and it's scattered through SUMMA, fwiw; also in some of the orig noah-mp code) |
Thanks for the heads-up. I'll look for other instances of this issue. After that, it would be good to compare the output with a previous version. FYI, I'm using gfortran on a Mac M1: A quick test verifies the behavior that we are seeing:
|
@drakest123 just a +1 that I have also noticed a similar issue in our Clear Creek modeling, where the initialization is fine for the first catchment, but not subsequent ones, e.g.:
|
An inventory of INTEGER, REAL and CHARACTER definitions for the NGEN version of the snow17 codebase indicates that, for variables that are not parameters, initialization during declaration occurs only in two files in the share/ directory:
|
digging some more, in 'modern' fortran (post F90) the |
In the example test.f90 above I tried:
|
sorry, I probably wasn't clear -- that's the default behavior if you leave out ',save' -- (which is causing the problem). |
Keith's suggested change fixed it for me, i.e., changing line 27 to:
and then adding the assignment below the local variables:
|
In share/ioModule.f90 Subroutine read_snow17_parameters(), the IOSTAT variable
ios
is non-zero upon subsequent calls to this subroutine.Current behavior
When running multiple catchments, variable ios is set to zero by a compile time setting. However, in subsequent calls to Subroutine read_snow17_parameters() this variable has a non-zero value.
Resolution
Explicitly set
ios = 0
after variable declarationsThe text was updated successfully, but these errors were encountered: