[MITgcm-devel] example of pkg/layers setup for latest MITgcm
Jean-Michel Campin
jmc at ocean.mit.edu
Sun Oct 21 18:10:04 EDT 2012
Hi Ryan,
> Either way; then could you check-in the removal of these time-ave vars ?
Oups ! I did not see that you already did it.
Cheers,
Jean-Michel
On Fri, Oct 19, 2012 at 02:22:36PM -0400, Jean-Michel Campin wrote:
> Hi Ryan,
>
> On Fri, Oct 19, 2012 at 11:02:38AM -0700, Ryan Abernathey wrote:
> >
> > On Oct 18, 2012, at 8:52 PM, Jean-Michel Campin wrote:
> >
> > > Hi,
> > >
> > > I fixed the previous problem (this morning) and went to
> > > the 2nd set of changes (this afternoon).
> > > However:
> > > 1) I have not checked that everything was working OK
> > > (my old "data.layers" which was supposed to be backward
> > > compatible ended up not to be so compatible, so I gave up)
> > > so if you find something strange, let me know.
> >
> > Do you know why it broke? Was due to my changes, or Gael's, or yours? I have switched to Gael's new data.layers format and have not had any problems. But it would probably be good to maintain backwards compatibility...
>
> I ended up looking at the previous version (1.5) of layers_readparams.F
> and compare it to the new one (1.6) and saw that LAYERS_nb
> default changed from 1 to 0 (and beacuse of this, my old data.layers
> was not doing much).
>
> > > 3) Ryan, I noticed you added some time-ave arrays for the
> > > new pkg/layers fields (layers_PIw_T, layers_U_T, ...)
> > > with the corresponding filling in layers_calc.F.
> > > But I did not find where these time-ave fields were written
> > > (looks like the "write" part is missing in layers_output.F)
> > > Could you add the corresponding "write" there ? (I did not
> > > make this change because I don't know which file name to pick).
> >
> > I did forget to write the output section for these variables. But instead of adding it now, I have removed these four variables completely in my latest commit. They are now available only through the diagnostics output. They were never in previous versions, so there is no issue with backwards compatibility. Maybe this will encourage people to use the diagnostics output instead, rather than the native layers output (which I agree should eventually be phased out.)
>
> Either way; then could you check-in the removal of these time-ave vars ?
>
> Cheers,
> Jean-Michel
>
> >
> > -Ryan
> >
> > >
> > > Cheers,
> > > Jean-Michel
> > >
> > > On Thu, Oct 18, 2012 at 09:28:14AM -0400, Jean-Michel Campin wrote:
> > >> Hi,
> > >>
> > >> I realised that what I just checked-in does not compile when
> > >> one (or more) of the 3 options LAYERS_UFLUX,_VFLUX,_THICKNESS
> > >> is undef.
> > >>
> > >> I wanted to simplify further what Gael added on Sept 19
> > >> and remove the 6 dimensions (layers_maxNum) from all
> > >> the pkg/layers arrays; I though of doing this in 2 steps but will
> > >> now make these changes (and will fix also the case when one CPP
> > >> option is undef).
> > >>
> > >> Cheers,
> > >> Jean-Michel
> > >>
> > >> On Tue, Oct 16, 2012 at 03:16:04PM -0700, Ryan Abernathey wrote:
> > >>> Jean-Michel,
> > >>> I started updating my code but I never finished. I will check in my update this afternoon and then you can do your modifications. Ok?
> > >>> -Ryan
> > >>>
> > >>> On Oct 16, 2012, at 2:42 PM, Jean-Michel Campin wrote:
> > >>>
> > >>>> Hi Ryan,
> > >>>>
> > >>>> I was going to remove some un-used variables in:
> > >>>> layers_diagnostics_fill.F and in
> > >>>> layers_diagnostics_init.F (+ some cleaning for this one)
> > >>>> Do you have modified (but not yet checked in) version of these routines ?
> > >>>> and should I wait before checking-in my changes ?
> > >>>>
> > >>>> Also, I wanted to remove the option "ALLOW_LAYERS_OUTPUT"
> > >>>> so that we always compile the pieces of code for snap-shot (+ fix this)
> > >>>> and leave time-ave code just within #ifdef ALLOW_TIMEAVE.
> > >>>> This involves changing more files (but mainly fixing layers_output.F)
> > >>>> Do you prefer that I wait or can I go for this 2nd set of changes ?
> > >>>>
> > >>>> Cheers,
> > >>>> Jean-Michel
> > >>>>
> > >>>> On Wed, Sep 19, 2012 at 02:37:42PM -0700, rpa wrote:
> > >>>>> Ok cool. I am happy you guys are working on it! I think all of the changes you have made are great ideas. I will update and then incorporate my new changes in line with what you have done.
> > >>>>>
> > >>>>> The goal of my other changes is to move towards being able to calculate the momentum budget in isopycnal coordinates. The new variables are PI, which is just the heaviside function averaged in each layer: 1 if the layers exists, 0 otherwise. This is an important variable for doing thickness-weighted averages in the presence of outcropping isopycnals. The other is just V, the average velocity in each layer (NOT weighted by the thickness.) With these extra terms you can compute an approximate form of the Ertel PV flux in isopycnal space.
> > >>>>>
> > >>>>> Ross: I am very curious to hear what other changes you have in mind--perhaps we are doing the same thing. Would it be okay if you hold off on committing any new changes until I have had time to submit mine? Should only take me a day or two.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Ryan
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Sep 19, 2012, at 2:27 PM, Gael Forget wrote:
> > >>>>>
> > >>>>>> Ryan,
> > >>>>>>
> > >>>>>> sorry for the extra work it is going to take to fit your modifs in the
> > >>>>>> revised pkg/layers. The recent changes should make pkg/layers
> > >>>>>> more flexible and easier to use/augment though. So hopefully
> > >>>>>> you will not struggle too much.
> > >>>>>>
> > >>>>>> My particular motiviation was :
> > >>>>>> 1) not to have to do three runs to diagnoze three types of layers.
> > >>>>>> 2) be able to output using the diagnostics pkg (rather than the custom
> > >>>>>> timeave/layers code) consistent with what we do for anything else.
> > >>>>>> Ross had also been modifying pkg/layers to be able to compute the layer
> > >>>>>> transports online but based on time averaged uv and THETA (I think).
> > >>>>>>
> > >>>>>> The first change I did was to add the diagnostics stuff (yesterday 5pm30 EDT).
> > >>>>>> The second change I commited (yesterday 7pm02) is to add Ross' layers_calcflux.F routine,
> > >>>>>> where the 'meat' of pkg/layers was moved. layers_calc.F now mostly calls layers_calcflux.F
> > >>>>>> The third change is the one you found the CVS message for, where I added an index
> > >>>>>> ('iLa' in the code loops, with iLa.LE. layers_maxNum, as defined in LAYERS_SIZE.h)
> > >>>>>> so that one can diagnoze several cases in a single run.
> > >>>>>>
> > >>>>>> Your changes/additions make sense and I believe are largely in
> > >>>>>> line with with our thinking here. To be more explicit :
> > >>>>>> 1) the following name changes are nice
> > >>>>>> C layers_UH :: U integrated over layer (m^2/s) (used to be layers_UFlux)
> > >>>>>> C layers_VH :: V integrated over layer (m^2/s) (used to be layers_VFlux)
> > >>>>>> C layers_Hw :: Layer thickness at the U point (m) (used to be layers_HU)
> > >>>>>> C layers_Hs :: Layer thickness at the V point (m) (used to be layers_HV)
> > >>>>>> In fact you will see that the variable names used in layers_calcflux.F
> > >>>>>> and in the diagnostics are quite consistent with the new names.
> > >>>>>> 2) the following additions
> > >>>>>> C layers_PIw :: 1 if layer exists, 0 otherwise (new)
> > >>>>>> C layers_PIs :: 1 if layer exists, 0 otherwise (new)
> > >>>>>> C layers_U :: mean zonal velocity in layer (only if layer exists) (m/s) (new)
> > >>>>>> C layers_U :: mean meridional velocity in layer (only if layer exists) (m/s) (new)
> > >>>>>> sounds very close to what Ross was aiming for (as far I understand), and
> > >>>>>> I suppose he will come back to you in this regard.
> > >>>>>> 3) as far as outputing the results I would encourage you to use pkg/diagnostics
> > >>>>>> You now have a blue print in layers_diagnostics_init.F / layers_diagnostics_fill.F
> > >>>>>> and pkg/layers has several advantages (incl. cal and mnc treatments).
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>> Gael
> > >>>>>>
> > >>>>>> ps : I am moving this thread to the devel list so that it is
> > >>>>>> documented and can be followed by anyone interested.
> > >>>>>>
> > >>>>>> On Sep 19, 2012, at 4:37 PM, rpa wrote:
> > >>>>>>
> > >>>>>>> Gael,
> > >>>>>>>
> > >>>>>>> I have recently made some major changes to the LAYERS package that allow you to diagnose new variables in isopycnal coordinates. I was actually just about to email Jean Michel to ask about committing this to CVS. to I was unaware that there was any development going at at MIT. (I get the CVS emails in digest mode and usually don't read them.)
> > >>>>>>>
> > >>>>>>> Now we have to versions that are out of sync. What are you guys doing? What is the goal of the code changes? (I cannot find your explanation of the changes in the cvs digest. Would you mind emailing it to me?)
> > >>>>>>>
> > >>>>>>> -R
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Sep 19, 2012, at 1:19 PM, Gael Forget wrote:
> > >>>>>>>
> > >>>>>>>> Hi guys,
> > >>>>>>>> I commited the planned pkg/layers change to the repository.
> > >>>>>>>> I explained the revision in some details in the cvs message
> > >>>>>>>> (e.g. see the mitgcm-cvs email earlier today). In case you
> > >>>>>>>> want to give it a try, I attach the namelists I used for testing :
> > >>>>>>>> data.layers (and LAYERS_SIZE.h) sets up three types of
> > >>>>>>>> layers, and data.diagnostics sets up the output format.
> > >>>>>>>> Cheers,
> > >>>>>>>> Gael
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> <data.diagnostics><data.layers>
> > >>>>>>>> <LAYERS_SIZE.h><DIAGNOSTICS_SIZE.h>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> 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