[MITgcm-devel] sea ice diagnostics

[Martin Losch]

Hi Jean-Michel,

this is what is looks like now:

https://github.com/mjlosch/MITgcm/blob/seaice_diagnostics/pkg/seaice/seaice_dynsolver.F
https://github.com/mjlosch/MITgcm/blob/seaice_diagnostics/pkg/seaice/seaice_diagnostics_state.F
(and https://github.com/mjlosch/MITgcm/blob/seaice_diagnostics/pkg/seaice/seaice_diagnostics_init.F )

what do you think? I’ll create a PR (or have my student create one for practice) if you approve of this in principle.

Martin

> On 5. May 2020, at 21:01, Martin Losch <Martin.Losch at awi.de> wrote:
> 
> Hmm, I like the fact, that the seaice diagnostics are somewhat collected in one routine. The dynamics diagnostics are about 200 lines of code, that would then appear at the end of seaice_dynsolver …
> I’ll have another look at this and will try.
> 
> Martin
> 
>> On 5. May 2020, at 20:36, Jean-Michel Campin <jmc at mit.edu> wrote:
>> 
>> Hi Martin,
>> 
>> I would think it would be simpler to move the seaice-dynamics diagnostics to seaice_dynsolver
>> (unless there is a serious issue with that);
>> the story with segFlag is more to accomodate the Ocean staggered time-stepping and
>> stay consistent with it.
>> 
>> Cheers,
>> Jean-Michel
>> 
>> On Tue, May 05, 2020 at 06:07:56PM +0200, Martin Losch wrote:
>>> Hi Jean-Michel,
>>> 
>>> thanks, that???s what I thought.
>>> I will try this: 
>>> - pass seqFlag to seaice_diagnostics_state and call only for segFlag < 2
>>> - have state variable filled for seqFlag=0
>>> - have other variables like sig1/2 and my new energy diagnostics etc filled for sigFlag=1, because they all require stress and strain, so that it???s good to have them filled together with sig1/2 (but really, it should be done in seaice_dynsolver, shouldn???t it?)
>>> - there are more energy diagnostics that require local arrays, they will be scattered in pkg/seaice 
>>> 
>>> What do you think?
>>> 
>>> M.
>>> 
>>>> On 5. May 2020, at 18:03, Jean-Michel Campin <jmc at mit.edu> wrote:
>>>> 
>>>> Hi Martin,
>>>> 
>>>> For state variable diagnostic (as well as directly derived from state vars, e.g., THETASQ),
>>>> the field is available at any time (since, as a state variable, it is supposed to be in one 
>>>> of the pickup files) and it can be useful (e.g., when doing a budget, to evaluate the
>>>> rate of change of a state variable) to have the diagnostic filled up outside
>>>> the main stepping-forward part, e.g. at the end of the time-step loop or at
>>>> the beginning of the time-step loop, as currently done from S/R DO_STATEVARS_DIAGS.
>>>> 
>>>> But for other intermediate variables, it's better (and easier) to fill-up their 
>>>> diagnostics from where they are computed. And it avoids the problem of filling
>>>> up with zero because they have not been computed yet.
>>>> And regarding pkg/seaice, there are some diagnostics currently filled-up from 
>>>> seaice_diagnostics_state.F that should not be there, but for some other like
>>>> SIsig1 & SIsig2, it's not very clear since it depends in using EVP or not
>>>> (but could have those filled up from different places depending on SEAICEuseEVP).
>>>> 
>>>> Cheers,
>>>> Jean-Michel
>>>> 
>>>> On Tue, May 05, 2020 at 01:38:08PM +0200, Martin Losch wrote:
>>>>> Hi Jean-Michel, and others,
>>>>> 
>>>>> we are working on mechanical energy diagnostics for the sea ice model (following Bouchat and Tremblay 2014).
>>>>> 
>>>>> While doing so I realized that maybe the diagnostics of seaice are not in the right place:
>>>>> seaice_diagnostics_state is called from do_statevars_diags when ???seqFlag=0???. this is probably OK for fields like HEFF, AREA, UICE, VICE, but not for derived quantities like SIzeta, SIeta, SIdelta, because they are all 0 in the first time step (after a pickup, say). With that all of SIsig1/2, etc are also not correct because they require zeta/eta from the previous iteration. The same is true for (some of) the energy diagnostics.
>>>>> 
>>>>> I am not sure what the correct philosophy is here. The model state variables (diagnostics_fill_state) are all computed at the beginning of the time step, but not always, so it???s a bit difficult for me to diagnose, when what type of variable should be passed to diagnostics_fill.
>>>>> 
>>>>> Could you give me some advice?
>>>>> 
>>>>> Martin
>>>>> _______________________________________________
>>>>> MITgcm-devel mailing list
>>>>> MITgcm-devel at mitgcm.org
>>>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org
>>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
>>> 
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel