You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recent changes to the CICE namelist implementation to trap bad namelist inputs is failing with the NAG compiler. After some debugging, this comes down to a few issues
The new feature leverages trapping bad lines with the iostat flag in the read namelist command. But that iostat flag is also used to cycle thru the namelist file to find the correct group in some cases.
Most compilers seem to reopen the namelist file in the place where it was most recently closed. NAG does not do that, it rewinds the file.
As currently coded, there is an assumption (mostly in ice_init) that namelist groups occur in a particular order. That is not documented. In other parts of the code, the namelist group could be in an arbitrary order. The required order seems to be more-or-less fortuitously followed by users and is implemented in just the perfect order in the standalone code.
The new feature that was added to trap bad namelist lines happens to work on most compilers because
The namelist groups appear in just the right order in the standalone testing to not require cycling in the file.
Most compilers do not rewind the namelist file when reopening, so there is no cycling of the file to find the right group.
The iostat command happens to only be in use to trap bad lines in this case.
But NAG rewinds the file, so it's trapping the "line" error during normal cycling. I think there are three possible options to move things forward,
Keep the current implementation which has some (but not all) required order of the namelist groups and document that.
Generalize the implementation, so there is no required order. That would mean we'd have to rewind the namelist file anytime we open it and we'd have to cycle thru the groups (as we do now for some of the groups) until we find the right one for all namelist groups.
Formalize the order of all namelist groups. To do this robustly, we'd want to open the namelist file once and leave it open. The groups would have to always be in a particular order from start to end. We would document this.
Only option 3 will allow us to trap and write a bad line in the namelist group. With option 1 or 2, we'd need to use the iostat to cycle thru the groups and we couldn't trap an error on a single line of the group... unless we check the iostat value and are able to robustly determine that certain values mean certain things and that it's uniform across all compilers. I don't think the iostat values are consistent across compilers.
Maybe there are other options. How should we proceed in terms of options 1, 2, or 3 at this point? We probably want to fix this soon-ish, even if that only means reverting back to what we had before (option 1) since the code is broken on NAG at the moment.
Let me clarify something based on more debugging. My guess now is that most compilers do rewind the namelist file when they reopen. In fact, I think they read from the top of the namelist every time they read a namelist group. I think what they're really doing is reading thru the file from the start until they come to the correct namelist group. That happens internally and automatically and is pretty handy. While NAG follows strict protocols and returns if the namelist group isn't the next group with an iostat error and expects CICE to handle checking whether the group has been read successfully and if not, continue to read the file or abort. So, we need to code to NAG even if most compilers are more clever. I don't think this changes our options.
Recent changes to the CICE namelist implementation to trap bad namelist inputs is failing with the NAG compiler. After some debugging, this comes down to a few issues
The new feature that was added to trap bad namelist lines happens to work on most compilers because
But NAG rewinds the file, so it's trapping the "line" error during normal cycling. I think there are three possible options to move things forward,
Only option 3 will allow us to trap and write a bad line in the namelist group. With option 1 or 2, we'd need to use the iostat to cycle thru the groups and we couldn't trap an error on a single line of the group... unless we check the iostat value and are able to robustly determine that certain values mean certain things and that it's uniform across all compilers. I don't think the iostat values are consistent across compilers.
Maybe there are other options. How should we proceed in terms of options 1, 2, or 3 at this point? We probably want to fix this soon-ish, even if that only means reverting back to what we had before (option 1) since the code is broken on NAG at the moment.
@dabail10, @eclare108213 @daveh150 @phil-blain
The text was updated successfully, but these errors were encountered: