ACCESS-NRI/cice5

Support for zero-layer ice

Opened this issue · 3 comments

To support single layer ice, it looks like the access coupling needs refinement:

These 5 lines try to read maicen from the mice.nc file, these fields dont exist in ESM1.5, so presumably won't be needed for ESM1.6:

!B: 20170825 ==> need maicen_saved variables
call ice_read_nc(ncid_o2i, 1, 'maicen1', maicen_saved(:,:,1,:), dbug)
call ice_read_nc(ncid_o2i, 1, 'maicen2', maicen_saved(:,:,2,:), dbug)
call ice_read_nc(ncid_o2i, 1, 'maicen3', maicen_saved(:,:,3,:), dbug)
call ice_read_nc(ncid_o2i, 1, 'maicen4', maicen_saved(:,:,4,:), dbug)
call ice_read_nc(ncid_o2i, 1, 'maicen5', maicen_saved(:,:,5,:), dbug)
!b.

These two lines reference fields not used in ESM1.5, but are presumably needed for iceberg runoff ?

!20171024: added 2 more:
call ice_read_nc(ncid_o2i, 1, 'lice_sth', lice_sth, dbug)
call ice_read_nc(ncid_o2i, 1, 'lice_nth', lice_nth, dbug)

@anton-seaice these lines are part of the CM2 iceberg scheme dave bi has written a different version for ESM1.6 which he is resting in ESM1.5. the macin looks like ice split inot categories, Dave is re-writing the coupler so I dont think it will be bring ice over in categories.

One comment @anton-seaice, its zero layer ice not single layer, we still are going to have multiple thickness categories, so I think some of lines in relation to ice categories will survive, its just how Dave merges the two code approaches. I should cross check what he is doing as some of the using the fluxes across ice categories is advantageous, and was implemented in between the UM versions that we used for ESM1.5 and CM2.

Oh good point - you are correct. These fields are ice thickness categories not layers.

Its strange ... the maicen fields dont exist in the restart here :

/g/data/vk83/experiments/inputs/access-esm1p5/modern/pre-industrial/restart/ice/mice.nc

Nor in this subroutine for cice4:

https://github.com/ACCESS-NRI/cice4/blob/4f8e2270ab17a8605296ab739d8a903140d0c367/drivers/access/cpl_forcing_handler.F90#L356

Maybe we need to generate some values for them?