Fastice

[eclare108213]

Fast-ice parameterization (merged from JF's fork)
Developer(s): Jean-Francois Lemieux, Fred Dupont
Updated documentation (Y/N): N
Results (bit for bit, roundoff, climate changing): BFB
Code review:
Other Relevant Details:
JF's fork had conflicts with the main repository due to changes after his PR, so I merged them into my fork so that I could fix them. I will close his PRs. Tested tensile changes separately (in tensile branch), then merged full fastice branch. Ran base_suite and also a 1-year gx3 test with standard parameter settings. The usual tests fail.

Modifications from JF’s version:

• changed the namelist flag from l_basalstress to basalstress
• moved read_basal_bathy to ice_grid.F90, for safe-keeping, but it is not called. I don’t have the file this routine reads, so I created a default bathymetry to go with the gx3, gx1 grids using POP’s 40-level vertical grid. Bathymetric input should be included with individual grids, henceforth.
• created set_nml.basal for testing the basalstress option.
• removed JF's hard-wired path directories from ice_in. This should work correctly now, if the data is put into the location specified in the machine file (env.fram).

Still needs to be done:

• add units to Cbu declaration in the code
• replace hwater with bathymetry (are they the same units, i.e. m?)
• add POP's 40-level vertical grid to standard grid info that is read in?
• How should Ktens and e_ratio be set in set_nml.basal? Are other namelist changes needed for this test?
• add documentation for Ktens, e_ratio, basalstress, and the entire fast ice parameterization

Is there history output specific to this parameterization? How do you identify fast ice in the output?

[JFLemieux73]

I prefer to keep hwater instead of bathymetry. In stand-alone mode, the water depth is fixed and equal to the bathymetry. However, in coupled mode (as we now do with our CICE-NEMO configs), it is better to include ocean dynamics for the water (i.e. hwater = ssh + bathymetry, units of ‘m’).

Thanks for creating the bathymetry file from POP. Note that grounding is effective for hwater < 20-25 m. The bathymetry file I use for my simulations has a minimum depth of 5 m (so grounding will be effective between 5 – 25 m).

If you want to test only the basalstress, then you should keep the standard values for Ktens (0.0) and for e_ratio (2.0). By the way, feel free to change the names of these two if you think other names would be more appropriate.

We could output the components of the basalstress. They could be calculated at the end of stepu:

tau_bu(i,j) = Cbu(i,j)*uvel(i,j)
tau_bv(i,j) = Cbu(i,j)*vvel(i,j)

I will include these in my next version of the code (with units for Cbu).

[eclare108213]

Thanks @JFLemieux73
The code is set up now to input bathymetry (currently hardwired data, not a file), and then hwater is set equal to it, but we can keep hwater as a separate variable so that ssh can be taken into account too. There are a couple of levels less than 25m, so we should have grounded ice appear in our gx3 runs. I would like someone (@JFLemieux73 or @dabail10 or anyone else) to run this test and make sure that we get grounded ice. Then I can merge this PR so that @JFLemieux73 can continue working on the code.

[JFLemieux73]

I already tested it with a very simple bathymetry file from the gx3 grid. I set everything to 1000 m except close to the Siberian Coast where the depth was set to 5 m. The grounding was working.

If we want to verify with the POP bathymetry, a simple way to enhance grounding is to increase k1 (set to 8 for the moment). We could set it to 20 for example.

[dabail10]

Running this now for a year. I am running a gx1 test. So, the bathymetry is just uniform except for the Siberian coast for the gx1 as well? Not sure if I should be expecting fast ice or not.

Dave

[dabail10]

I noticed that the default ice_in comes out with dumpfreq = 'd'. Do we want this to be the default?

Dave

[JFLemieux73]

Hi Dave,

I am also running the test right now.

I will soon add the basal stress in the outputs so it will be easy to see if there is landfast ice simulated. In the mean time you could look at the velocity field. The ice velocity should be very small in shallow regions (in winter) compared to the standard run (no grounding).

jf

[dabail10]

Ok. I am running a control with basalstress = .false. to compare to. Is the gx1 default bathymetry set up with some shallow areas?

[eclare108213]

I'm glad you are both running this! Dave, I hard-wired POP's 40-level vertical grid in ice_grid.F90 and created a 2D bathymetry field by combining it with the read-in kmt values. I did not look to see if it actually worked correctly, only that it ran. The top couple of levels in POP's vertical grid are less than 25m, I think, so you should have shallow enough areas to get fast ice. Please take a look at that. I think we ought to include the bathymetry field (or the vertical grid) as part of our input grid files, rather than having it hard-wired, I just didn't have the cycles to do that myself.

[eclare108213]

The defaults in ice_in are currently set up for smoke tests, but I think these ought to be set the way we would need them for a typical single-run case, i.e. more or less the same as in the v5.1.2 release. Then for the test suite we can put the changed values into the env_nml files. We need to do a "big picture" evaluation of all of these test cases and the default namelist, knowing that users will use them as guidance for configuring the code.

[JFLemieux73]

Ok I was able to get grounding. It didn't work the first time because hwater was set to 10000 m in init_coupler_flux (which comes after init_grid2 where we read the bathymetry).

I also modified the code to output the basal stress.

[dabail10]

Aha. That explains why my two cases are bfb. I'll change that and rerun. I am still testing using the hard coded bathymetry Elizabeth put in.

[JFLemieux73]

Ok I also tried with Elizabeth's bathymetry. I get grounding at many places...I had a quick look and it seems the bathymetry is 10 m everywhere. You might get ice almost completely stopped in late winter in the Arctic...

[eclare108213]

Just looking at the code, it's possible that the kmt field being read in is only a landmask, either 0 or 1, but the original POP version has kmt = the number of ocean levels. Is this the problem? Otherwise, I don't see it. I could get out the debugger...

[kshedstrom]

Is this my fault? I was using kmt for the land mask when coupling to a model with a 2-D land mask. I don't get depth via kmt.

…

On Wed, Dec 20, 2017 at 12:13 PM, Elizabeth Hunke ***@***.***> wrote: Just looking at the code, it's possible that the kmt field being read in is only a landmask, either 0 or 1, but the original POP version has kmt = the number of ocean levels. Is this the problem? Otherwise, I don't see it. I could get out the debugger... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbIHoHH4-9hoNA6TalOBB7rCpcmJ5UKks5tCXiVgaJpZM4REhST> .

[JFLemieux73]

Just at a quick look. I think in get_bathymetry, it should be depth = thick instead of depth(1) = thick(1). Does it make sense?

[eclare108213]

@kshedstrom I don't think this is your fault. kmt wasn't in the landfast code that JF provided; I added it.
I checked that the kmt field in the netcdf file has values larger than 1. The line depth(1)=thick(1) is just initializing the first value, then the following loop (k=2,...) adds the levels together to convert level thickness to total depth.

[eclare108213]

This version should work better. We might want to initialize hwater, separately from the bathymetry calculation -- I just took the 10K initialization out, for now.

[dabail10]

So, I am happy to approve this at this point. However, what is the plan for reading the bathymetry or not? Does that come in for a different PR?

[eclare108213]

I’ve made some more changes and am waiting for my job to get through the queue. I’ll go ahead and push them now so you can take a look. JF sent a file for the bathymetry that we could read in instead of POP’s. I haven’t looked at that yet. I suggest a separate PR for that one (not mine!) Thanks, e

[eclare108213]

My run might be stuck in the queue for a while. Please take a look at the latest commit, where I added JF's history and moved hwater (again). Thanks.....

[JFLemieux73]

Elizabeth,

The file I sent is just for testing...it does not give a realistic bathymetry. It is deep everywhere except for a few grid cells on the Russian coast.

I will have a look at the latest code tomorrow morning.

thanks
jf

[dabail10]

This is giving the results I would expect with it turned on or off. I have done a one-month run with and without the basalstress and added the taubx and tauby fields to my history successfully. I agree for the next PR, we should read in the bathymetry directly.

[eclare108213]

Thanks Dave and JF. We can use the hard-wired bathymetry for now, but I think we'll want to add it to our input files so that we have guidance in place for other grids being used outside the Consortium itself (like yours, JF). I'll go ahead and merge this now, and if you find issues when your test it tomorrow from the main repo, you can submit changes using your own fork. I'm not sure how connected I will be.