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

Jean-Michel Campin jmc at ocean.mit.edu
Thu Aug 28 13:57:04 EDT 2014 

Hi Jonny,

Just a detail:
I generally avoid to do a strait "cp", because sym-links will not
be preserved but will get instead a "real" copy.
For instance, all the *.F links in any build dir will ended up
being really copied to a real file, that "make Clean" will never
clean.

I prefer intead to go through a tar file (which preserve the links).

Cheers,
Jean-Michel

On Thu, Aug 28, 2014 at 06:32:54PM +0100, Jonny Williams wrote:
> Thanks Jody
> 
> The new checkout is a good idea. What I originally did was to copy my old
> directory to MITgcm.orig and then try and update the other one!
> 
> Thanks a lot.
> 
> Jonny
> 
> 
> On 28 August 2014 18:25, Jody Klymak <jklymak at uvic.ca> wrote:
> 
> > Hi Jonny,
> >
> > I don't think cvs update *removes* any files, so your old copy of
> > ptracers_advection.F is still there.  You could just remove it by hand.
> >
> > However, if it was me, I'd move ~/MITgcm to MITgcm.old and simply re
> > checkout the code into a fresh MITgcm directory.
> >
> > Cheers,   Jody
> >
> >
> > On Aug 28, 2014, at  10:07 AM, Jonny Williams <
> > Jonny.Williams at bristol.ac.uk> 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 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
> >>
> >>
> >> > _______________________________________________
> >> > 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

> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support

More information about the MITgcm-support mailing list