Skip to content
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

Namelist implementation issues #676

Closed
apcraig opened this issue Dec 20, 2021 · 1 comment · Fixed by #677
Closed

Namelist implementation issues #676

apcraig opened this issue Dec 20, 2021 · 1 comment · Fixed by #677
Assignees

Comments

@apcraig
Copy link
Contributor

apcraig commented Dec 20, 2021

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,

  1. Keep the current implementation which has some (but not all) required order of the namelist groups and document that.
  2. 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.
  3. 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.

@dabail10, @eclare108213 @daveh150 @phil-blain

@apcraig
Copy link
Contributor Author

apcraig commented Dec 20, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant