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

ice_calendar: zero-initialize 'nstreams' #752

Merged
merged 1 commit into from
Aug 17, 2022

Conversation

phil-blain
Copy link
Member

@phil-blain phil-blain commented Aug 17, 2022

PR checklist

  • Short (1 sentence) summary of your PR:
    title
  • Developer(s):
    me
  • Suggest PR reviewers from list in the column to the right.
  • Please copy the PR test results link or provide a summary of testing completed below.
    I checked that the code runs fine with the fix when compiling with -init=huge. It crashes without the fix.
    I ran the base, decomp and nothread suites with the fix and -init=huge and everything passed as expected.
  • How much do the PR code changes differ from the unmodified code?
    • bit for bit
    • different at roundoff level
    • more substantial
  • Does this PR create or have dependencies on Icepack or any other models?
    • Yes
    • No
  • Does this PR add any new test cases?
    • Yes
    • No
  • Is the documentation being updated? ("Documentation" includes information on the wiki or in the .rst files from doc/source/, which are used to create the online technical docs at https://readthedocs.org/projects/cice-consortium-cice/. A test build of the technical docs will be performed as part of the PR testing.)
    • Yes
    • No, does the documentation need to be updated at a later time?
      • Yes
      • No
  • Please provide any additional information or relevant details below:

The variable ice_calendar::nstreams, which corresponds to the number of
output history streams to use for the run, is initialized in
ice_history::init_hist depending on the number of non-'x' elements in
'histfreq' in the namelist.

However, the code does use 'nstreams' before ice_history::init_hist is
called, in ice_calendar::calendar when called from
ice_calendar::init_calendar. Both 'init_calendar' and 'init_hist' are
called from CICE_InitMod::cice_init, in that order, such that the loop
that initializes 'write_history' in 'calendar' uses 'nstreams'
uninitialized.

'calendar' ends up being called at least once more during 'cice_init', from
ice_calendar::advance_timestep, at which point 'nstreams' is correctly
defined and 'write_history' is thus correctly initialized, before its
first use in 'accum_hist'.

To avoid using 'nstreams' uninitialized in the first call to 'calendar'
from 'init_calendar', initialize it to zero in 'init_calendar' before
calling 'calendar'.

This issue was discovered by compiling using the '-init=huge' flag of
the Intel compiler.

The variable ice_calendar::nstreams, which corresponds to the number of
output history streams to use for the run, is initialized in
ice_history::init_hist depending on the number of non-'x' elements in
'histfreq' in the namelist.

However, the code does use 'nstreams' before ice_history::init_hist is
called, in ice_calendar::calendar when called from
ice_calendar::init_calendar. Both 'init_calendar' and 'init_hist' are
called from CICE_InitMod::cice_init, in that order, such that the loop
that initializes 'write_history' in 'calendar' uses 'nstreams'
uninitialized.

'calendar' ends up being called at least once more during 'cice_init', from
ice_calendar::advance_timestep, at which point 'nstreams' is correctly
defined and 'write_history' is thus correctly initialized, before its
first use in 'accum_hist'.

To avoid using 'nstreams' uninitialized in the first call to 'calendar'
from 'init_calendar', initialize it to zero in 'init_calendar' before
calling 'calendar'.

This issue was discovered by compiling using the '-init=huge' flag of
the Intel compiler.
Copy link
Contributor

@dabail10 dabail10 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch.

@apcraig apcraig merged commit fea412a into CICE-Consortium:main Aug 17, 2022
@phil-blain phil-blain deleted the init-nstreams branch August 23, 2022 15:28
dabail10 pushed a commit to ESCOMP/CICE that referenced this pull request Oct 4, 2022
The variable ice_calendar::nstreams, which corresponds to the number of
output history streams to use for the run, is initialized in
ice_history::init_hist depending on the number of non-'x' elements in
'histfreq' in the namelist.

However, the code does use 'nstreams' before ice_history::init_hist is
called, in ice_calendar::calendar when called from
ice_calendar::init_calendar. Both 'init_calendar' and 'init_hist' are
called from CICE_InitMod::cice_init, in that order, such that the loop
that initializes 'write_history' in 'calendar' uses 'nstreams'
uninitialized.

'calendar' ends up being called at least once more during 'cice_init', from
ice_calendar::advance_timestep, at which point 'nstreams' is correctly
defined and 'write_history' is thus correctly initialized, before its
first use in 'accum_hist'.

To avoid using 'nstreams' uninitialized in the first call to 'calendar'
from 'init_calendar', initialize it to zero in 'init_calendar' before
calling 'calendar'.

This issue was discovered by compiling using the '-init=huge' flag of
the Intel compiler.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants