[MITgcm-devel] seaice code beyond checkoint61j blows for ECCO-GODAE

Thu May 7 02:16:04 EDT 2009

Hi Dimitris,

great news!
1. We don't need to repeat the runs for the ceaice_paper
2. the new code with metric terms seems to work for a least a few years

I would really like to get to the bottom of the blow-ups. As far as I  
can see they are all with free-slip boundary conditons  
(SEAICE_no_slip=.false.). Correct? (Patrick?)
If that's the case, then I would change the implementation of the free  
slip BC (include the masking of etaMeanZ).

M.
On May 6, 2009, at 7:08 PM, Dimitris Menemenlis wrote:

> Martin, An produced following movie
> http://ecco2.jpl.nasa.gov/data1/meeting/2009/05_05/ATN_ice_metric_JRA25.mpeg
> comparing HEFF for integrations with (top-left) and without (bottom- 
> right) metric terms.
> As you expected the difference is very small.  D.
>
> On Apr 14, 2009, at 3:49 AM, Martin Losch wrote:
>
>> Hi Patrick,
>>
>> that's awful.
>>
>> I changed many things between these checkpoints and not all of them
>> actually improved the stability.
>> 1. There were a few bugs with the metric terms that I tried to fix.
>> These were clearly bugs and I suspected them to be reason that the
>> seaice model kept blowing up on my various lat/lon configurations.
>> However, even after these bugs were fixed (hopefully) the solver  
>> still
>> did not converge occasionally, so that that was no practical
>> improvement. I think that issue was, that with the code and
>> discretization adapted from the old B-grid code (all my fault, I
>> admit) it was very difficult to get a truly symmetric discretization.
>> This made me move to a fresh start for the solver. (To get this
>> discretization turn on the "old_and_bad_discretization" flag, still
>> these changes change the results)
>> 2. Finite-Volume discretization: This is clearly the one change that
>> stabilized the solver on lat/lon grids. I tested it on a 2deg global,
>> a .5deg Weddell Sea and a .25deg Arctic domain. All of these
>> integrations blew up sooner or later without too much prelude earlier
>> and all of these integrations are now stable for as long as we run
>> them (the .25deg runs for the entire CORE period, 46years). I do not
>> know if Dimitris has gotten around to test this on CS-or curvilinear
>> grids. There is a flag that turns off the metric terms in all cases,
>> maybe you want to test that.
>> 3. defaults: There have been modifications of defaults, and as  
>> usual I
>> was probably not careful enough. I tried to document them all (from
>> tag-index):
>>  - ALLOW_FLOODING is defined and turned on by default
>>  - SEAICE_advSnow = .true. is now the default
>>  - SEAICE_advSalt = .true. is now the default
>>  - SEAICE_advAge  = .true. is now the default
>>  - SEAICE_clipVelocities  = .false. is now the default
>>                                     (as per J. Zhang's  
>> recommendation)
>>  - B-grid, and thus not tested: SEAICE_TEST_ICE_STRESS_1/
>> EXPLICIT_SSH_SLOPE
>>    is defined, SEAICE_TEST_ICE_STRESS_1 is renamed into
>> SEAICE_BICE_STRESS
>>  - seaice_growth: replace computation of UG by a simple copy from
>> wspeed
>> Most of these changes are sensible and should have been used in all
>> seaice integrations (e.g. advSnow). Of these changes I suspect that
>> the SEAICE_clipVelocities flag and ALLOW_FLOODING (unless you usually
>> have that turned on anyway should have the most effect on you adjoint
>> computations. Setting UG=wspeed instead of recomputing should be  
>> benign.
>>
>> Martin
>>
>> On Apr 13, 2009, at 11:07 PM, Patrick Heimbach wrote:
>>
>>>
>>> Hi there,
>>>
>>> I've update the seaice code from checkoint61j to latest,
>>> and the ECCO-GODAE production now blows up about 1/3rd into
>>> the calculation (i.e. after roughly 5 years of integration).
>>>
>>> I have double-checked that reverting only(!) pkg/seaice back to c61j
>>> gives back stable code.
>>> I have done this for current iter. 73, not yet iter. 0.
>>>
>>> (At least) two possibilities:
>>> 1.
>>> optimization compensated for some seaice errors that are no longer
>>> there,
>>> and therefore adjusted forcing causes the blow-up
>>> 2.
>>> new seaice code has problems.
>>> 3.
>>> Some parameter setting defaults have changed,
>>> which I've missed (if so, we should start a mechanism to document
>>> that,
>>> not just for seaice).
>>>
>>> What's a bit disconcerting is that it seems the old code was more
>>> stable than the new code(?)
>>>
>>> I will try an iter.0 run later.
>>> In the mean time, any suggestions?
>>>
>>> Cheers
>>> -p.
>>>
>>> ---
>>> Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>>> MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
>>> FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
>>>
>>>
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> Dimitris Menemenlis <menemenlis at jpl.nasa.gov>
> Jet Propulsion Lab, California Institute of Technology
> MS 300-323, 4800 Oak Grove Dr, Pasadena CA 91109-8099, USA
> tel: 818-354-1656;  cell: 818-625-6498;  fax: 818-393-6720
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel