<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Laura, Karl<br>
<br>
Regarding Karl's three points:<br>
<br>
1) Indeed what Karl said it's true. Our discussion around DRS is
precisely because it's not mandated.<br>
I think we made quite a few mistakes in this, if we had had
delivered proper tools in time, there should have been no need for
data centers to come up with different directory structures.<br>
<br>
2) the drslib is not intended for CMIP3, it will/might be used for
that purpose though. It mainly produces a valid DRS structure out of
any files in other structure (including CMOR2). I think Stephen can
comment more on this if required.<br>
<br>
3) In my opinion, the recommendation is useful for datacenters, but
not on an archive level. We must cope with data centers not
complying to this, so it's the same as if there where no
recommendation at all.<br>
<br>
I know the main idea is to create a middleware layer that would make
file structures obsolete. But then, we will have to write all tools
again in order to interact with this intermediate level or at least
patch them somehow. gridFTP, as well as ftp, are only useful as
transmission protocols, you can't write your own script to use them,
you have to rely on either the gateway or the datanode to find what
you are looking.<br>
In my opinion, we will be relying too much in the ESG
infrastructure. What would happen if we loose the publisher
database? How would we tell apart one version from another, if this
is not represented in the directory structure?<br>
My fear is that if we keep separating the metadata from the data
itself, we add a new weak link in the chain. Now if we loose the
metadata the data will also be useless (this would be indeed the
worst case scenario). In 10 years we will have no idea what this
interfaces were like, probably both data node and gateways will be
superseded by newer versions that can't translate our old
requirements. But as I said, that's a problem for LTAs only. In any
case, we need the middleware to provide some services and speed
things up, but I don't think we should rely blindly on it.<br>
<br>
And regarding CMOR2, indeed it was designed to be flexible, but
drslib also relies on the same CMOR tables to separate what output1
and 2 is. And there's no magic in drslib regarding versioning, it
must be input by hand. Why this functionality was kept away from
CMOR2 is not really clear to me. What ever it was, I'm not sure it
work the best for all configurations regarding who create,
post-processes and publish the data.<br>
<br>
I don't mean we should change any of these, it's too late and that
wasn't the point anyway. I just thought that it is worth the
discussion, especially for the future.<br>
<br>
Thanks,<br>
Estani<br>
<br>
Am 02.09.2011 00:02, schrieb Karl Taylor:
<blockquote cite="mid:4E600108.1050405@llnl.gov" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<font face="Times New Roman">Dear Laura,<br>
<br>
Thank you for providing an important perspective on this. I
agree that misunderstanding and poor communication about this
has caused considerable confusion.<br>
<br>
Here's some short answers to your questions, followed by a more
complete discussion that others may also want to read carefully:<br>
<br>
1. It is *not* true that CMIP5 or ESG mandate a specific
directory structure, although DRS document recommends for CMIP5
a specific directory structure. Note that for reanalysis data,
which falls under the "obs4MIPs" project, the recommended (again
not required) directory structure differs from CMIP5.<br>
<br>
2. The directory structure produced by CMOR2 is not identical
to the directory structure for CMIP*3* data stored at PCMDI. It
also differs from the "final" form of the recommended (not
required) directory structure for CMIP5. I'm not sure if drslib
(</font><a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://esgf.org/esgf-drslib-site/index.html">http://esgf.org/esgf-drslib-site/index.html</a>)
can convert from CMIP3 to final recommended CMIP5 directory
structure, but I know it can convert from the default
CMOR2-produced directory structure to final CMIP5 structure
(although I didn't see this mentioned in the drslib documentation)<font
face="Times New Roman">.<br>
<br>
3. </font>The recommended procedure for treatment of CMIP5
data is to write it using CMOR2 (without overriding the default
directory structure it produces) and then use drslib (or
equivalent) to produce the final directory structure.<br>
<br>
Now for some discussion....<br>
<font face="Times New Roman"><br>
For ESG, there is no directory structure imposed. When datasets
are published, information is recorded that enables users
(through gateways) to access the data they want (without any
knowledge of directory structures). The directory structures
recommended for CMIP5 and for the "obs4MIPs" activity are
different, but this does not hamper ESG from serving them and
searching them, because it doesn't really care about directory
structure.<br>
<br>
For CMIP5 (which is only one of the projects served by ESG),
cmor2 creates a directory structure that is a reasonable way to
organize the output, and CMOR2 can generate filenames according
to a template required by CMIP5, as described in the DRS
document.<br>
<br>
For CMIP5 the DRS document recommends (but does *not* require)
a final directory structure. Because this is only a
recommendation, individual data nodes may choose to organize
their data to fit their own local requirements.<br>
<br>
The DRS specifies a controlled vocabulary, and various
"descriptors" of CMIP5 datasets that are stored in catalogs at
the data nodes. This information can be accessed in various
ways, but by "reading" the catalogs (which are xml files), a
user can obtain the URL that can be used to get the data. The
uniformity in structure for all CMIP5 catalogs ensures that
software can be written to automatically translate between a set
of DRS descriptors that uniquely identify the data being sought
and a list of (possibly *non-uniformly* structured)
directories/filenames containing that data. Thus the ESG
gateway can generate wget scripts that can be run to download
the data even when the directory structures differ from one node
to another. Presumably other tools could get the URL's
similarly.<br>
<br>
By the way, CMOR2 was designed to meet the needs of many
different projects, not just CMIP5, so having it generate
automatically directory structures consistent with the
requirements of these different projects is difficult. For one
thing, the "output" descriptor called for by the DRS requires a
complicated algorithm unique to CMIP5 and thus this information
is unknown by CMOR2. Also the version number (which appears in
the final recommended DRS directory structure) is based on the
("publication") date of the dataset. Since a dataset comprises
many different variables, perhaps written on different days, it
would be impossible for CMOR2 to assign this date automatically,
which is why the version number is assigned when the data are
published. Thus, the full, final directory structure
*recommended* by CMIP5 cannot be assigned by CMOR2.<br>
<br>
So, those are the rules for CMIP5: the directory structure is
not mandated, but it is certainly recommended. I think that
using drslib is a good way to put CMOR2 output in the
recommended DRS directory structure, and I don't *think* other
steps are required.<br>
<br>
Please let me know if you have questions, and please feel free
to respond.<br>
<br>
Best regards,<br>
Karl<br>
<br>
<br>
</font><br>
On 9/1/11 12:55 PM, Laura Carriere wrote:
<blockquote cite="mid:4E5FE330.1020407@nasa.gov" type="cite">
<pre wrap="">For what it's worth, I'm going to add my own perspective, one that comes
from someone who is managing the team that is publishing the data at
NASA/GSFC but is not involved in writing the code or producing the
data. In other words, I'm sure there's lots I don't understand, but
here's what I have managed to decipher.
I'll start by saying that we don't have a strong opinion about what
directory structure is used. Our focus is on providing users quick
access to data that is accurate and easily identified. Our initial
understanding was that CMOR2 would create the correct DRS file structure
but we have since learned that this is not the case. We were also under
the impression that the DRS file structure was "recommended" not
"required". This, also, appears not to be the case.
After learning that we weren't using the correct file structure, we
re-read the documentation more carefully but we were still left not
really knowing what the expectations were.
First I read the CMIP5 Data Reference Syntax (DRS) and Controlled
Vocabulary documentation:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://cmip-pcmdi.llnl.gov/cmip5/docs/cmip5_data_reference_syntax.pdf">http://cmip-pcmdi.llnl.gov/cmip5/docs/cmip5_data_reference_syntax.pdf</a>
Section 3.1, shows the DRS structure we were creating by using CMOR2,
and 3.3 shows the DRS structure that we are supposed to be creating.
It also states that there is an expectation that we are responsible for
"transforming" the CMOR2 structure to the recommended structure. I
found this surprising so I checked the CMOR2 release notes and found
that there's no reference to modifying CMOR2 to have an option to
produce the new DRS structure so it became clear that we needed to do
this ourselves.
I then looked at the drslib page:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://esgf.org/esgf-drslib-site/index.html">http://esgf.org/esgf-drslib-site/index.html</a>
This is a utility to convert a CMIP3 directory structure to
DRS-compliant form but since our team is quite new to the IPCC activity,
we don't know if what CMOR2 creates is CMIP3 or not.
That left us not knowing if there were any tools to do what we had been
asked to do. The data provider was willing to recreate the data with
the missing directories so we republished all the data we had had the
time. However, that doesn't really help us with the next data provider
who is just now starting to give us data.
What I would like to be able to find is a simple way for the data
providers (who are running CMOR2 but are not publishing the data) to
prepare the directory structure in a way that is compliant. I would
rather not ask them to wade through all the above documentation and
translate the directory structure themselves because they are busy
enough as it is.
Ideally I would like to be able to tell them to use a particular option
to CMOR2 to create the right structure but such an option doesn't
exist. The second best option would be some clarification on the use of
drslib. Specifically, can it be run on the directory structure that
CMOR2 produces and will it then produce a compliant directory structure
that we can publish? And are there any additional steps required?
So, in the interests of improving communication, I suggest that someone
remove the word "recommended" from sections 3.1 and 3.3 in the DRS
document, explain why it's "required" and the repercussions of not
complying and also add instructions on how to get to the "required"
structure. In an ideal world, an option would be added to CMOR2 to do
this there.
As I said, this is just my perspective from the data publication side.
Please feel free to enlighten me on what I've missed. Thanks.
Laura Carriere
On 9/1/2011 4:58 AM, Kettleborough, Jamie wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
Isn't one issue that for some applications the *interface* with the data
is at the *file system level* - not the catalogues? Version management,
QC look like they are examples, and replication may be too (and I think
these are pretty much federation wide activities/applications). So if
you want to minimise the complexity (~= minimise time to develop, cost
of maintenance) in the way these applications interact with the data you
want to ensure consistency in the way data stored in the file system.
Bryan - I wasn't sure what interfaces you were talking about... Sorry.
I'm going to be a bit pedantic here - but I don't think the DRS document
says that data nodes must follow the DRS directory structure, its only a
recommendation. Though there *may* be a slight inconsistency in the way
the DRS is written as it says the URLS *will* be a site dependant prefix
followed by the
*DRS directory structure*. At least that's my reading of the 1.2
version dated 9th March. I don't think all nodes are following the DRS
specification for the URLS because they don't have the same underlying
directory structure. I don't know if the way the DRS is written or
being interpreted is one of the sources of misunderstanding over this
issue of DRS directory structure? (This is not a criticism, its an
acceptance that communicating specification and plans is a hard problem
to crack).
Another (possibly week) motivation for keeping all data in the DRS
directory structure is it gives you a last ditch back up strategy - if
you loose the catalogues you can regenerate the version info etc from
the file system.
Jamie
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:go-essp-tech-bounces@ucar.edu">go-essp-tech-bounces@ucar.edu</a>
[<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:go-essp-tech-bounces@ucar.edu">mailto:go-essp-tech-bounces@ucar.edu</a>] On Behalf Of Bryan Lawrence
Sent: 01 September 2011 08:55
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a>
Cc: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:stockhause@dkrz.de">stockhause@dkrz.de</a>
Subject: Re: [Go-essp-tech] Non-DRS File structure at data nodes
Hi Folks
</pre>
<blockquote type="cite">
<pre wrap="">At least it's now clear to me, that we can't rely on the
</pre>
</blockquote>
<pre wrap="">DRS structure
</pre>
<blockquote type="cite">
<pre wrap="">so we should try to cope with this.
</pre>
</blockquote>
<pre wrap="">I'm just coming back to this, and I haven't read all of this
thread, but I don't agree with this statement! If we can't
rely on the DRS *at the interface level*, then ESGF is
fundamentally doomed as a distributed activity, because we'll
never have the resource to support all the possible variants.
Behind those interfaces, more flexibility might be possible,
but components would need to be pretty targetted in their
functionality.
Bryan
</pre>
<blockquote type="cite">
<pre wrap="">Thanks,
Estani
Am 31.08.2011 12:55, schrieb <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:stephen.pascoe@stfc.ac.uk:">stephen.pascoe@stfc.ac.uk:</a>
</pre>
<blockquote type="cite">
<pre wrap="">Hi Estani,
I see you have some code in esgf-contrib.git for managing
</pre>
</blockquote>
</blockquote>
<pre wrap="">a replica
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">database. There's quite a lot of drs-parsing code there.
</pre>
</blockquote>
</blockquote>
<pre wrap=""> Is there
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">any reason why this couldn't use drslib?
Cheers,
Stephen.
---
Stephen Pascoe +44 (0)1235 445980
Centre of Environmental Data Archival STFC Rutherford Appleton
Laboratory, Harwell Oxford, Didcot OX11 0QX, UK
-----Original Message-----
From: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:go-essp-tech-bounces@ucar.edu">go-essp-tech-bounces@ucar.edu</a>
[<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:go-essp-tech-bounces@ucar.edu">mailto:go-essp-tech-bounces@ucar.edu</a>] On Behalf Of Estanislao
Gonzalez
Sent: 31 August 2011 10:23
To: Juckes, Martin (STFC,RAL,RALSP)
Cc: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:stockhause@dkrz.de">stockhause@dkrz.de</a>; <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a>
Subject: Re: [Go-essp-tech] Non-DRS File structure at data nodes
Hi Martin,
Are you planning to publish that data as a new instance
</pre>
</blockquote>
</blockquote>
<pre wrap="">or as a replica?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">If I recall it right, Karl said he thought the replica
</pre>
</blockquote>
</blockquote>
<pre wrap="">was attached
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">at a semantic level. But I have my doubts and haven't got
</pre>
</blockquote>
</blockquote>
<pre wrap="">any feed
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">back on this. does anyone know if the gateway can handle
</pre>
</blockquote>
</blockquote>
<pre wrap="">a replica
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">with a different url path? (dataset and version "should" be the
same, although keeping the same version will be
</pre>
</blockquote>
</blockquote>
<pre wrap="">difficult, because
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">no tool can handle this AFAIK, i.e. replicating or publishing
multiple datasets with different versions)
And regarding replication (independently from the previous
question), how are you going to cope with new versions? Do you
already have tools for harvesting the TDS and building a list of
which files do need to be replicated, regarding from what
</pre>
</blockquote>
</blockquote>
<pre wrap="">you already have?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The catalog will just publish a dataset and version along with a
bunch of files, you would need to keep a DB with the fies you've
already downloaded, and compare with the catalog to realize what
should be done next. This information is what drslib
</pre>
</blockquote>
</blockquote>
<pre wrap="">should use to
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">create the next version. Is that what will happen? If
</pre>
</blockquote>
</blockquote>
<pre wrap="">not, how will you be solving this?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Thanks,
Estani
Am 31.08.2011 10:54, schrieb <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:martin.juckes@stfc.ac.uk:">martin.juckes@stfc.ac.uk:</a>
</pre>
<blockquote type="cite">
<pre wrap="">Hello Martina,
For BADC, I don't think we are considering storing data
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">in anything
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">other than the DRS structure -- we just don't have the time to
build systems around multiple structures. This means
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">that data that
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">comes from a node with a different directory structure
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">will have to
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">be re-mapped. Verification of file identities will rely on
check-sums, as it always will when dealing with files
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">from archives
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">from which we have no curation guarantees,
cheers,
Martin
________________________________
From: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:go-essp-tech-bounces@ucar.edu">go-essp-tech-bounces@ucar.edu</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">[<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:go-essp-tech-bounces@ucar.edu">go-essp-tech-bounces@ucar.edu</a>]
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">on behalf of Martina Stockhause [<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:stockhause@dkrz.de">stockhause@dkrz.de</a>] Sent: 31
August 2011
09:44
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</a>
Subject: [Go-essp-tech] Non-DRS File structure at data nodes
Hi everyone,
we promised to describe the problems regarding the non-DRS file
structures at the data nodes. Estani has already started the
discussion on the replication/user download problems
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">(see attached
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">email and document).
Implications for the QC:
- In the QCDB we need DRS syntax. The DOI process,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">creation of CIM
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">documents, and identification of the data the QC results are
connected to rely on that. - The QC needs to know the version of
the data checked. The DOI at the end of the QC process
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">is assigned
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">to a specific not-changable data version. At least at
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">DKRZ we have
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">to guarantee that the data is not changed after
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">assignment of the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">DOI, therefore we store a data copy in our archive. - The QC
checker tool runs on files in a given directory structure and
creates results in a copy of this structure. The QC
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">wrapper can deal with recombinations of path parts.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">So, if the directory structure includes all parts of the DRS
syntax, the wrapper can create the DRS syntax before
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">insert in the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">QCDB. But we deal with structures at the data nodes, where some
information is missing in the directory path, i.e.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">version and MIP
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">table. Therefore an additional information would be
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">needed for that mapping.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Possible solutions to map the given file structure to the DRS
directory structure before insert in the QCDB:
1. The publication on the data nodes of the three gateways who
store replicas (PCMDI, BADC, DKRZ) publish data in the DRS
directory structure. Then the QC run is possible without
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">mapping.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Replication problems?
2. The directory structures of the data nodes are replicated as
they are. We store the data under a certain version.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">How? Are there
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">implications for the replication from the data nodes? The
individual file structures down to the chunk level are stored
together with its DRS identification in a repository and
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">a service
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">is created to access the DRS id for the given file in the given
file structure. The QC and maybe other user data
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">services use this
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">service for mapping. That will slow down the QC insert process.
Before each insert of a chunk name, a qc result for a specific
variable, and the qc result on the experiment level that service
has to be called. And who can set-up and maintain such a
repository? DKRZ has not the man power to do that in the
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">next months.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Cheers,
Martina
-------- Original-Nachricht --------
Betreff: RE: ESG discussion
Datum: Wed, 10 Aug 2011 15:35:04 +0100
Von: Kettleborough,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Jamie<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:jamie.kettleborough@metoffice.gov.uk"><jamie.kettleborough@metoffice.gov.uk></a><<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:jamie.kettl">mailto:jamie.kettl</a>
eborough@
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">metoffice.gov.uk> An: Karl
Taylor<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:taylor13@llnl.gov"><taylor13@llnl.gov></a><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:taylor13@llnl.gov"><mailto:taylor13@llnl.gov></a>, Wood,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Richard<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:richard.wood@metoffice.gov.uk"><richard.wood@metoffice.gov.uk></a><<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:richard.wood@met">mailto:richard.wood@met</a>
office.go
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">v.uk> CC: Carter,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Mick<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:mick.carter@metoffice.gov.uk"><mick.carter@metoffice.gov.uk></a><<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:mick.carter@metoffice.gov">mailto:mick.carter@metoffice.gov</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">.uk>
, Elkington,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Mark<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:mark.elkington@metoffice.gov.uk"><mark.elkington@metoffice.gov.uk></a><<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:mark.elkington@metoffi">mailto:mark.elkington@metoffi</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">ce.g
ov.uk>, Bentley,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Philip<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:philip.bentley@metoffice.gov.uk"><philip.bentley@metoffice.gov.uk></a><<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:philip.bentley@metof">mailto:philip.bentley@metof</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">fice
.gov.uk>, Senior,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Cath<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:cath.senior@metoffice.gov.uk"><cath.senior@metoffice.gov.uk></a><<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:cath.senior@metoffice.gov">mailto:cath.senior@metoffice.gov</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">.uk>
, Hines,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Adrian<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:adrian.hines@metoffice.gov.uk"><adrian.hines@metoffice.gov.uk></a><<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:adrian.hines@metoffice">mailto:adrian.hines@metoffice</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">.gov .uk>, Dean N.
Williams<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:williams13@llnl.gov"><williams13@llnl.gov></a><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:williams13@llnl.gov"><mailto:williams13@llnl.gov></a>,
Estanislao
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Gonzalez<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:gonzalez@dkrz.de"><gonzalez@dkrz.de></a><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:gonzalez@dkrz.de"><mailto:gonzalez@dkrz.de></a>,<martin.juckes@
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">stfc .ac.uk><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:martin.juckes@stfc.ac.uk"><mailto:martin.juckes@stfc.ac.uk></a>, Kettleborough,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Jamie<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:jamie.kettleborough@metoffice.gov.uk"><jamie.kettleborough@metoffice.gov.uk></a><<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:jamie.kettleboro">mailto:jamie.kettleboro</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">ugh@
metoffice.gov.uk>
Hello Karl, Dean,
Thanks for you reply on this, and the fact you are taking our
concerns seriously. You are right to challenge us for
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">the specific
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">issues, rather than us just highlighting the things that
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">don't meet
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">our (possibly idealised) expectations of how the system should
look. As a result, we have had a thorough review of our key
issues. I think some of them are issues that make if
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">harder for us
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">to do things now; other issues are maybe more concerns
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">of problems
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">being stored up. This document has been prepared with the help
Estani Gonzalez. We would like to have Martin Juckes
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">input on this
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">too - but he is currently away on holiday. I hope he can add to
this when he returns - he has spent a lot of time thinking about
the implications of data node directory structure on
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">versioning. I
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">hope this helps clarify issues, if not please let use
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">know, Thanks,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Jamie
________________________________
From: Karl Taylor [<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:taylor13@llnl.gov">mailto:taylor13@llnl.gov</a>]
Sent: 09 August 2011 01:48
To: Wood, Richard
Cc: Carter, Mick; Kettleborough, Jamie; Elkington, Mark;
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Bentley,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Philip; Senior, Cath; Hines, Adrian; Dean N. Williams
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Subject: Re:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">ESG discussion
Dear all,
Thanks for taking the time to bring to my attention the
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">ESG issues
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">that I hope can be addressed reasonably soon. I think we're in
general agreement that the user's experience should be improved.
I've discussed this briefly with Dean. I plan to meet
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">with him and
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">others here, and, drawing on your suggestions, we'll attempt to
find solutions and methods of communication that might
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">improve matters.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Before doing this, it would help if you could briefly answer the
following questions:
1. Is the main issue that it is currently difficult to script
downloads from all the nodes because only some support
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">PKI? What
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">other uniformity among nodes is required for you to be
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">able to do
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">what you want to do (i.e., what do you specifically want
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">to do that
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">is difficult to do now)? [nb. all data nodes are
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">scheduled to be
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">operating with PKI authentication by September 1.]
2. Is there anything from the perspective of a data *provider*
that needs to be done (other than make things easier for
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">data users)?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">3. Currently ESG and CMIP5 do not dictate the directory
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">structure
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">found at each data node (although most nodes are adhering to the
recommendations of the DRS). The gateway software and
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">catalog make it
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">possible to get to the data regardless of directory
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">structure. It
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">is possible that "versioning" might impose additional
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">constraints
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">on the directory structure, but I'm not sure about this.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""> (By the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">way, I'm not sure what the "versioning" issue is since
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">currently I
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">think it's impossible for users to know about more than one
version; is that the
issue?) From a user's or provider's perspective, is there any
essential reason that the directory structure should be
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">the same at
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">each node?
4. ESG allows considerable flexibility in publishing data, and
CMIP5 has suggested "best practices" to reduce
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">differences. Only
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">some of the "best practices" are currently requirements.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""> A certain
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">amount of flexibility is essential since different data
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">providers
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">have resources to support the potential capabilities of
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">ESG (e.g.,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">not all can support server-side calculations, which will
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">be put in place at some nodes).
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Likewise a provider can currently turn off the
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">"checksum", if this
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">is deemed to slow publication too much (although we could insist
that checksums be stored in the thredds catalogue).
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Nevertheless,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">it is unlikely that every data node will be identically
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">configured for all
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">options. What are the *essential* ways that the data
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">nodes should
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">respond identically (we may not be able to insist on uniformity
that isn't essential for serving our users)?
Thanks again for your input, and I look forward to your further
help with this.
Best regards,
Karl
On 8/5/11 10:43 AM, Wood, Richard wrote:
Dear Karl,
Following on from our phone call I had a discussion with
technical
colleagues here (Mick Carter, Jamie Kettleborough, Mark
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Elkington,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">also earlier with Phil Bentley), and with Adrian Hines who is
coordinating our CMIP5 analysis work, about ideas for
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">future development of the ESG.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Our observations are from the user perspective, and
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">based on what
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">we can gather from mailing lists and our own experience.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Coming out
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">of our discussion we have a couple of suggestions that
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">could help
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">with visibility for data providers and users:
- Some areas need agreement among the data nodes as to the
technical solution, and then implementation across all
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">the nodes,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">while others need a specific solution to be developed in
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">one place and rolled out.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The group teleconferences that Dean organises appear to
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">be a good
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">forum for airing specific technical ideas and solutions.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">However,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">in our experience it can be difficult in that kind of forum to
discuss planning and prioritisation questions. From our
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">perspective
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">we don't have visibility of the more project-related
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">issues such as
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">key technical decisions, prioritisation and timelines, or of
whether issues that have arisen in the mailing list
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">discussions are
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">being followed up. We guess these may be discussed in separate
project teleconferences involving the technical leads
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">from the data
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">nodes. As users we would not necessarily expect to be
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">involved in
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">those discussions, but as data providers and dowloaders
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">it would be
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">very helpful for our planning to see the outcomes of the
discussions. The sort of thing we had in mind would be a
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">simple web
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">page showing the priority development areas, agreed
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">solutions and
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">estimated dates for completion/release. Some solutions
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">will need to
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">be implemented separately across all the participating
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">data nodes,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">and in these cases it would be useful to see the
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">estimated timeframe for implementation at each node.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">This would not be intended as a 'big stick' to the partners, but
simply as a planning aid so that everyone can see what's
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">available
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">when and the project can identify any potential
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">bottlenecks or issues in advance.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Also the intention is not to generate a lot of extra work.
Hopefully providing this information would be pretty
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">light on people's time.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- From where we sit it appears that some nodes are quite
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">successful
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">in following best practice and implementing the
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">federation policies
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">as far as they are aware of them. Could what these nodes
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">do be made
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">helpful to all the data nodes (e.g. by using identical
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">software)?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We realise there may be real differences between some
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">data nodes -
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">but where possible we think that what is similar could
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">be enforced
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">or made explicitly the same through sharing the software
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">components and tools.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">To set the discussion on priorities rolling, Jamie has
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">prepared, in
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">consultation with others here, a short document showing the Met
Office view of current priority issues (attached). If you could
update us on the status of work on these issues, that
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">would be very
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">useful (ideally via the web pages proposed above, which we think
would be of interest to many users, or via email in the
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">interim).
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Many thanks for the update on tokenless authentication,
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">which is very good news.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> Once again, our thanks to you, Dean and the team for
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">all the hard
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> work
we know is going into this. Please let us know what you think of
the above ideas and the attachment, and if there is
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">anything we can
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">do to help.
Best wishes,
Richard
--------------
Richard Wood
Met Office Fellow and Head (Oceans, Cryosphere and Dangerous
Climate
Change)
Met Office Hadley Centre
FitzRoy Road, Exeter EX1 3PB, UK
Phone +44 (0)1392 886641 Fax +44 (0)1392 885681 Email
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:richard.wood@metoffice.gov.uk">richard.wood@metoffice.gov.uk</a><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:richard.wood@metoffice.gov.uk"><mailto:richard.wood@metoffice.gov.uk></a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.metoffice.gov.uk">http://www.metoffice.gov.uk</a> Personal web page
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.metoffice.gov.uk/research/scientists/cryosphere-oceans/r">http://www.metoffice.gov.uk/research/scientists/cryosphere-oceans/r</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">ichar
d-wood
*** Please note I also work as Theme Leader (Climate System) for
the Natural Environment Research Council ***
*** Where possible please send emails on NERC matters to
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:rwtl@nerc.ac.uk">rwtl@nerc.ac.uk</a><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:rwtl@nerc.ac.uk"><mailto:rwtl@nerc.ac.uk></a> ***
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">--
Bryan Lawrence
University of Reading: Professor of Weather and Climate
Computing National Centre for Atmospheric Science: Director
of Models and Data
STFC: Director of the Centre of Environmental Data Archival
Phone +44 1235 445012; Web: home.badc.rl.ac.uk/lawrence
_______________________________________________
GO-ESSP-TECH mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
GO-ESSP-TECH mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a>
</pre>
</blockquote>
<pre wrap="">
--
Laura Carriere <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:laura.carriere@nasa.gov">laura.carriere@nasa.gov</a>
SAIC 301 614-5064
_______________________________________________
GO-ESSP-TECH mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
GO-ESSP-TECH mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Estanislao Gonzalez
Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
Phone: +49 (40) 46 00 94-126
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:gonzalez@dkrz.de">gonzalez@dkrz.de</a> </pre>
</body>
</html>