Dear all
I agree that ensemble_member_identifier is likely to be more self-explanatory
than realization. I withdrew my suggestion of the former because I'd
forgotten, when I made it, that we already had the latter as a standard name.
If ensemble_member_identifier is preferred, we could change the
name based on the term
'ensemble' might be useful.
Jamie
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu
[mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Nan Galbraith
Sent: 06 April 2010 21:30
To: John Caron
Cc: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata
Hi All -
The term realization is, apparently, *perfectly* clear to you
modelers, but it conveys no information at all to me.
Since it looks like it's going to be adopted, I hope you'll provide
a really clear definition in the standard - something that even an
oceanographer will understand.
All,
Nan's point deserves consideration. Well-chosen names should help the
uninitiated to understand the concepts that CF is encoding.
Realization is arguably the opposite sort of term; the sort of term
that clicks as being sensible only _after_ one understands the range of
concepts that
All,
Another option might be ensemble_realization. At least if you search
the web you will find reasonable guidance (whereas this is likely not
the case for realization alone).
Karl
On 06-Apr-10 2:50 PM, Steve Hankin wrote:
All,
Nan's point deserves consideration. Well-chosen names
Dear Seth
This may be complicating the issue more than resolving it, but how about in
some way applying the ensemble dimension to the CF global attributes for
source
and institution, rather than transplanting the information into auxiliary
coordinates?
This could be done, but isn't there a
Dear John
it sounds like a modest proposal is to recommend either of
these attributes to identify the ensemble coordinate variable:
axis = ensemble;
standard_name = realization;
with the idea of keeping it simple.
For auxiliary coordinate variables of the ensemble axis,
other
based on the definitions it would be nice to see source_institution
(or institution_where_produced) and source_method (or
source_provenance), in order to avoid collisions. just a thought, I
know it's not CF-ish to imagine far-flung-future problems so feel free
to ignore it!
john
On Mar
This may be complicating the issue more than resolving it, but how about in
some way applying the ensemble dimension to the CF global attributes for source
and institution, rather than transplanting the information into auxiliary
coordinates?
It could also be done for the global history
Jonathan Gregory wrote:
Dear all
realization is fine as a standard name. I had forgotten we had introduced it.
I withdraw my suggestion of ensemble_member_identifier.
Thus, the standard name (of realization) can be used to identify an ensemble
axis. I think that providing an axis attribute as
Dear all
realization is fine as a standard name. I had forgotten we had introduced it.
I withdraw my suggestion of ensemble_member_identifier.
Thus, the standard name (of realization) can be used to identify an ensemble
axis. I think that providing an axis attribute as well could be helpful:
In the absence of a standard, I have also made some choices about how
to handle ensemble metadata with GrADS and the GDS. Below is a
shortened example of the ncdump output from a GFS ensemble data set
behind GDS. I put the metadata that GrADS needs in customized
attributes (e.g.
Jonathan Gregory writes:
Dear John
Im not sure if we ever converged on how to write ensemble files.
No, we didn't. If I remember correctly, we couldn't agree on the relationship
between attributes and coordinates, and that was a sticking-point. I thought
that we ought to allow multivalued
Hi Jennifer, in this instance, how do you know its an ensemble
dimension, as opposed to say, a wavelength ? is it
ens:long_name = ensemble member
??
On 3/16/2010 12:36 PM, Jennifer Adams wrote:
In the absence of a standard, I have also made some choices about how
to handle ensemble metadata
Hi Doug:
Looks to be the same as Paco's. Do you know what was modified?
On 3/16/2010 1:46 PM, Doug Schuster wrote:
NCAR uses a modified version of Paco's file structure for TIGGE output.
All ensemble members found in the file require the same single model
initialization time, the same
On 3/16/2010 11:22 AM, Jonathan Gregory wrote:
Dear John
Im not sure if we ever converged on how to write ensemble files.
No, we didn't. If I remember correctly, we couldn't agree on the relationship
between attributes and coordinates, and that was a sticking-point. I thought
that
John,
I think the standard names and basic template are all the same. The
only difference is that
the structure we're using for TIGGE has 4 variable dimensions vs 5,
where the 5th allows for multiple forecast initialization times.
On Mar 16, 2010, at 3:43 PM, John Caron wrote:
Hi Doug:
Where the 5th dimension allows for multiple levels I meant to say.
The files NCAR produces for TIGGE are all on one fixed level, with one
fixed forecast initialization time.
Doug
On Mar 16, 2010, at 5:16 PM, Doug Schuster wrote:
John,
I think the standard names and basic template are all
On Mar 16, 2010, at 5:30 PM, John Caron wrote:
Hi Jennifer, in this instance, how do you know its an ensemble
dimension, as opposed to say, a wavelength ? is it
ens:long_name = ensemble member
Grads knows it's an ensemble by the attribute:
ens:grads_dim = e ;
I could just as easily look
Im not sure if we ever converged on how to write ensemble files.
Particularly, how does software recognize the ensemble dimension?
I have an example file:
netcdf C:/data/CMIP3_Rank_Qensemble_4D.nc {
dimensions:
model = 2;
latitude = 97;
longitude = 93;
time = 13;
variables:
20 matches
Mail list logo
