[MITgcm-support] Forcing files in data.dic (biogeochemistry)

Jonny Williams Jonny.Williams at bristol.ac.uk
Mon Aug 11 13:19:27 EDT 2014


Hi Jean-Michel

Thanks very much indeed for that, I wasn't aware of your suggestion (a)

Unfortunately I am still having issues with restarting my model with the
DIC, GCHEM and PTRACERS packages turned on.

What seems to be happening is that when I restart from a pickup, all of the
ptracers*.nc output gets initialised to zeros around the edges. The
alkalinity, PO4 etc seem to be able to recover but the DIC variable simply
goes to NaNs everywhere apart from at the edges, where it is always zero.

I am assuming that this problem must have something to do with the OBCS
package?

Is there anything I need to do apart from set pickupSuff='ckptA', in the
PARM03 namelist for this to work? Do I also need to set niter0 also as I
have needed to in the past? I have attached my data file in case this is of
any use?

The modules themselves are working fine, it's just that they don't know how
to get going from pickups I think! The model runs fine and gives reasonable
output when starting from scratch (i.e. niter0=0).

Thank you!

Jonny


On 5 August 2014 17:14, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:

> Hi Jonny,
>
> Just a comment regarding the symbolic link for pickup files:
> a) you could by-pass this symbolic link step and specify,
>  in main parameter file "data", in 3rd namelist (/PARM03/):
>  pickupSuff='ckptA',
>  so that the model will load-in pickup*.ckptA.* files instead of
>  pickup*.[nIter0].* files (pickup*.0000012960.* in your case).
> b) an other option, if you want to keep the set of pickup files
>  that you use to restart, is to rename all the pickup*.ckptA.* files
>  to pickup*.[nIter0].* (I often do that, so that I can re-run
>  some segments of a multi-segment simulation).
>  You could find the script "rn_pickup" in MITgcm_contrib/jmc_script
>  that will do this renaming (just typing "rn_pickup" prints
>  how to use it; and in your case, "rn_pickup A" should do the
>  remaning).
>
> Cheers,
> Jean-Michel
>
> On Mon, Aug 04, 2014 at 12:01:23PM +0100, Jonny Williams wrote:
> > ... as often happens though, I have now uncovered a further error which
> > occurs when I try to restart the model using global pickup files.
> >
> > Previously, when I have run without the biogeochemistry packages (DIC,
> > PTRACERS, GCHM) I created a symbolic link such as this...
> >
> > *pickup_dic.0000012960.meta -> pickup_dic.ckptA.meta*
> >
> > ... to indicate that I want to use the ckptA file to restart the run from
> > timestep 12960. I now that I also have pickup files called
> >
> > *pickup_ptracers.ckptA.meta/data *
> > and
> > *pickup_dic.ckptA.meta/data *
> >
> > *... *for the DIC and PTRACERS packages.
> >
> > I have created 2 further sets symbolic links thus...
> >
> > *pickup_dic.0000012960.meta/data -> pickup_dic.ckptA.meta/data*
> > and
> > *pickup_ptracers.0000012960.meta/data -> pickup_ptracers.ckptA.meta/data*
> >
> > Unfortunately I am getting the following error out and the model is not
> > running...
> >
> > *forrtl: severe (64): input conversion error, unit -5, file Internal
> > Formatted Read*
> > *Image              PC                Routine            Line
>  Source
> >             *
> > *mitgcmuv           0000000000BAB3FE  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           0000000000BA973A  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           000000000051D78C  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           00000000005CE598  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           00000000007410B0  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           000000000070FE8E  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           0000000000735AD2  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           000000000075BCEF  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           000000000075BF19  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           00000000006A2B14  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           0000000000400F26  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           0000000000C5DBA4  Unknown               Unknown
> >  Unknown*
> > *mitgcmuv           0000000000400D8D  Unknown               Unknown
> >  Unknown*
> >
> > Is there anything else that anyone can think of that I need to do to get
> > this restart to restart successfully?
> >
> > Many thanks
> >
> > Jonny
> >
> >
> >
> >
> >
> >
> > On 4 August 2014 11:29, Jonny Williams <Jonny.Williams at bristol.ac.uk>
> wrote:
> >
> > > Hi there
> > >
> > > I thought that I would update this thread since I have now found a
> > > solution to this problem. I found the solution in this
> > > <http://mitgcm.org/pipermail/mitgcm-support/2008-April/005351.html>
> thread
> > > from the MITgcm support list archive.
> > >
> > > Basically, the interaction of the biogeochemistry packages (DIC, GCHEM,
> > > PTRACERS) and the OBCS boundary condition package were incompatible and
> > > adding the following line in my data.obcs file fixed the problem...
> > >
> > > *OBCSfixTopo=.TRUE.,*
> > >
> > > Thanks to everyone for your help again.
> > >
> > > Jonny
> > >
> > >
> > > On 31 July 2014 12:00, Jonny Williams <Jonny.Williams at bristol.ac.uk>
> > > wrote:
> > >
> > >> Hi Christoph
> > >>
> > >> Many thanks for your email, I really appreciate it.
> > >>
> > >> I am now able to run the model which is great! I am getting plausible
> > >> values for alkalinity, PO4, DOP and O2 and these evolve through time
> as I
> > >> would expect.
> > >>
> > >> Note that I am running with an empty *DIC_FORCING* namelist in
> *data.dic*.
> > >> it seems that I need to include this namelist even though it is empty.
> > >>
> > >> *&DIC_FORCING*
> > >>
> > >> *&*
> > >>
> > >>
> > >> Unfortunately, although the DIC field is being initialised correctly
> > >> (using the values specified in *data.ptracers*), the DIC field rapidly
> > >> becomes unphysical, giving NaNs everywhere (even over land!) after
> about 25
> > >> timesteps of 24s each.
> > >>
> > >> The NaNs seems to 'propagate' from the corners of the domain as the
> > >> simulation proceeds. I have attached an image of the domain after 13
> > >> timesteps which clearly shows the unphysical nature of the output!
> > >>
> > >> I assume that there must be something that I am missing in my setup
> > >> regarding DIC?
> > >>
> > >> Thanks again
> > >>
> > >> Jonny
> > >>
> > >>
> > >>
> > >>
> > >> On 31 July 2014 11:17, Christoph Voelker <christoph.voelker at awi.de>
> > >> wrote:
> > >>
> > >>>  Hi Jonny,
> > >>>
> > >>> the fractional sea-ice area, supplied via the sea-ice file (or
> > >>> calculated in the sea-ice module) is used for reducing the air-sea
> gas
> > >>> exchange in the presence of sea-ice. The simple assumption here is
> that sea
> > >>> ice is impermeable, so the flux comes just from the non-covered part
> of the
> > >>> ocean surface. You can certainly set all values in the file to zero;
> then
> > >>> the ocean can exchange CO2 unhampered. Maybe you can even just leave
> the
> > >>> filename blank, but I am not sure about that; I usually don't
> specify the
> > >>> file, but I always use the sea-ice package.
> > >>>
> > >>> Concerning the silica file: You don't have to specify it. If you
> leave
> > >>> it away, what you do is that you neglect the contribution of silicic
> acid
> > >>> to the alkalinity, which in many parts of the surface ocean is
> small. But
> > >>> it is not so small in the Southern Ocean, and also to some extent in
> the
> > >>> North Pacific.
> > >>> The contribution of silicic acid to alkalinity is used in the
> > >>> calculation of the equilibrium carbonate chemistry, which is called
> when
> > >>> the model calculates air-sea flux. Neglecting it will lead to a
> small bias
> > >>> in equilibrium DIC values where Si is high.
> > >>>
> > >>>
> > >>> Hope that helps a bit,
> > >>> Cheers, Christoph
> > >>>
> > >>>
> > >>>
> > >>> On 7/31/14 11:45 AM, Jonny Williams wrote:
> > >>>
> > >>> Hi Manfredi
> > >>>
> > >>>  Thank you very much for your very helpful email!
> > >>>
> > >>>  I should clarify my model set up. Although I am using a regional
> model
> > >>> which is based on an Arctic configuration I am now using it for a
> different
> > >>> part of the world.
> > >>>
> > >>>  Also, I have the sea ice package switched off. Perhaps I need to
> > >>> specify a sea ice file which is simply all zeros?
> > >>>
> > >>>  Finally do I need to supply a silica file (like sillev1.bin in the
> > >>> tutorial model)?
> > >>>
> > >>>  Many thanks again
> > >>>
> > >>>  Jonny
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 30 July 2014 19:31, Manfredi Manizza <mmanizza at ucsd.edu> wrote:
> > >>>
> > >>>>  Hi Jonny,
> > >>>>
> > >>>> yes, you are correct that namelist below works fine for the
> > >>>> verification experiment where you run the 2.8 by 2.8 global
> > >>>> setup with dimensions 28 by 64 by 12 of input filles for sea-ice
> cover
> > >>>> and for windspeed
> > >>>>
> > >>>> For your (coarse-res ?) Arctic set-up, you will read wind speed  via
> > >>>> the EXF package  directly from re-analyzed products (NCEP, ECMWF,
> JRA-25)
> > >>>>
> > >>>> For the fraction of sea- ice (or sea ice cover) you will pass to the
> > >>>> biogeochemical routine the variable that is computed
> > >>>> by the sea-ice model that its is coupled in your run to the ocean
> > >>>> physical model.
> > >>>>
> > >>>> In this case you do not have to generate any input files with
> specificy
> > >>>> dimensions becuase in the data.exf file you should have
> > >>>> all details needed to interpolate on the fly your forcing
> accordingly
> > >>>> to your Arctic domain.
> > >>>>
> > >>>> Debugging tip :
> > >>>>
> > >>>> Just make sure that in the dic package the sea-ice coverage is
> > >>>> correctly read in order to compute the gas transfer velocity
> > >>>> and the amount of irradiance use to compute the Net Community
> > >>>> Production that has to be masked at the surface
> > >>>> by the sea-ice fraction. Running 2-3 time steps with printout
> linese of
> > >>>> the variables always helps
> > >>>> to figure out that all works OK and the two parts of the code talk
> to
> > >>>> each other.
> > >>>>
> > >>>> I hope this helps.
> > >>>>
> > >>>> Manfredi
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 07/30/2014 07:45 AM, Jonny Williams wrote:
> > >>>>
> > >>>>  Hi there
> > >>>>
> > >>>>  I am currently trying to incorporate the GCHEM, PTRACERS and DIC
> > >>>> packages into my setup of the MITgcm. I already have it successfully
> > >>>> working in regional model using the OBCS and EXF forcing packages.
> > >>>>
> > >>>>  in the ~/MITgcm/verification/tutorial_global_oce_biogeo example,
> the
> > >>>> data.dic file calls for the following files in the DIC_FORCING
> namelist
> > >>>>
> > >>>>  &DIC_FORCING
> > >>>>   DIC_iceFile='fice.bin',
> > >>>>   DIC_windFile='tren_speed.bin',
> > >>>>   DIC_silicaFile='sillev1.bin',
> > >>>>  &
> > >>>>
> > >>>>  What I cannot work out however is what size these files should be
> in
> > >>>> my setup. From trial and error, I think the ice and wind files are
> monthly
> > >>>> climatologies (longitude x latitude x 12 months) and the sillev1
> file
> > >>>> (silica data file, according to the manual
> > >>>> <
> http://mitgcm.org/public/r2_manual/latest/online_documents/manual.pdf>)
> > >>>> is of the form longitude x latitude x 15 levels.
> > >>>>
> > >>>>  Does anyone know what size they should be? Should they have the
> same
> > >>>> number of elements as the underlying grid, or is it staggered?
> > >>>>
> > >>>>  This raises a more generic issue in that clearly the binary input
> > >>>> files are not self-describing (like, say, NetCDF) and so having to
> > >>>> reverse-engineer what size forcing and boundary condition files
> should is
> > >>>> not uncommon for me.
> > >>>>
> > >>>>  I may well be going about this in the wrong way so any suggestions
> > >>>> about how to avoid this situation in future would be appreciated :)
> > >>>>
> > >>>>  Many thanks, as always
> > >>>>
> > >>>>  Jonny
> > >>>>
> > >>>>  --
> > >>>>  Dr Jonny Williams
> > >>>> School of Geographical Sciences
> > >>>> University of Bristol
> > >>>> University Road
> > >>>> BS8 1SS
> > >>>>
> > >>>>  +44 (0)117 3318352 <%2B44%20%280%29117%203318352>
> > >>>> jonny.williams at bristol.ac.uk
> > >>>> bit.ly/jonnywilliams
> > >>>>
> > >>>>
> > >>>>  _______________________________________________
> > >>>> MITgcm-support mailing listMITgcm-support at mitgcm.orghttp://
> mitgcm.org/mailman/listinfo/mitgcm-support
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Dr. Manfredi Manizza
> > >>>> Geosciences Research Division
> > >>>> Scripps Institution of Oceanography
> > >>>> University of California San Diego
> > >>>> 9500 Gilman Drive La Jolla, CA 92093-0244
> > >>>> email : mmanizza at ucsd.edu
> > >>>> tel   : +1-858-534-7094
> > >>>> web   : http://bluemoon.ucsd.edu/mmanizza/
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> MITgcm-support mailing list
> > >>>> MITgcm-support at mitgcm.org
> > >>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>  --
> > >>>  Dr Jonny Williams
> > >>> School of Geographical Sciences
> > >>> University of Bristol
> > >>> University Road
> > >>> BS8 1SS
> > >>>
> > >>>  +44 (0)117 3318352
> > >>> jonny.williams at bristol.ac.uk
> > >>> bit.ly/jonnywilliams
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> MITgcm-support mailing listMITgcm-support at mitgcm.orghttp://
> mitgcm.org/mailman/listinfo/mitgcm-support
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Christoph Voelker
> > >>> Alfred Wegener Institute for Polar and Marine Research
> > >>> Am Handelshafen 12
> > >>> 27570 Bremerhaven, Germany
> > >>> e: Christoph.Voelker at awi.de
> > >>> t: +49 471 4831 1848
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> MITgcm-support mailing list
> > >>> MITgcm-support at mitgcm.org
> > >>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Dr Jonny Williams
> > >> School of Geographical Sciences
> > >> University of Bristol
> > >> University Road
> > >> BS8 1SS
> > >>
> > >> +44 (0)117 3318352
> > >> jonny.williams at bristol.ac.uk
> > >> bit.ly/jonnywilliams
> > >>
> > >
> > >
> > >
> > > --
> > > Dr Jonny Williams
> > > School of Geographical Sciences
> > > University of Bristol
> > > University Road
> > > BS8 1SS
> > >
> > > +44 (0)117 3318352
> > > jonny.williams at bristol.ac.uk
> > > bit.ly/jonnywilliams
> > >
> >
> >
> >
> > --
> > Dr Jonny Williams
> > School of Geographical Sciences
> > University of Bristol
> > University Road
> > BS8 1SS
> >
> > +44 (0)117 3318352
> > jonny.williams at bristol.ac.uk
> > bit.ly/jonnywilliams
>
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>



-- 
Dr Jonny Williams
School of Geographical Sciences
University of Bristol
University Road
BS8 1SS

+44 (0)117 3318352
jonny.williams at bristol.ac.uk
bit.ly/jonnywilliams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140811/a1e1cde2/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data
Type: application/octet-stream
Size: 2656 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140811/a1e1cde2/attachment-0001.obj>


More information about the MITgcm-support mailing list