Add grounding scheme and tensile strength.

[JFLemieux73]

• l_basalstress logical flag to use the grounding scheme (false by default)

• isotropic tensile strength can be specified in ice_in (Ktens variable).

• the ellipse ratio (uniaxial tensile stength) can also be modified in ice_in (e_ratio).

[apcraig]

This looks like it might change answers, even with the new feature turned off. There are some new adds/multiply/divides, even with 0s and 1s, answers might changes. Also, ice_dyn_shared.F90 line 187-188, definining ecc and ecci look very different.

What kind of testing has been done and has anyone confirmed this does not change answers when basalstress is off? If it does change answers, do we understand why and are those changes acceptible?

[JFLemieux73]

Hi everyone,

I have compared the code before the changes and the new code with basalstress off, Ktens=0 (no tensile strength) and e_ratio=2. These settings are equal to the standard model in the old code.

I ran both cases on my desktop machine (gx3 grid, 1 day simulation). I got exactly the same answers after the 1 day simulations (I checked uvel, vvel and hi).

Note that we use this code (for the fast ice) in our operational systems. When we implemented it, we observed small differences between the old and the new code due to the multiplications by 1s. The differences were on the order of machine precision. These operational systems run on a power7. I don’t know why we get these very small differences on the power7 while I get exactly the same answers on my desktop.

If you think I should do more tests please let me know.

JF

[eclare108213]

Is it possible to separate your modifications (for PR purposes) into those that change the answers in the default configuration and those that don't? That way, it's more explicit what's happening. Also, during the code review we can formally ask the question whether the mods that change the answers are really necessary, and if we want them then we can do the appropriate tests to make sure that they don't change the 'climate' of the model (if indeed they shouldn't).

This is a part of the testing process that we haven't completely mapped out for the consortium, and this is an excellent test case for figuring out how to do that. Thanks

[eclare108213]

@mattdturner @apcraig @proteanplanet @dabail10
JF and I have just talked about this on the phone. There are two types of changes, unfortunately all in the same modules: putting parameters to control the ellipse ratio and tensile strength into namelist, which introduces bit-changing multiplies, and introduction of a new basal stress parameterization for simulating fast ice, which is wrapped in an on/off flag and should be BFB.

JF can separate these onto different branches, for testing.

Our testing scripts should already be set up to test the BFB basal stress. This is an opportunity to see how well that works (setting up a baseline, changing the code, then comparing with the baseline). JF can try this on his machines, and I'll try it on one of the LANL machines (mainly to learn how to do it).

The non-BFB tests are the challenge. We can run a comparison against the baseline, which we expect will fail. Then what? @dabail10 how does CESM determine that a non-BFB change is okay? Can we implement a formal test for this, or is it case-by-case?

[proteanplanet]

Hi Elizabeth et al. I’d like to chime in from a RASM perspective, as this scenario was encountered a lot when implementing CICE5/ColPkg. The standard we took was that if a non-BFB change cannot possibly be avoided, but the science should not change, then there must be no statistically-significant climatological change in the model at every grid point. In our case, we applied this either over a decade or thirty years, and were careful in the way we calculated the statistical confidence limits, with either hourly or daily sub-samples and the sample size adjusted for time series correlation. I cannot think of a single case in RASM where this test failed and we did not then find a science-changing reason for the failure. - Andrew

…

On Oct 3, 2017, at 11:33 AM, Elizabeth Hunke ***@***.***> wrote: @mattdturner <https://github.com/mattdturner> @apcraig <https://github.com/apcraig> @proteanplanet <https://github.com/proteanplanet> @dabail10 <https://github.com/dabail10> JF and I have just talked about this on the phone. There are two types of changes, unfortunately all in the same modules: putting parameters to control the ellipse ratio and tensile strength into namelist, which introduces bit-changing multiplies, and introduction of a new basal stress parameterization for simulating fast ice, which is wrapped in an on/off flag and should be BFB. JF can separate these onto different branches, for testing. Our testing scripts should already be set up to test the BFB basal stress. This is an opportunity to see how well that works (setting up a baseline, changing the code, then comparing with the baseline). JF can try this on his machines, and I'll try it on one of the LANL machines (mainly to learn how to do it). The non-BFB tests are the challenge. We can run a comparison against the baseline, which we expect will fail. Then ***@***.*** <https://github.com/dabail10> how does CESM determine that a non-BFB change is okay? Can we implement a formal test for this, or is it case-by-case? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANtoUp2JVYch2qh9emY62EFmVozkDSAnks5son31gaJpZM4PfkMK>.

[eclare108213]

Andrew, thanks for this. I expect that RASM and CESM will both test such changes in their fully-coupled systems, but on their own timelines. So I think it makes sense to develop a test along these lines using the stand-alone CICE model. At the moment, we have the gx3 grid and 1 year of forcing, or the gx1 grid and 5 years of forcing data. Are either of those sufficient for such a test, at least to pass a first hurdle in order to merge the change into the main consortium repo?

[proteanplanet]

I think 5 years of forcing is fine, 1 year is probably fine too, but only captures a single annual cycle, which can be dangerous if trying to detect radiation code changes, for example. Due to the high autocorrelation in sea ice variable time series in a grid cell, we don’t gain much, if anything, by increasing the sample rate and decreasing the timespan. However, we’re really just trying to decipher noise from any signal at all, and I think 5 years is a good test. While not offering to code this test up myself right now, I can provide the equations needed. We should set perhaps set a pass/fail on two different confidence intervals (say, 80%, 95%). All should ideally pass, meaning that we should see no significance in any grid cells.

…

On Oct 3, 2017, at 1:54 PM, Elizabeth Hunke ***@***.***> wrote: Andrew, thanks for this. I expect that RASM and CESM will both test such changes in their fully-coupled systems, but on their own timelines. So I think it makes sense to develop a test along these lines using the stand-alone CICE model. At the moment, we have the gx3 grid and 1 year of forcing, or the gx1 grid and 5 years of forcing data. Are either of those sufficient for such a test, at least to pass a first hurdle in order to merge the change into the main consortium repo? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANtoUrfUKFVFUPIrr5m8_LABjWCJFKMiks5sop8BgaJpZM4PfkMK>.

[JFLemieux73]

I just created 3 branches (fastice, basalstress and tensile). I still have to modify the code in these. I will let you know when this is done.

-fastice will include all my changes.
-basalstress will only include the grounding scheme.
-tensile will include the ellipse ratio defined in the namelist and the Ktens parameter for shifting the ellipse (with tensile strength).

[JFLemieux73]

Ok the 3 branches are done. There is another branch (origcode_4oct2017 ) which is just the consortium code I used on October 4th to create the 3 branches.

I just did 48 h gx3 runs on my desktop machine comparing the results from the 3 branches to origcode_4oct2017. With the default settings (l_basalstress=.false., Ktens=0, e_ratio=2) I get exactly the same results.

I will now try to make some tests on a linux cluster.

Elizabeth, it would be nice if you could also test this at LANL. By the way, if we agree to add this code to the consortium code, I think it would be better to cancel this PR and do another one with the more recent fastice code (in this fastice branch).

[eclare108213]

A fresh PR #52 was created for the fast-ice parameterization with slight modifications.