[MITgcm-devel] changes in pkg/layers

[Ryan Abernathey]

Jean-Michel,

I found another small bug in layers_diapycnal that I need to fix. I see
that you just made the changes we discussed above regarding the
organization of the variables. Would now be a good time for me to add my
fix?

Thanks,
Ryan

On Wed, Jun 10, 2015 at 4:01 PM, Ryan Abernathey <ryan.abernathey at gmail.com>
wrote:

> One comment:
> It might be good to add a check that complains if layers_bounds are
> assigned to phro values > 1000. This change will break many people's
> data.layers. I don't know if you want to wait until after the checkpoint or
> not...
> -Ryan
>
> On Wed, Jun 10, 2015 at 4:30 PM, Ryan Abernathey <
> ryan.abernathey at gmail.com> wrote:
>
>> Yes, sounds like a good plan.
>> Thanks,
>> Ryan
>>
>> On Wed, Jun 10, 2015 at 4:29 PM, Jean-Michel Campin <jmc at ocean.mit.edu>
>> wrote:
>>
>>> Hi Ryan,
>>>
>>> I propose to switch on the pkg/layers CPP option: LAYERS_THERMODYNAMICS
>>> in verification/cfc_example to have these pieces of code compiled there
>>> (but without any output yet) and leave exp4 as it is (with default
>>> LAYERS_OPTIONS.h).
>>> Have also few minor edit to add.
>>> Then will wait a couple of days to get most of the automatic testreport
>>> output
>>> and then will make a checkpoint (it's time) before making any new changes
>>> in pkg/layers.
>>> Do you agree with this ?
>>>
>>> Cheers,
>>> Jean-Michel
>>>
>>> On Tue, Jun 09, 2015 at 12:40:51PM -0400, Ryan Abernathey wrote:
>>> > Jean-Michel,
>>> >
>>> > Getting back to this original email which motivated me to finally get
>>> my
>>> > layers changes checked in...
>>> >
>>> > Now that that is done (as of just now with my latest commit), your
>>> items 2)
>>> > and 3) should be good to go ahead. Regarding 3), yes, you are right, it
>>> > seems that there is no reason why those layers diagnostic arrays need
>>> to be
>>> > in the common blocks. Note that there are a lot more diagnostics now if
>>> > LAYERS_THERMODYNAMICS is enabled.
>>> >
>>> > Let me know how I can help with this.
>>> >
>>> > Cheers,
>>> > Ryan
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, May 12, 2015 at 11:10 AM, Jean-Michel Campin <
>>> jmc at ocean.mit.edu>
>>> > wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > I would like to make little changes in pkg/layers:
>>> > > 1) substract 1000 to "prho" = the potential density
>>> > >   that pkg/layers uses as tracer field.
>>> > >  motivation:
>>> > >   a) when I output "prho" using 32-bit precision file,
>>> > >     the -1000 shift would save at least 2 digits of precision.
>>> > >   b) this is a common practise in oceanography to use rho-1000
>>> > >     variable for potential density.
>>> > >   c) since I've just added (yesterday) a diagnostics for this
>>> > >     prho field (+ bring back the snap-shot output of prho that
>>> > >     has been missing for long time when density-layers is not in
>>> > >     first position in the "layers_num" list), this could be a good
>>> > >     time to make this modification.
>>> > > 2) add few check and stop regarding parameter settings, especially:
>>> > >   a) checking for inconsistency between "layers_name" and layers_num
>>> > >    value.
>>> > >   b) if mixing old setting (LAYER_nb, layers_kref, layers_G,
>>> useBOLUS)
>>> > >   and new settings (layers_num, layers_krho, layers_bounds,
>>> layers_bolus).
>>> > > 3) move layer diagnostics array out of commom blocks and define them
>>> > >   as local variables in layers_calc.F
>>> > >  (outside common blocks, the missing re-init of layer non-weighted
>>> velocity
>>> > >   and layer probability - fixed yesterday - would have be caught by
>>> some
>>> > >   "-devel" compiler option).
>>> > >
>>> > > Comments ? suggestions ?
>>> > >
>>> > > Cheers,
>>> > > Jean-Michel
>>> > >
>>> > > _______________________________________________
>>> > > 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20150616/e5b91e5e/attachment-0001.htm>