-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fastice #52
Fastice #52
Conversation
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) I will include these in my next version of the code (with units for Cbu). |
Thanks @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. |
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 |
I noticed that the default ice_in comes out with dumpfreq = 'd'. Do we want this to be the default? Dave |
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 |
Ok. I am running a control with basalstress = .false. to compare to. Is the gx1 default bathymetry set up with some shallow areas? |
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. |
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. |
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. |
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. |
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... |
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... |
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>
.
|
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? |
@kshedstrom I don't think this is your fault. kmt wasn't in the landfast code that JF provided; I added it. |
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. |
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? |
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
|
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..... |
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
* new subroutines stepu_Cgrid and stepv_Cgrid * Corrected compilation errors
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:
Still needs to be done:
Is there history output specific to this parameterization? How do you identify fast ice in the output?