[MITgcm-devel] another diagnostics puzzle
Jean-Michel Campin
jmc at ocean.mit.edu
Thu Jun 7 12:41:41 EDT 2007
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
More information about the MITgcm-devel
mailing list