[MITgcm-devel] another diagnostics puzzle

[Jean-Michel Campin]

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