[MITgcm-support] Re: OBCS sponge and prescribe code checked in
Patrick Heimbach
heimbach at MIT.EDU
Wed Sep 22 09:04:27 EDT 2004
Martin,
I would like to leave this for a bit later.
I have a separate routine locally that can
handle annual files, i.e. for real time forcing
not everything needs to be in one file, but can be
split into annual files.
But I'll put your suggestion in there.
-Patrick
Quoting Martin Losch <mlosch at awi-bremerhaven.de>:
> setting fldperiod=repeatperiod should work, i agree, but what if I
> don't have a repeatperiod ...? Ok, I can always use a very long
> repeatperiod, much longer than my integration, but that's not very
> nice.
>
> If you like, I can try to fix this in exf_getffieldsrec. Do you think
> the proposed code is sufficient?
You also need to assign
> Martin
>
> On Sep 21, 2004, at 10:23 PM, Patrick Heimbach wrote:
>
> > Martin,
> >
> > can't you just set for the field that's constant
> > fldperiod = repeatperiod
> > that is, e.g. for lwdown
> > lwdownperiod = whatever.your.repeat.period.is
> > It should then always cycle through to record 1.
> >
> > That should work, shouldn't it.
> > But maybe not totally intuitive, so maybe
> > worth changing at some point.
> >
> > -Patrick
> >
> >
> >
> > Quoting Martin Losch <mlosch at awi-bremerhaven.de>:
> >
> >> Patrick,
> >> still another question about EXF. I thought that I can specify
> >> different forcing periods for different data. For example, I have
> >> hourly time dependent short wave surface forcing, so I specify
> >> swdownperiod = 3600.0, etc. but my long wave surface forcing is
> >> constant in time, so I specify lwdownperiod = 0., but then the model
> >> crashes while reading lwdownFile, actually before that because in
> >> exf_getffieldsrec there is a division by zero=fldperiod=lwdownPeriod.
> >>
> >> I suggest the following fix (but haven't tested that at all so far):
> >> CML)
> >> if (fldperiod.eq.0 ) then
> >> fac = 0.
> >> count0 = 1
> >> count1 = 1
> >> changed = .false.
> >> else
> >> CML)
> >> C this is the original code
> >> if (repeatPeriod.eq.0.) then
> >> elseif()then
> >> else
> >> endif
> >> CML(
> >> endif
> >> CML)
> >>
> >> Or have I overlooked something?
> >>
> >> Martin
> >>
> >> On Sep 21, 2004, at 1:38 AM, Patrick Heimbach wrote:
> >>
> >>>
> >>> Hi Martin, Uli, and others,
> >>>
> >>> I've just checked in code in pkg/obcs/ that
> >>> * ALLOW_OBCS_PRESCRIBE allows prescibing time-dependent obcs values,
> >>> * ALLOW_OBCS_SPONGE sponge layers
> >>> * ALLOW_OBCS_BALANCE rudimentary balancing of normal barotropic flow
> >>>
> >>> tag is checkpoint55a_post
> >>>
> >>> The stuff I checked in at least doesn't break
> >>> the existing verif.'s that use obcs ;o)
> >>> The code has been / is used in a few open boundary setups,
> >>> it compiles ok, but no guarantee that the merging may have
> >>> broken some of the new stuff.
> >>> Any feedback on bugs, improvements etc are welcome.
> >>>
> >>> One feature/caveat is that the time-dependent prescibe
> >>> runs in conjunction with exf, cal., i.e.
> >>> S/R OBCS_CALC calls S/R EXF_GETOBCS
> >>> If someone wants to volunteer to call
> >>> external_fields_load alternatively, please.
> >>>
> >>> The files read are
> >>> xz files (northern, southern boundary)
> >>> yz files (eastern, western boundary)
> >>>
> >>> I've put a few "template" CPP options and runtime parameter files
> >>> under
> >>> http://mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm_contrib/heimbach/
> >>> obcs_prescribe/
> >>>
> >>> A verif. experiment will hopefully come soon.
> >>>
> >>> -Patrick
> >>>
> >>>
> >>>
> >>> Quoting Patrick Heimbach <heimbach at MIT.EDU>:
> >>>
> >>>>
> >>>> Hi Martin,
> >>>>
> >>>> there is code for sponge layers and code for reading
> >>>> 2D (xz, yz) boundart slices (was part of ECCO).
> >>>> I wanted to merge it with the main code last week,
> >>>> but didn't have time since I also had to catch up
> >>>> with the adjoint (-> c55).
> >>>> Will try it in the first half of this week
> >>>> (remind me ;o).
> >>>>
> >>>> -Patrick
> >>>>
> >>>> Quoting Martin Losch <mlosch at awi-bremerhaven.de>:
> >>>>
> >>>>> Hi,
> >>>>> now the obcs-package has got me. In the global_ocean.90x40x15
> >>>>> experiment, I would like to introduce open boundaries in the south
> >>>>> and/or north to emulate polar regions. Now the simplest and
> >>>>> dirtiest
> >>>>> way to do it would be through restoring in external_forcing. But I
> >>>>> want
> >>>>> to do it the hard and clean way and use the obcs package (o: A few
> >>>>> questions arise:
> >>>>> 1) as a general rule/how-to I start by modifying obcs_calc, so that
> >>>>> after calling obcs_calc, the boundary values at time myTime+deltaT
> >>>>> are
> >>>>> known. Why myTime+deltaT, why not the current time=myTime?
> >>>>> 2) ALLOW_OBCS_SPONGE: Is there code for sponge layers, or am I
> >>>>> completely responsible for it myself (subroutine
> >>>>> obcs_sponge_u/v/t/s)?
> >>>>> As far as I know, a sponge layer is not much more than a restoring
> >>>>> zone, correct? If I use a sponge layer (#define ALLOW_OBCS_SPONGE),
> >>>>> will I still have an open boundary? Or in other words: just having
> >>>>> restoring in external_forcing.F is not the same as
> >>>>> ALLOW_OBCS_SPONGE
> >>>>> and do the restoring somewhere in obcs_sponge_u/v/t/s, etc? It
> >>>>> seems
> >>>>> so.
> >>>>> 3) not quite OBCS, but related. I want to read my open boundary
> >>>>> values
> >>>>> from a file (in calc_obcs), so I have to create code for that, fair
> >>>>> enough; but because I only want to read one xz-slice, for example,
> >>>>> (there is even an MDSIOREADFIELDXZ, impressive), I have a problem
> >>>>> with
> >>>>> exchanging the xz-slice, or did I just not find the excange_xz_r?
> >>>>> file?
> >>>>> Does anyone have experience with this?
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> _______________________________________________
> >>>>> MITgcm-support mailing list
> >>>>> MITgcm-support at mitgcm.org
> >>>>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> >>>>>
> >>>>
> >>>>
> >>>> --------------------------------------------------------
> >>>> Patrick Heimbach Massachusetts Institute of Technology
> >>>> FON: +1/617/253-5259 EAPS, Room 54-1518
> >>>> FAX: +1/617/253-4464 77 Massachusetts Avenue
> >>>> mailto:heimbach at mit.edu Cambridge MA 02139
> >>>> http://www.mit.edu/~heimbach/ USA
> >>>>
> >>>> _______________________________________________
> >>>> MITgcm-support mailing list
> >>>> MITgcm-support at mitgcm.org
> >>>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> >>>>
> >>>
> >>>
> >>> --------------------------------------------------------
> >>> Patrick Heimbach Massachusetts Institute of Technology
> >>> FON: +1/617/253-5259 EAPS, Room 54-1518
> >>> FAX: +1/617/253-4464 77 Massachusetts Avenue
> >>> mailto:heimbach at mit.edu Cambridge MA 02139
> >>> http://www.mit.edu/~heimbach/ USA
> >>>
> >>
> >>
> >
> >
> > --------------------------------------------------------
> > Patrick Heimbach Massachusetts Institute of Technology
> > FON: +1/617/253-5259 EAPS, Room 54-1518
> > FAX: +1/617/253-4464 77 Massachusetts Avenue
> > mailto:heimbach at mit.edu Cambridge MA 02139
> > http://www.mit.edu/~heimbach/ USA
> >
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>
--------------------------------------------------------
Patrick Heimbach Massachusetts Institute of Technology
FON: +1/617/253-5259 EAPS, Room 54-1518
FAX: +1/617/253-4464 77 Massachusetts Avenue
mailto:heimbach at mit.edu Cambridge MA 02139
http://www.mit.edu/~heimbach/ USA
More information about the MITgcm-support
mailing list