[MITgcm-devel] changes in pkg/layers

Ryan Abernathey ryan.abernathey at gmail.com
Wed Jun 10 17:01:19 EDT 2015


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/20150610/adc9ba46/attachment-0001.htm>


More information about the MITgcm-devel mailing list