[MITgcm-devel] another diagnostics puzzle

Martin Losch Martin.Losch at awi.de
Thu Jun 7 17:42:09 EDT 2007 

OK, I'll do it tomorrow.
Martin
On 7 Jun 2007, at 18:41, Jean-Michel Campin wrote:

> Hi again,
>
> You are right:
> Since all those derived fields are recomputed locally from
> the state, they are at the right place. And no need to
> move the call of seaice_diagnostics_fill out off
> do_statevars_diags.F, it's right here (called before seaice_model).
>
> regarding the 2nd set (forcing fields), it's perfectly fine to just
> fill them directly at the end of seaice_model, without a new S/R.
>
> Jean-Michel
>
> On Thu, Jun 07, 2007 at 06:06:28PM +0200, Martin Losch wrote:
>> 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
>>
>> _______________________________________________
>> 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