Add new landfast tests

[apcraig]

See #565. We need to update the landfast tests to test multiple options and test at a time where there is some landfast ice (April). This should be done after the new time manager is merged and after we have the new ics from the long JRA55 spinup runs.

[apcraig]

@JFLemieux73 I'm looking at this now. We have new gx1 initial conditions. When I run 5 days with either April 1 or Jan 1 initial conditions, there is one point (in Antarctica) that has taubx /= 0. Is that what we expect? Is that good enough? Do we need to do a longer run that targets a particular time period where there is more landfast ice? Is there any period that is like that?

[JFLemieux73]

Hi Tony, No this is not what we expect. Are you using the gx1 bathymetry file? You should see grounding at many places. Good places to look at are the Laptev and East Siberian Seas.

[apcraig]

Thanks @JFLemieux73, I turned on the bathymetry and now am getting many more points (100s), both in the Arctic and Antarctic, so that's good. Separately, should the default landfast use "LKD" or "probabalistic"?

[JFLemieux73]

Good. For the moment I would prefer to keep LKD as the default as it has been more tested.

[apcraig]

Sounds good, thanks!

[JFLemieux73]

One question...I guess you had use_bathymetry = .false. when you had only one point with grounding, right? I think the bathymetry is too deep (more than 30 m) in this case to get grounding (the seabed stress can only be non zero if it is shallower than 30 m...see the LKD method in ice_dyn_shared).

[apcraig]

Correct, I had use_bathymetry=.false. and got only 1 point.

[JFLemieux73]

But then do we really need this capability to define the bathymetry in the code (with kmt I guess?) instead of reading a file?

[apcraig]

I agree that if landfast ice is used, the user should define the bathymetry. There seem to be two ways, one is thru a bathymetry file which is a 2d file that defines the depth at each gridcell. The other is thru the KMT where the depth of each kmt is defined. We use this in RASM using a pop depth file. It's also hardwired into the code via a 40 layer setup. I would argue we should get rid of the 40 level hardwired thing and that we should add a namelist that allows the user to define the first "n" values of depth associated with kmt as a third option. Once the depth is greater than 30m or similar, it doesn't matter to the landfast code, so we really only need the first "n" kmt thickness or depth values.

I also don't love that bathymetry_file and use_bathymetry are in the grid namelist while the seastress namelist is in dynamics. If these two settings are uniquely tied together, I think they should be in the same namelist group. Is the idea that the bathymetry might be used in some other parts of the code at some point?

[eclare108213]

The bathymetry is also useful for Icebergs, which we don't yet have in the main code (it's been under development for a while...)

[phil-blain]

Regarding the hardcoded bathymetry levels:

I looked in more details at the code and here is a summary of my understanding as to the interaction of the different namelist settings:

• Case 1: use_bathymetry = true , bathymetry_format = default: code reads bathy from NetCDF file given by bathymetry_file (subroutine get_bathymetry)
• Case 2: use_bathymetry = false, bathymetry_format = default: code computes bathy from hardcoded ocean level thicknesses (40 levels) and kmt given by kmt_file (subroutine get_bathymetry)
• Case 3: use_bathymetry = true , bathymetry_format = pop : code computes bathy from ocean level thicknesses given by POP "vert_grid" file given by bathymetry_file and kmt given by kmt_file (subroutine get_bathymetry_popfile)
• Case 4: use_bathymetry = false , bathymetry_format = pop : code computes bathy from generated thickness profile based on kmt given by kmt_file (subroutine get_bathymetry_popfile)

So the hardcoded levels are used in case 2 only. I did a quick test on the gx3 kmt file (kmt_gx3.nc) to see if it contains any cell that would trigger the landfast parameterization. Knowing that the parameterization is only active if the water depth is less than 30 m, and given the depth of the first 3 hardcoded levels,

CICE/cicecore/cicedynB/infrastructure/ice_grid.F90

Lines 2365 to 2367 in e204fb8

	real (kind=dbl_kind), dimension(nlevel), parameter :: &
	thick = (/ & ! ocean layer thickness, m
	10.01244_dbl_kind, 10.11258_dbl_kind, 10.31682_dbl_kind, &

we would need grid cells with kmt = 1 or 2 since the third level is at 30.44 and so greater than 30. A quick test:

ncap2 -s "shallow=kmt; shallow=0.0; where(kmt > 0 && kmt < 3) shallow=1"  kmt_gx3.nc test.nc

Looking at the variable "shallow" reveals that there is no such point (the variable is zero everywhere).

For gx1, the kmt file is in binary format and not NetCDF, so I can't do the same test that easily, but I ran a case with seabed_stress = .true., use_bathymetry = .false., bathymetry_format = default, and with this hack:

diff --git i/cicecore/cicedynB/dynamics/ice_dyn_shared.F90 w/cicecore/cicedynB/dynamics/ice_dyn_shared.F90
index f3685ed..93dd693 100644
--- i/cicecore/cicedynB/dynamics/ice_dyn_shared.F90
+++ w/cicecore/cicedynB/dynamics/ice_dyn_shared.F90
@@ -916,7 +916,9 @@ subroutine seabed_stress_factor_LKD (nx_block, ny_block,         &
          hwu = min(hwater(i,j),hwater(i+1,j),hwater(i,j+1),hwater(i+1,j+1))
 
          if (hwu < threshold_hw) then
-         
+        
+            print*, "IN SHALLOW WATERS, i,j = ", i, j
+
             au  = max(aice(i,j),aice(i+1,j),aice(i,j+1),aice(i+1,j+1))
             hu  = max(vice(i,j),vice(i+1,j),vice(i,j+1),vice(i+1,j+1))

which should write to the log file if there are locations where the waters are shallow enough to trigger the parameterization. There are no such locations.

I also tested the autogenerated thickness profile (Case 4 above). In this case there are several grid points where the bathymetry is shallow enough for the parameterization to be triggered (on both gx1 and gx3).

---

This is just to document the current state of affairs. I think the name of the different namelist settings, their interaction and the current implementation in code, are a little hairy and difficult to follow.... For example, I don't see why the auto-generated thickness profile is implemented in 'get_bathymetry_popfile'. It would be cleaner in a separate subroutine, and given its own namelist option. Also "use_bathymetry" should maybe be renamed use_bathymetry_from_file or something like that...)

Finally, I agree with @apcraig that we should get rid of the hard-coded levels and have the user input the thicknesses themselves. It does not have to be in the namelist, can be a separate file (like the POP vertgrid approach), but at least not having them hard-coded would be better.