Modified CICE to support RASM coupling

[apcraig]

Modify CICE to support RASM coupling

• Developer(s): tcraig

• Please suggest code Pull Request reviewers in the column at right.

• Are the code changes bit for bit, different at roundoff level, or more substantial?

• Is the documentation being updated with this PR? (Y/N)
  If not, does the documentation need to be updated separately at a later time? (Y/N)
  Note: "Documentation" includes information on the wiki and .rst files in doc/source/,
  which are used to create the online technical docs at https://readthedocs.org/projects/cice-consortium-cice/.

• Other Relevant Details:

Update and verify pio interfaces.
Add spiralcenter and wghtfile decompositions.
Update and verify mct coupling interfaces.
Move to single ice_constants file with init and query methods, coupling interfaces sets the constants to be consistent with RASM shr constants.
Add new check for continue mode and none/default ic.

[eclare108213]

In ice_init.F90:

! tcx tcraig added, is this correct?
if (trim(runtype) /= 'continue' .and. ice_ic == 'none' .or. ice_ic == 'default') then

Yes, this is correct. The code currently is (or is supposed to be) set up so that if it's not a continuation run then the restart flags in namelist don't matter, i.e. the runtype flag takes precedence. In the logic above, I think you need parentheses around the ice_ic '.or.' parts, otherwise different compilers might interpret the and/or in different orders.

Looks like there's more new stuff to add to the docs, e.g. 2 new distributions and ICE_CONSTOPT

[apcraig]

The documentation is updated. Mostly, under the implementation performance section. The new documentation can be see here, https://apcraig-cice.readthedocs.io/en/rasma/user_guide/ug_implementation.html#performance. I have updated the decomposition description a bit.

If travis passes, which it should, I think this is ready. Just let me know if you have other changes.

[eclare108213]

This looks okay to me. As I understand it, the values of the constants in ice_constants.F90 are now defaults, and other drivers like cesm or hadgem can reset them using the query/init interface, but they are currently not available in namelist. What is CESM/RASM's preferred method for entering 'SHR_CONST' parameters?

For the record, here are the differences between cice, cesm and hadgem3 constants files:

pn1614351:constants eclare$ diff cice/ice_constants.F90 hadgem3/ice_constants.F90
20,21c20,21
< omega = 7.292e-5_dbl_kind ,&! angular velocity of earth (rad/sec)
< radius = 6.37e6_dbl_kind ! earth radius (m)

     omega     = 7.292116e-5_dbl_kind,&! angular velocity of earth (rad/sec)
     radius    = 6.371229e6_dbl_kind   ! earth radius (m)

pn1614351:constants eclare$ diff cice/ice_constants.F90 cesm/ice_constants.F90
20,21c20,21
< omega = 7.292e-5_dbl_kind ,&! angular velocity of earth (rad/sec)
< radius = 6.37e6_dbl_kind ! earth radius (m)

     omega     = SHR_CONST_OMEGA ,&! angular velocity of earth (rad/sec)
     radius    = SHR_CONST_REARTH  ! earth radius (m)

24c24
< spval_dbl = 1.0e30_dbl_kind ! special value (double precision)

     spval_dbl = SHR_CONST_SPVAL    ! special value

120a121,125

#ifndef USE_ESMF
integer (kind=int_kind), parameter :: &
ESMF_SUCCESS = 0 ! otherwise ESMF defines this parameter
#endif

[eclare108213]

@apcraig @dabail10, would one of you please answer this question? I'd like to know whether it makes sense to move these SHR constants into namelist, if they aren't already there.

the values of the constants in ice_constants.F90 are now defaults, and other drivers like cesm or hadgem can reset them using the query/init interface, but they are currently not available in namelist. What is CESM/RASM's preferred method for entering 'SHR_CONST' parameters?

[apcraig]

The constants do not have to be moved to namelist. It might be worth doing for internal testing, if we really care, but any coupling interface will have access to the share code in their model and the constants need to be set by calls to icepack/ice "init" interfaces. In other words, CESM would not use the namelist even if CICE had it because the constants have to come from share code. Adding namelist would just be a feature that might or might not be used by others.

When I looked at the constants diffs in the original code (noted above), they were so minimal that I saw no reason to worry about supporting a full set of constants via namelist at that time. But we could do that if it were desired.