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

Dimitris Menemenlis menemenlis at jpl.nasa.gov
Wed May 6 13:08:53 EDT 2009


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




More information about the MITgcm-devel mailing list