[MITgcm-support] Forcing files in data.dic (biogeochemistry)
Jean-Michel Campin
jmc at ocean.mit.edu
Thu Aug 28 13:44:39 EDT 2014
Hi Jonny,
Regarding question (1), it would be usefull to know
when was the last time you updated your MITgcm code (full code),
or if you did not before, when you downloaded it.
the top of MITgcm/doc/tag_index (down to the latest "checkpoint???")
is generally a good indicator.
The information about gchem_forcing_sep.F is one thing, but it does not
tell much about the other parts of the code.
Regarding question (4): can you try:
cd /home/n02/n02/ggjhtw/MITgcm/
cd pkg/ptracers
cvs -q -n update -A
just to list (but will do nothing) how this dir compares with
the latest MITgcm/pkg/ptracers code.
and let us know what this command output is.
Cheers,
Jean-Michel
On Thu, Aug 28, 2014 at 06:07:43PM +0100, Jonny Williams wrote:
> Hi Jean-Michel
>
> In answer to your questions
>
> 1. the previous version of gchem_forcing_sep.F was "1.32 2013/07/04", it
> is now at 1.37.
> 2. no, I don't think so!
> 3. yes I did clean the directory, I have a script which basically does
> the same things as make Clean
> 4. I used the instructions on that same website using "cvs update -d -P"
> in the root ~/MITgcm directory which is from the section of the website
> that you recommend. This took approximately 20 minutes or so to update the
> whole directory tree. The ptracers_advection.F file is still present in
> ~/MITgcm/pkg/ptracers
>
> I hope this is helpful information!
>
> Many thanks
>
> Jonny
>
>
>
> On 28 August 2014 17:40, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
>
> > Hi Jonny,
> >
> > 1) what was the version of the code you were working with
> > (or last time you updated your MITgcm code) ?
> > 2) do you have customized source file in your local "../code" dir ?
> > they might need to be updated to account for the changes (updates)
> > between the latest MITgcm code and the one you had before.
> > 3) I don't know what is in script "New_Build_Script.txt", but
> > did you clean-up your build dir (make Clean) before ?
> > 4) And regarding ptracers_advection.F (where the error comes from),
> > this source file has been removed (~ 8 months ago) in the latest code.
> > How did you update your MITgcm code ?
> > There are few tips about the use of CVS there:
> > http://mitgcm.org/public/using_cvs.html
> > and in particular, the section "Getting updates from the repository".
> >
> > Cheers,
> > Jean-Michel
> >
> > On Thu, Aug 28, 2014 at 04:21:54PM +0100, Jonny Williams wrote:
> > > 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
> > @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
> >
> >
> > > _______________________________________________
> > > 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
More information about the MITgcm-support
mailing list