forked from CICE-Consortium/CICE
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
cicecore: correct initial condition metadata (CICE-Consortium#818)
* ice_history_write: fix initial condition metadata under 'hist_avg'
When writing averaged history outputs (hist_avg=.true.), this setting
also affects the initial condition. Even if the actual data variables
written to the initial condition are not averaged (they are taken
more or less directly from the restart or the hard-coded defaults,
modulo aggregation over categories), their attributes ('cell_method' and
'time_rep') imply they are averaged, and the 'bound' attribute of the
'time' variable refers to the 'time_bounds' variable.
Make the metadata of the initial condition more correct by:
- not writing the 'time_bounds' variable (and the corresponding 'd2' dimension)
- not writing the 'bounds' attribute of the 'time' variable
- not writing the 'cell_method' attributes of each variable
- writing the 'time_rep' attribute of each variable as 'instantaneous'
instead of 'averaged'.
Do this by checking 'write_ic' at all places where we check for the
value of 'hist_avg' to write the above variables and attributes in each
of the 3 IO backends (binary, netcdf, pio2).
* drivers/{nemo_concepts,standalone}: write initial condition at initial time
In CICE_InitMod::cice_init, we call ice_calendar::advance_timestep
before writing the initial condition, such that the 'time' variable in
the initial condition is not zero; it has a value of 1*dt (the model
time step). The initial condition filename also reflects this, since
'msec' (model seconds) also has a value of 1*dt and is used in
ice_history_shared::construct_filename. This leads to the initial
condition filename not corresponding to the model initialization
date/time but rather 1*dt later.
Since we call 'accum_hist' after initializing the forcing, any forcing
field written to the initial condition has values corresponding to
msec=dt, whereas the ice state corresponds to msec=0, leading to an
inconsistency.
Fix that by calling 'accum_hist' to write the initial condition _before_
calling 'advance_timestep'. Since we now call 'accum_hist' before
initializing the forcing, any forcing field written to the initial
condition have its default, hard-coded value, instead of its value at
time=dt. An improvement would be to read the forcing at time=dt, write
the initial condition, advance the time step, and read the forcing
again, but let's not complicate things too much for now.
(cherry picked from commit 9a55ad9)
Cherry-pick notes:
There were some conflicts in io_{netcdf,pio2}/ice_history_write.F90 due
to 26d917a (Fix QC test, fix bug in history time axis, fix history
output averaging for timestep output (CICE-Consortium#624), 2021-08-19), since that
commit enabled averaging over multiple time steps and thus removed the
assumption that histfreq(ns) = '1' means hist_avg = .false.. I also had
to add additional changes to 'ice_history_write' in the conditions that
are checked before writing the NetCDF attributes since we do not yet
have the 'ice_write_hist_attrs' subroutine added in 078aab4 (Merge
cgridDEV branch including C grid implementation and other fixes (CICE-Consortium#715),
2022-05-10).
Rebase onto CICE6.4.1 notes:
There were some conflicts in io_{netcdf,pio2}/ice_history_write.F90 due
to the same commits mentioned above. They are both included in
CICE6.4.1, but the original cherry-picked commit (9a55ad9 (cicecore:
correct initial condition metadata (CICE-Consortium#818), 2023-03-13)) is not.
The correct resolution was thus to:
- keep ours version for calls to ice_write_hist_attrs
- cherry-pick from 9a55ad9 the changes to ice_write_hist_attrs
- in io_pio2, change 'if (hist_avg)' to 'if (hist_avg .and. .not.
write_ic)'- Loading branch information
1 parent
a8764db
commit 64f9d79
Showing
5 changed files
with
27 additions
and
24 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters