[MITgcm-devel] another diagnostics puzzle

Thu Jun 7 11:39:10 EDT 2007

Hi there,

On Jun 7, 2007, at 11:27 AM, Jean-Michel Campin wrote:

> Hi Martin,
>
...
>
> 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 ?

Don't forget our beloved exf which has
exf_diagnostics_fill called from main routine exf_getforcing.F

-p.

> 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

---
Dr 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