[MITgcm-support] Forcing files in data.dic (biogeochemistry)
Jonny Williams
Jonny.Williams at bristol.ac.uk
Thu Aug 28 11:21:54 EDT 2014
Hi again
Unfortunately, after updating the whole MITgcm directory tree, I now cannot
compile at all due to the error copied below. Does this make sense in light
of the changes that you've made Jean-Michel? I sent most of the output
from *source
New_Build_Script.txt *to a text file called *out*, which I have also
attached.
Thanks!
*ggjhtw at eslogin007:~/MITgcm/91Ma_obcs_0.1degree_bio/build> source
New_Build_Script.txt > out*
*ptracers_advection.f(2271): error #6404: This name does not have a type,
and must have an explicit type. [GPTR]*
* O gPtr(1-OLx,1-OLy,1,1,1,iTracer),*
*------------------------------^*
*compilation aborted for ptracers_advection.f (code 1)*
*make[1]: *** [ptracers_advection.o] Error 1*
*make: *** [fwd_exe_target] Error 2*
*ggjhtw at eslogin007:~/MITgcm/91Ma_obcs_0.1degree_bio/build>*
On 28 August 2014 15:50, Jonny Williams <Jonny.Williams at bristol.ac.uk>
wrote:
> Hi there
>
> For your information, updating the pkg/gchem/gchem_forcing_sep.F file on
> its own has not worked unfortunately. I am currently updating the whole
> code tree in case there are any cross-dependencies which I have missed.
>
> I have not attempted running with OBNptrFile,OBSptrFile,OBEptrFile,OBWptrFile
> included as yet. Is clear however from the crash results that the errors
> are 'propagating' from the open boundaries!
>
> Thanks again
>
> Jonny
>
>
> On 23 August 2014 16:56, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
>
>> Hi Jonny,
>>
>> I made some changes in pkg/gchem/gchem_forcing_sep.F (CVS revision 1.36),
>> adding a (2nd) call to OBCS_APPLY_PTRACER that I think is needed since,
>> currently, nothing prevent pkg/dic to modify/update the ptracers fields
>> beyond the OB lines.
>>
>> It has not yet been carefully tested (we will try to check this in the
>> coming days), but if you want to give it a try (needs to get the latest
>> MITgcm code).
>>
>> An other thing with OBCS that might bring some instabilities in ptracer
>> fields
>> is that, since you don't specify any OB values for ptracers (from your
>> "data.obcs",
>> OBNptrFile,OBSptrFile,OBEptrFile,OBWptrFile are not set) you are relying
>> on the "default ptracer option" for ptracer OBCS which is sometimes
>> problematic.
>> Might be usefull to try to specify these OB fields to check this aspect.
>>
>> Cheers,
>> Jean-Michel
>>
>> On Fri, Aug 22, 2014 at 04:42:36PM +0100, Jonny Williams wrote:
>> > 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
>>
>>
>>
>>
>>
>> > _______________________________________________
>> > 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
>
--
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/20140828/6b45f217/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out
Type: application/octet-stream
Size: 446907 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140828/6b45f217/attachment-0001.obj>
More information about the MITgcm-support
mailing list