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

Thu Sep 11 05:17:37 EDT 2014

Hi again

A further update to this rather long ongoing thread! After becoming
suspicious that divergent air-sea flux of carbon was to blame for my model
crashing, I turned this flux completely off and this has fixed my problem,
at least in the short term. I did this by adding "FluxCO2(i,j,bi,bj) = 0.
_d 0" in dic_surfforcing.F.

I will continue to experiment with how to get around this problem in the
longer term but any tips would still be gratefully received ;)

Thanks for for everyone's help thus far.

Jonny

On 4 September 2014 10:19, Jonny Williams <Jonny.Williams at bristol.ac.uk>
wrote:

> Hi everyone
>
> I just thought that I would update this thread to let you know that I have
> found a solution to my persistent problem of the DIC variable diverging in
> my version of the MITgcm.
>
> Basically it was to do with sharp changes in bathymetry. Limiting the
> ocean depth to 3km globally has fixed this issue which is great for now but
> is clearly not a long term solution.
>
> What is not at all clear to me however is why the DIC variable was being
> affected but none of the other biogeochemical variables (alkalinity, PO4,
> DOP and O2) were.
>
> Does anyone have any ideas about why this might be?
>
> Many thanks!
>
> Jonny
>
>
> On 29 August 2014 14:30, Jonny Williams <Jonny.Williams at bristol.ac.uk>
> wrote:
>
>> Hi again
>>
>> Sorry for taking up so much room in people's inboxes!
>>
>> I think I'm getting somewhere now. I have implemented the OBCS boundary
>> conditions for the DIC variable but I am still getting the same crash
>> although it does not seem to be coming from the open boundaries any more
>> which is good!
>>
>> What I think may be happening now is that the surface fluxes are going a
>> bit haywire, as (I think) indicated in the dic_tave* output files. Since
>> the model I am dealing with is of such high resolution (0.1 degree) there
>> are tiny gridboxes which are side-by-side of very different magnitudes and
>> I think that the numerics may not be able to deal with this?
>>
>> For now, is there a way to turn of the surface flux of co2/dic just to
>> check that the advection (etc) are behaving themselves?
>>
>> Thanks!
>>
>> Jonny
>>
>>
>> On 29 August 2014 09:33, Jonny Williams <Jonny.Williams at bristol.ac.uk>
>> wrote:
>>
>>> I've downloaded the whole MITgcm tree from scratch again and the
>>> compilation now works with regard to the pkg/gchem/gchem_forcing_sep.F
>>> changes which Jean-Michel has made so that's great!
>>>
>>> On the other hand the model is still crashing with the same NaNs
>>> propagating out from the open boundaries and so I am going to try using the
>>> OBNptrFile,OBSptrFile,OBEptrFile,OBWptrFile option.
>>>
>>> I am assuming that the dimensions of these files should be...
>>>
>>> (length of boundary) x (number of depth levels) x (number of tracers)
>>>
>>> and that the order of the tracers is dic, alk, po4, dop, o2
>>>
>>> Cheers
>>>
>>> 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
>>
>
>
>
> --
> 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/20140911/c0a94f81/attachment-0001.htm>