[MITgcm-devel] another diagnostics puzzle

[Martin Losch]

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