[MITgcm-support] Cold bias and Eta has values on land

[Yang Wang]

I am running a case exactly the same as the "tutorial_global_oce_latlon",
but used the data that made by myself. The input data is from the ECCO "
ftp://ftp-icdc.cen.uni-hamburg.de/EASYInit/ECCO/", the bathymetry is
ETOPO5, and the SST and SSS is from WOA94. Land-sea mask and topography
adjustments have been applied by comparing the grid depth data and input
data.

The model runs into a serious cold bias (the maximum SST drops rapidly to
25C soon and stays stable), though the temperature pattern seems Okay.
Another weird thing is the the Eta has values on land! Did anybody face
this issue before? Thank you for your help in advance.

Best,

James Young

On Tue, Mar 27, 2018 at 7:16 AM, <mitgcm-support-request at mitgcm.org> wrote:

> Send MITgcm-support mailing list submissions to
>         mitgcm-support at mitgcm.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> or, via email, send a message with subject or body 'help' to
>         mitgcm-support-request at mitgcm.org
>
> You can reach the person managing the list at
>         mitgcm-support-owner at mitgcm.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MITgcm-support digest..."
>
>
> Today's Topics:
>
>    1. Re: Controlling MNC output (Jody Klymak)
>    2. Re: SST relaxation with temporal variability (Uchida Takaya)
>    3. Re: Controlling MNC output (Gus Correa)
>    4. Re: SST relaxation with temporal variability (Martin Losch)
>    5. Blocking of light by sea ice and plankton (Andrew Twelves)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 Mar 2018 09:07:26 -0700
> From: Jody Klymak <jklymak at uvic.ca>
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] Controlling MNC output
> Message-ID: <43B28540-9896-4E55-8E7E-DA2249E79A87 at uvic.ca>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Taylor,
>
> If you just use the state-dump files, I don?t know of a way to only starts
> saving after N years, except to stop the run after saving a pickup, and
> then restart with the pickup.
>
> If you use the diagnostics package, then you can set the ?phase? of the
> save to be many years in the future and the saves won?t start until that
> point.
>
> Cheers,  Jody
>
> > On Mar 26, 2018, at  8:58 AM, Taylor Shropshire <tas14j at my.fsu.edu>
> wrote:
> >
> > Hello,
> >
> > I am attempting to save computational resources by having the model
> write output files only after a predetermined amount of spin up. I see
> variables like deltaTClock and dumpFreq but can't seem to figure out how to
> make the model write output files only after a few years of a simulation
> have been ran.
> >
> > Thanks,
> > Taylor
> >
> > Taylor Shropshire
> > PhD Candidate - Oceanography
> > Center for Ocean - Atmospheric Prediction Studies
> > Florida State University
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
> > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support <
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/
> attachments/20180326/1f3179ef/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Mar 2018 12:53:28 -0400
> From: Uchida Takaya <tu2140 at columbia.edu>
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] SST relaxation with temporal variability
> Message-ID: <6169FD67-220D-4B0E-8247-4D89C92A5239 at columbia.edu>
> Content-Type: text/plain; charset=utf-8
>
> Hi Martin,
>
> Thank you very much for your reply and information.
>
> If I understand correctly what you have mentioned, as long as the forcing
> data (e.g. `zonalWindFile`, `thetaClimeFile` etc.) all have the same
> relaxation time scale, cycle and period, the time varying surface forcing
> should work fine with just prescribing the forcing files along with the
> `tauThetaClimRelax`, `externForcingCycle` and `externForcingPeriod`
> parameters in the namelist file `data` without having to resort to the
> `rbcs` nor `exf` package. Is this understanding correct?
>
> Best,
> Takaya
>
> > On Mar 26, 2018, at 4:37 AM, Martin Losch <Martin.Losch at awi.de> wrote:
> >
> > Hi Takaya,
> >
> > `externForcingCycle` and `externForcingPeriod` are used for all forcing
> data that is specified in the namelist file ?data?. That makes this way of
> reading and applying forcing data very unflexible.
> >
> > You could use the rbcs package for surface restoring, although I would
> not recommend it as it?s a bit of an overkill. rbcs can be used for 3D
> restoring and involves a lot of extra storage.
> >
> > The recommended surface forcing package is the exf-package. There you
> have different forcing periods etc for each forcing field, including
> surface restoring. The exf-package is more involved in terms of
> configuration, but in the long run it pays off to use it.
> >
> > Martin
> >
> >> On 20. Mar 2018, at 20:28, Uchida Takaya <tu2140 at columbia.edu> wrote:
> >>
> >> Dear MITgcm support,
> >>
> >>
> >> I am trying to include sea-surface temperature (SST) relaxation with
> temporal variability.
> >>
> >> I found the documentation for which parameters to change for temporally
> varying wind stress (http://mitgcm.org/public/r2_manual/latest/online_
> documents/node104.html) but the `externForcingCycle` and
> `externForcingPeriod` parameters seem only to be incorporated into the
> momentum equation.
> >> Do the parameters also apply to the SST forcing prescribed by
> `thetaClimFile` in the `data` name file or would I need to use the `rbcs`
> package by prescribing `rbcsForcingPeriod`, `rbcsForcingCycle` and
> `tauRelaxT`?
> >> In the latter case, should I simply comment out `tauThetaClimRelax` and
> `thetaClimFile` in the `data` name file?
> >>
> >> Any clarification on this would be helpful. Thank you very much for
> your support in advance.
> >>
> >>
> >> Best,
> >> Takaya
> >> ???????
> >> PhD Candidate
> >> Physical Oceanography
> >> Columbia University in the City of New York
> >> https://roxyboy.github.io/
> >>
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org
> >> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 Mar 2018 13:18:15 -0400
> From: Gus Correa <gus at ldeo.columbia.edu>
> To: MITgcm Support <mitgcm-support at mitgcm.org>
> Subject: Re: [MITgcm-support] Controlling MNC output
> Message-ID: <82c9f30f-d1b4-1944-3f93-c24b19324ef0 at ldeo.columbia.edu>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Taylor
>
> Piggybacking on Jody's suggestions:
>
> 1) My understanding is that deltaTClock (in seconds)
> controls the model time step
> (other than the momentum solver time step, controlled by deltaTMom),
> is the model fundamental heartbeat,
> and in most setups it boils down to the the same as deltaT,
> deltaTtracer, etc.
> (MITgcm insiders correct me, please correct me if I am wrong.)
> deltaTClock doesn't control the output frequency.
>
> 2) You could run the spinup phase first,
> with a large value of dumpFreq (in seconds),
> say, greater or equal to the model endTime, to avoid output
> during spinup (if that is really what you want).
> [Having some output during spinup would let you QC the spinup.]
> The endTime or nTimeSteps in the data namelist file
> will tell the model when to stop.
>
> Then run again, now picking up at the end of the spinup phase,
> now with a smaller dumpFreq,
> to output what you need for post-spinup.
>
> You need to update nIter0 (in data)
> for this second phase of the run, to match the final
> iteration of the spinup phase.
>
> The same technique can be applied if you're using the
> diagnostics package, by changing the values in data.diagnostics
> between the two phases.
> BTW, the diagnostic package allows finer grained control.
>
> 3) In my experience with the MITgcm,
> to avoid to have jobs running for extremely long periods of time
> (sometimes doing the wrong thing),
> and to promote more flexibility to make changes such
> as the one you mention,
> one can handle these things in at least two ways, both laborious:
>
> A) If you're running on a cluster with a job scheduler, you could
> write a wrapper job submission script
> (in bash, tcsh, perl, python, whatever) that:
> A1) updates nIter0 (in data) after each model run ends (after mpirun
> ./mitgcmuv)
> A2) then resubmits the job (with "qsub $0",
> or equivalent command for the job scheduler you use).
> Most job schedulers are configured to allow jobs to resubmit themselves
> this way.
>
> B) If you're running on a workstation or standalone machine without
> a job scheduler, you could do the steps in item A) manually.
>
> This way you can gracefully break your run in two phases (spinup and
> "steady state"), and adjust the various data* namelists according to
> your needs.
>
> This also has the advantage of allowing you to QC partial results along
> the way, avoiding long and costly runs with mistaken setups.
>
> I hope this helps,
> Gus Correa
>
>
> On 03/26/2018 12:07 PM, Jody Klymak wrote:
> > Hi Taylor,
> >
> > If you just use the state-dump files, I don?t know of a way to only
> > starts saving after N years, except to stop the run after saving a
> > pickup, and then restart with the pickup.
> >
> > If you use the diagnostics package, then you can set the ?phase? of the
> > save to be many years in the future and the saves won?t start until that
> > point.
> >
> > Cheers, ?Jody
> >
> >> On Mar 26, 2018, at ?8:58 AM, Taylor Shropshire <tas14j at my.fsu.edu
> >> <mailto:tas14j at my.fsu.edu>> wrote:
> >>
> >> Hello,
> >>
> >> I am attempting to save computational resources by having the model
> >> write output files only after a predetermined amount of spin up. I see
> >> variables like deltaTClock and dumpFreq?but can't seem to figure out
> >> how to make the model write output files only after a few years of a
> >> simulation have been ran.
> >>
> >> Thanks,
> >> Taylor
> >>
> >> *Taylor Shropshire
> >> PhD Candidate?- Oceanography*
> >> *Center for Ocean - Atmospheric Prediction Studies*
> >> *Florida State University*
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
> >> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> >
> >
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 27 Mar 2018 09:35:49 +0200
> From: Martin Losch <Martin.Losch at awi.de>
> To: MITgcm Support <mitgcm-support at mitgcm.org>
> Subject: Re: [MITgcm-support] SST relaxation with temporal variability
> Message-ID: <406CEEC4-FC4B-454C-8738-959C5042CF42 at awi.de>
> Content-Type: text/plain; charset="utf-8"
>
> Yes,
>
> except that the relaxation time scale only affects the surface restoring
> fields (files thetaClimFile, saltClimFile), but I think you mean that.
>
> M.
>
> > On 26. Mar 2018, at 18:53, Uchida Takaya <tu2140 at columbia.edu> wrote:
> >
> > Hi Martin,
> >
> > Thank you very much for your reply and information.
> >
> > If I understand correctly what you have mentioned, as long as the
> forcing data (e.g. `zonalWindFile`, `thetaClimeFile` etc.) all have the
> same relaxation time scale, cycle and period, the time varying surface
> forcing should work fine with just prescribing the forcing files along with
> the `tauThetaClimRelax`, `externForcingCycle` and `externForcingPeriod`
> parameters in the namelist file `data` without having to resort to the
> `rbcs` nor `exf` package. Is this understanding correct?
> >
> > Best,
> > Takaya
> >
> >> On Mar 26, 2018, at 4:37 AM, Martin Losch <Martin.Losch at awi.de> wrote:
> >>
> >> Hi Takaya,
> >>
> >> `externForcingCycle` and `externForcingPeriod` are used for all forcing
> data that is specified in the namelist file ?data?. That makes this way of
> reading and applying forcing data very unflexible.
> >>
> >> You could use the rbcs package for surface restoring, although I would
> not recommend it as it?s a bit of an overkill. rbcs can be used for 3D
> restoring and involves a lot of extra storage.
> >>
> >> The recommended surface forcing package is the exf-package. There you
> have different forcing periods etc for each forcing field, including
> surface restoring. The exf-package is more involved in terms of
> configuration, but in the long run it pays off to use it.
> >>
> >> Martin
> >>
> >>> On 20. Mar 2018, at 20:28, Uchida Takaya <tu2140 at columbia.edu> wrote:
> >>>
> >>> Dear MITgcm support,
> >>>
> >>>
> >>> I am trying to include sea-surface temperature (SST) relaxation with
> temporal variability.
> >>>
> >>> I found the documentation for which parameters to change for
> temporally varying wind stress (http://mitgcm.org/public/r2_
> manual/latest/online_documents/node104.html) but the `externForcingCycle`
> and `externForcingPeriod` parameters seem only to be incorporated into the
> momentum equation.
> >>> Do the parameters also apply to the SST forcing prescribed by
> `thetaClimFile` in the `data` name file or would I need to use the `rbcs`
> package by prescribing `rbcsForcingPeriod`, `rbcsForcingCycle` and
> `tauRelaxT`?
> >>> In the latter case, should I simply comment out `tauThetaClimRelax`
> and `thetaClimFile` in the `data` name file?
> >>>
> >>> Any clarification on this would be helpful. Thank you very much for
> your support in advance.
> >>>
> >>>
> >>> Best,
> >>> Takaya
> >>> ???????
> >>> PhD Candidate
> >>> Physical Oceanography
> >>> Columbia University in the City of New York
> >>> https://roxyboy.github.io/
> >>>
> >>> _______________________________________________
> >>> MITgcm-support mailing list
> >>> MITgcm-support at mitgcm.org
> >>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> >>
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org
> >> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> >
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 27 Mar 2018 11:16:40 +0000
> From: Andrew Twelves <agt_94 at hotmail.co.uk>
> To: "mitgcm-support at mitgcm.org" <mitgcm-support at mitgcm.org>
> Subject: [MITgcm-support] Blocking of light by sea ice and plankton
> Message-ID:
>         <DB6PR0501MB266204BA9F0DD91D117BB072B2AC0 at DB6PR0501MB2662.
> eurprd05.prod.outlook.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Morning all,
>
>
>
> I am about to start biogeochemical modelling using the BLING package, and
> have a couple of questions regarding the treatment of light availability:
>
>
>
>   1.  Does BLING by default set light penetration to zero underneath sea
> ice, or does it allow for limited penetration subject to a strong
> attenuation coefficient?  If the latter, does BLING take the value of
> effective sea ice thickness HEFF directly from the Sea Ice package, or does
> it do something more sophisticated (like a sub-grid scale parametrization
> of the thickness distribution)?
>   2.  Does BLING take the self-shading effect of phytoplankton themselves
> into account for light calculations?
>
>
>
> I appreciate that these are potentially broad questions but any guidance
> would be much appreciated.
>
>
>
> Many thanks in advance,
>
>
>
> Andrew Twelves
>
> University of Edinburgh
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/
> attachments/20180327/ec6abe7a/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> ------------------------------
>
> End of MITgcm-support Digest, Vol 177, Issue 20
> ***********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20180327/eec3d045/attachment-0001.html>