[MITgcm-support] Forcing files in data.dic (biogeochemistry)
Jonny Williams
Jonny.Williams at bristol.ac.uk
Fri Aug 22 11:42:36 EDT 2014
Hi Jean-Michel
Thank you very much for your email!
In answer to your questions:
1. Yes, OBs are straight lines and yes, the northern/western and
southern/western boundaries cross at wet points. The other two boundaries
are all dry.
2. I have been using tracer advection scheme 77 (described here
<http://mitgcm.org/public/r2_manual/latest/online_documents/node82.html#tab:advectionShemes_summary>)
but I have also tried advection schemes 1 and 2 and neither of them worked.
I don't think I am using multidimensional advection for the tracers. I
coped the example of data.ptracers
from verification/tutorial_global_oce_biogeo/input/data.ptracers and the
changes I have made have been minimal except for the inclusion of the KPP
scheme and changing the number of levels in PTRACERS_ref to 50.
3. I've attached the relevant files.
Please let me know if I can provide any more. Huge thanks!
Jonny
On 22 August 2014 16:29, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> Hi Jonny,
>
> I suspect that we have a problem in the code regarding the use
> of pkg/dic with pkg/obcs.
> This combination is not currently tested (i.e., we don't have any
> verification experiment that run this case).
> The fact that setting "OBCSfixTopo=.TRUE.," was helping at lower
> resolution is not a good sign (the model is supposed to run fine
> without this flag).
>
> Will take a look at the code and get back to you.
> But to facilitate the search:
> 1) do your OB are strait lines ? and do you have wet points in a place
> where OB cross (e.g. Northern and Eastern OB) ?
> 2) which advection scheme do you use for ptracers ? do you use
> multi-dim advection for ptracers ?
> 3) it could help if you send us some of the relevant parameter files:
> data.obcs data data.pkg and data.ptracers
>
> Cheers,
> Jean-Michel
>
> On Thu, Aug 21, 2014 at 12:45:39PM +0100, Jonny Williams wrote:
> > Hi everyone
> >
> > With regard to this thread, I can now successfully run my model at 1
> degree
> > resolution with all the biogeochemistry packages that I want turned on
> and
> > I can also restart the model, which is great; thanks for your help.
> >
> > I am now trying to run essentially the same model but for 0.1 degree
> > resolution. Unfortunately, even using the *OBCSfixTopo=.TRUE., *flag in
> > data.obcs I am getting unphysical values creeping in from the corners
> again
> > (see attachment in previous email).
> >
> > Does anyone have any ideas about how I can circumvent this? Notably, it
> is
> > only the DIC quantity which is going to NaNs, all the other
> biogeochemical
> > variables (alk, po4, dop, o2) carry on fine so I assume it is a problem
> > with the DIC package specifically (i.e. not GCHEM, PTRACERS)?
> >
> > Many thanks in advance for any input!
> >
> > 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/20140822/eed9f8d5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.pkg
Type: application/octet-stream
Size: 265 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140822/eed9f8d5/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.obcs
Type: application/octet-stream
Size: 1051 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140822/eed9f8d5/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.ptracers
Type: application/octet-stream
Size: 4393 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140822/eed9f8d5/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data
Type: application/octet-stream
Size: 2622 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140822/eed9f8d5/attachment-0007.obj>
More information about the MITgcm-support
mailing list