[MITgcm-devel] another diagnostics puzzle
Martin Losch
Martin.Losch at awi.de
Thu Jun 7 12:06:28 EDT 2007
Hi Jean-Michel,
I don't understand.
1. seaice state variables: AREA, HEFF, HSNOW, UICE, VICE, these
should be filled in do_statevars_diagnostics, that is at the
beginning of the time step?
2. all others: uwind, vwind, fu, fv, empmr, qnet, qsw, they are
modified by seaice (except for u/vwind) and should probably be filled
at the end of seaice_model
sigI, sigII, press, zeta, eta belong directly on the state variables
and should be filled at the same time at the state variables,
otherwise they would be staggered and would correspond to the next
time step, right?
Does it make sense to move seaice_diagnostics_fill.F from
do_statevars_diags.F to the beginning of seaice_model, then move
diagnostics_fill of wind, vwind, fu, fv, empmr, qnet, qsw to the end
of seaice_model (maybe even without an extra subroutine, because it's
just calling diagostics_fill?
Martin
On 7 Jun 2007, at 17:27, Jean-Michel Campin wrote:
> Hi Martin,
>
> I've just had a quick look at this new S/R: SEAICE_DIAGNOSTICS_FILL
> and my impression (did not run any test) is that it will
> work very well for state variables (which are in the pickup_seaice),
> but not so well for all the others (annoying ...).
> Note that this time, and contrary to state-vars, they could stay
> in seaice_do_diags but filled only if myIter.NE.nIter0,
> (not very "clean" from my point of view ...).
>
> Why not a short S/R called directly from SEAICE_MODEL
> (towards the end), that would take care of them.
>
> I don't see any standard name for this king of S/R:
> pkg/thsice has a thsice_ave.F (but I don't like too much
> the name), aim_v23 has a aim_diagnostics.F (certainly not better),
> gmredi has a gmredi_diagnostics_fill (called from gmredi_calc_tensor),
> KPP seems to be like seaice (not so good).
>
> What would you propose ?
>
> Jean-Michel
>
> On Thu, Jun 07, 2007 at 09:51:04AM +0200, Martin Losch wrote:
>> Hi Jean-Michel,
>> this was exactly my suspicion last night, as I was lying awake
>> worrying about my diagnostics. I will create a
>> seaice_diagnostics_fill.F and put in do_statevars_diags.F as it is
>> done the thsice, if that's OK with you.
>>
>> Martin
>>
>> On 7 Jun 2007, at 01:20, Jean-Michel Campin wrote:
>>
>>> Hi Martin,
>>>
>>> OK, I can confirm my suspicion.
>>> What I did not realize, is that it was only the 1rst output
>>> (because I did not read carefully your 1rst e-mail), but now
>>> everything make sense, since DO_THE_MODEL_IO is also
>>> called from INITIALISE_VARIA.
>>> And you don't see the double counting in SIuice,SIvice
>>> because they are initialised to zero.
>>>
>>> I use this "hack" to get the right 1rst snap-shot:
>>> pkg/seaice/seaice_do_diags.F, around line 384:
>>>
>>> 383 #ifdef ALLOW_DIAGNOSTICS
>>> 384 c IF ( useDiagnostics ) THEN
>>> 385 IF ( useDiagnostics .AND. myIter.NE.nIter0 ) THEN
>>>
>>> but it is not the "right" thing to do (therefore, I am not
>>> going to check-in this), since we still have this famous
>>> "1 time-step" shift mismatch.
>>>
>>> Jean-Michel
>>>
>>> On Wed, Jun 06, 2007 at 05:03:14PM -0400, Jean-Michel Campin wrote:
>>>> Hi Martin,
>>>>
>>>> What I suspect is that the seaice state-variable diagnostics
>>>> are filled from the wrong place, meaning from do_the_model_io.F ;
>>>> If I compare with what is done in pkg/thsice,
>>>> do_the_model_io.F calls thsice_output (snap-shot but no
>>>> diagnostics)
>>>> but thsice_diagnostics_fill (state-variable) is called
>>>> from do_statevars_diags.
>>>>
>>>> it would be better to do it in the same (right) way;
>>>> might find a way to go arround this by adding some if/conditions
>>>> in seaice_do_diags but I don't have time right now
>>>> to try different possible hack.
>>>>
>>>> I will do a short test to confirm that this is the cause
>>>> of this problem (since it's still not completely clear to me).
>>>>
>>>> Jean-Michel
>>>>
>>>> On Wed, Jun 06, 2007 at 05:41:09PM +0200, Martin Losch wrote:
>>>>> Hi Andrea and others,
>>>>>
>>>>> the if statement is only there for
>>>>> SIsigI,SIsigII,SIpress,SIzeta,SIeta.
>>>>> All others don't have one. I have put an if-statement before the
>>>>> SIhsnow call, but that does not change anything.
>>>>>
>>>>> the diagnostics_status-files don't tell me much, except that the
>>>>> three fields in question are the first three fields in my list of
>>>>> diagnostics, but the order doesn't matter (I tried with a
>>>>> different
>>>>> order and the result is the same).
>>>>>
>>>>> Oh, and an important detail was missing: I use a negative
>>>>> frequency
>>>>> (that is -1 in my test case by before I was trying much longer
>>>>> intervals, eg. frequency = -21600) to get snap shots. for
>>>>> averaging,
>>>>> the output is OK.
>>>>>
>>>>> Martin
>>>>> PS I'll attach the two diagnostics_status files, maybe you can see
>>>>> something there:
>>>>
>>>>
>>>>
>>>>>
>>>>> On 6 Jun 2007, at 17:13, Andrea Molod wrote:
>>>>>
>>>>>> hi martin,
>>>>>>
>>>>>> On Wed, 6 Jun 2007, Martin Losch wrote:
>>>>>>
>>>>>>> I am seeing a strange behavior of the diagnostics package for
>>>>>>> seaice:
>>>>>>> When I use averaging (only) the first field that is written
>>>>>>> (both
>>>>>>> by mnc and mdsio) is wrong (by a factor of 2, I only noticed
>>>>>>> because my AREA was suddenly 2 instead of 1=max(AREA)). This is
>>>>>>> true for Siarea,SIheff,SIhsnow, but not for
>>>>>>> SIuice,SIvice,SIpress,
>>>>>>> etc. I don't recognize a pattern in this, do you?
>>>>>>
>>>>>> the ones that are ok have an if-loop around the 'fill' sequence
>>>>>> (call diagnostics_fill....) checking whether 'diagnostics_is_on',
>>>>>> the ones that
>>>>>> are not ok don't. i don't know about your configuration,
>>>>>> etc... but
>>>>>> there
>>>>>> are a few reasons why the diagnostics gets turned 'off'
>>>>>> temporarily
>>>>>> during
>>>>>> the run. i bet if you put that call (if diagnostics_is_on(...) )
>>>>>> in there
>>>>>> the behavior will be ok.
>>>>>>
>>>>>> my 2 cents.
>>>>>>
>>>>>> andrea
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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
More information about the MITgcm-devel
mailing list