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

Jean-Michel Campin jmc at ocean.mit.edu
Tue Aug 5 12:14:03 EDT 2014


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




More information about the MITgcm-support mailing list