[MITgcm-devel] gentim2d controls - nonperiodic forcing

[Daniel Goldberg]

Thanks for the response Jean-Michel.


On Fri, Feb 7, 2014 at 3:36 PM, Jean-Michel Campin <jmc at ocean.mit.edu>wrote:

> Hi Dan,
>
> The standard way that MITgcm follows is to assume that
> a record in file is some time-average value and is centered
> on the middle of the the time interval which starts and ends
> at record-spacing multiple.
>
> This is not what you would like to have:
> > t=0 days --> count0 = 1, count1 = 2, fac=1
> > t=0.25 days --> count0=1, count1=2, fac=0.75
> > t=1 days --> count0=2, count1=3, fac=1
> > t=10 days --> count0=10, count1=11, fac=0
> where a record in file would be centered on an exact multiple
> of the record-spacing.
>

but without a periodic cycle, this would mean the forcing needs to be
extrapolated, rather than interpolated, when time < 0.5*period or time >
endTime-0.5*period -- i think we can do better than this?

and besides which, if externForcingCycle is set to zero when
get_periodic_interval is called from ctrl_get_gen_rec, it results in a
runtime error -- which is perhaps why this (calling get_periodic_interval
with externForcingCycle=0) was not allowed in the first place. Still, there
is no other way I can see NOT to make the gentim2d control periodic. but
perhaps if anyone else is using the control they might know?


>
> But regarding this convention, I don't think that we currently treat
> differently periodic and non-periodic time series.
>
> > and to get_periodic_interval to implement the following *only
> > when exter_forcing_cycle = 0*, would this impact anyone?
> So, I think it would be more confusing to treat non-periodic time-series
> in a different way that we do for periodic time-series.
>
> The way to work around this would be to define a "time-offset"
> that you could set to half the record-spacing, a little bit like
> what is done in rbcs_fields_load.F:
>        locTime = myTime - rbcsForcingOffset
>        CALL GET_PERIODIC_INTERVAL(
>      O                   intimeP, intime0, intime1, bWght, aWght,
>      I                   rbcsForcingCycle, rbcsForcingPeriod,
>      I                   deltaTclock, locTime, myThid )
>
> I think that with pkg/cal, you can already provide an offset.
>
>
not sure how to do that (without using modified S/R's). i am calling
get_periodic_interval through ctrl_get_gen_rec without ALLOW_CAL, and this
does not include a way to specify an offset.

if I *could* change ctrl_get_gen_rec, I could maybe fix the issue, but I
know Gael (and maybe others) use this S/R so it is up to Gael and Patrick.


> Cheers,
> Jean-Michel
>
> On Fri, Feb 07, 2014 at 11:17:39AM +0000, Daniel Goldberg wrote:
> > Hi,
> >
> > I was wondering if anyone uses the gentim2d control for NON-periodic
> > time-dependent cases, and/or whether there are thoughts on the following:
> >
> > the S/R ctrl_get_gen_rec uses the S/R get_periodic_interval to determine
> > the indices of the time-dependence between which to interpolate, and the
> > interpolation weights (called count0, count1, and fac within
> > ctrl_get_gen_rec).
> >
> > 1) get_periodic_interval has a case for a non-periodic time-record
> sequence
> > (line 100) if externForcingCycle is set to zero -- but ctrl_get_gen_rec
> > ensures that this is never called! (i am not using ALLOW_CAL)
> >
> > 2) if this is modified to allow get_periodic_interval to be called, this
> > returns a given count0, count1, and fac according to the
> > get_periodic_interval algorithm in the nonperiodic case. But I am unsure
> if
> > the result is what should be done.
> >
> > For example, if the period of gentim2d as set in data.ctrl
> > (xx_gentim2d_period) is 1 day, and the simulation is 10 days, an
> > appropriate-seeming way to define time-dependent forcing would be to have
> > 11 fields, applied at t=0 days, 1 days, 2 days, ... I think currently
> they
> > are defined at 0.5 days, 1.5 days, etc.. and I am unsure how the
> > interpolation should be done at t=0.25 days.
> >
> > So for example, in the scheme i propose and the above example, count0
> could
> > take on values from 0 to 10, and count1 from 1 to 11, and at
> >
> > t=0 days --> count0 = 1, count1 = 2, fac=1
> > t=0.25 days --> count0=1, count1=2, fac=0.75
> > t=1 days --> count0=2, count1=3, fac=1
> > t=10 days --> count0=10, count1=11, fac=0
> >
> > This is not, I believe, the way things are defined now, but I could be
> > wrong. Assuming I am not, and changes were made to ctrl_get_gen_rec to
> > address (1), and to get_periodic_interval to implement the following
> *only
> > when exter_forcing_cycle = 0*, would this impact anyone?
> >
> > Thanks
> > Dan
> >
> > --
> >
> > Daniel Goldberg, PhD
> > Lecturer in Glaciology
> > School of Geosciences, University of Edinburgh
> > Geography Building, Drummond Street, Edinburgh EH8 9XP
> >
> >
> > em: D <dgoldber at mit.edu>an.Goldberg at ed.ac.uk
> > web: http://ocean.mit.edu/~dgoldberg
>
> > _______________________________________________
> > 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
>



-- 

Daniel Goldberg, PhD
Lecturer in Glaciology
School of Geosciences, University of Edinburgh
Geography Building, Drummond Street, Edinburgh EH8 9XP


em: D <dgoldber at mit.edu>an.Goldberg at ed.ac.uk
web: http://ocean.mit.edu/~dgoldberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20140208/5b5a5a24/attachment.htm>