Thanks, Sophie, for your quick response. Given your clarification,
perhaps we might replace the description of ice_sheet, which currently
reads:
> ice_sheet: An area type of "ice sheet" indicates where ice sheets are
> present. It includes both grounded ice sheets resting over bedrock
:45 +
From: Alison Pamment - UKRI STFC
To: 'Karl Taylor' , Martin Juckes - UKRI STFC
, "CF-metadata (cf-metadata@cgd.ucar.edu)"
Subject: Re: [CF-metadata] Precipitation fractions for LS3MIP
Dear Martin, Jonathan, Karl,
I have had another look at these two names a
Hi Alison and Martin,
I haven't confirmed this with a web search, but I think albedo is
generally reserved for the ratio of reflected solar radiation to
incident solar radiation, considering the full spectrum. It is a
special case of "reflectance" restricted for use with the full spectrum
be some "heat flux" of interest. This would mean "added at a
different temperature" may not be quite the right way to describe
things. Again not sure of this.
best regards,
Karl
On 6/9/18 8:23 AM, Karl Taylor wrote:
Hi Martin,
Regarding
heat_flux_into_snow_and_ice_on_
to refer to the body of snow and ice on
land which is the recipient of the heat here -- my last suggestion was
"snow_and_ice_on_land", but that discussion is still open. Here, we could use
"heat_flux_into_snow_and_ice_on_land_due_to_rainfall".
(4) On reflection it may be clearer to say
surface_upward_latent_heat_f
Dear Alison, Martin, and Jonathan,
I just spent the last hour going over Alison's email and composed the
following comments before seeing Martin's response and not being aware
of Jonathan's comments on Tuesday. I think most of my comments are
still relevant.
best regards,
Karl
Hi Alison
Hi all,
I think in common usage "mass fraction" is the ratio of the mass of a
particular species to the total mass of all species combined (e.g., the
mass fraction of oxygen molecules in air). For the variable considered
here, the fraction refers to the ratio of the mass of as particular
ase already used.
Thus I end up with
fraction_of_precipitation/rainfall/snowfall_amount_falling_onto_surface_snow
and if that's still not quite transparent to parse, we could consider saying
which_falls instead of falling. Neither is yet used in standard names.
Best wishes
Jonathan
- Forwarde
Hi Martin,
For CMIP6, I think we define precipitation = rainfall + snowfall .
So do you want to collect "precipitation amount" or "rainfall amount"
(in addition to "snowfall amount")? You first mention "rainfall" below,
but later propose a name for "precipitation".
I also think it is a
05 +0000
From: Martin Juckes - UKRI STFC <martin.juc...@stfc.ac.uk>
To: Karl Taylor <taylo...@llnl.gov>, Jonathan Gregory
<j.m.greg...@reading.ac.uk>, "cf-metadata@cgd.ucar.edu"
<cf-metadata@cgd.ucar.edu>
CC: "yves.balkan...@lsce.ipsl.fr&
Hi all,
Thanks to everyone making the push to get all the names defined for
CMIP6. Alison, who must be working close to full time on this, deserves
special recognition.
best wishes,
Karl
On 5/17/18 7:41 AM, Alison Pamment - UKRI STFC wrote:
Dear All,
The standard name and area type
Dear Alison, Martin, and all
On the last point commented on by Martin:
"4.3-4.7 Perturbed radiation calculations"
I wonder if it is wise to assign a new name every time experiment
conditions change. I would limit names to quantities that are
calculated independently by a physics model or
Haven't been following this, but how about
isotope_ratio_of_18O_to_16O_in_H2O (or H2O_molecules or water_molecules)
best,
Karl
On 5/8/18 7:26 AM, Jonathan Gregory wrote:
Dear Martin and Alison
10, 11: yes, this is the ratio of oxygen isotope atoms in the sea water molecules. It is
true
in our efforts to improve the situation.
regards,
Martin
From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf of Sebastien Villaume
<sebastien.villa...@ecmwf.int>
Sent: 13 April 2018 17:30
To: Karl Taylor
Cc: cf-metadata
in favour of proposing new standard names by prefixing existing
standard names with "ocean_" !
/Sébastien
- Original Message -
From: "Karl Taylor" <taylo...@llnl.gov>
To: cf-metadata@cgd.ucar.edu
Sent: Wednesday, 11 April, 2018 18:
Hi all,
Just to summarize some of what has been said before
I think it is pretty clear that the solid phase can take several forms,
as Martin points out. I think the more subtle issue is that frozen
water is not quite the same as solid water, if we take the strict
definition of
Dear Sebastien,
One option would be to include in cell_methods the following:
cell_methods = "depth: mean (from surface to sea floor)"
where depth is the standard name for the vertical coordinate, as
provided for in
Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.
-Original Message-
From: Karl Taylor [mailto:taylo...@llnl.gov]
Sent: 15 March 2018 23:58
To: P
Hi Erik,
If the mean is a straightforward average of the 600 per-second samples
(at 23:10:00, 23:10:01, 23:19:59), then this most accurately
represents (according to the "Midpoint Rule") a mean for the period
extending from 23:09:59.5 to 23:19:59.5, so those should be your bounds.
the interval represented by the mean you
are reporting (23:10:00 - 23:20:00), and you should estimate that mean
using 601 samples, but weighting the first and last sample half as much
as the others.
best regards,
Karl
On 3/26/18 9:00 AM, Karl Taylor wrote:
Dear Erik,
I think one could argue
Dear Erik,
I think one could argue that a "sample" taken *on* the second is most
representative of an interval extending from half a second prior to the
sample time and half a second following the sample time, so, for
example, a sample at 1 sec represents the interval from 0.5 to 1.5
ers agree?
Best wishes,
Alison
--
Alison Pamment Tel: +44 1235 778065
NCAS/Centre for Environmental Data ArchivalEmail: alison.pamm...@stfc.ac.uk
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.
-Original Message--
Hi Chris and Alison,
Thanks to both of you for all the good progress and considerable thought
required to approve all these new names. Thanks also to anyone else how
contributed.
Perhaps it will inspire others to engage in the processing of other
proposed names.
cheers,
Karl
On 3/12/18
I noticed that "subsurface_litter_carbon_content" has the same
"definition" as "surface_litter_carbon_content": "Content" indicates a
quantity per unit area. "Litter carbon" is dead plant material in or
above the soil quantified as the mass of carbon which it contains. The
surface called
Dear all,
I think what Roy proposes is o.k., but I would worry if we allowed the
use of "-" (hyphen) in standard_name. I think that could be a mistake,
even though I can't come up with a strong argument. (perhaps something
about parsing being more difficult? or reserving hyphens for
with the
CF-mandated attributes. Does anyone disagree?
thanks,
Karl
On 1/1/18 4:47 PM, Chris Barker wrote:
On Wed, Dec 20, 2017 at 2:21 PM, Karl Taylor <taylo...@llnl.gov
<mailto:taylo...@llnl.gov>> wrote:
My sense is that no one violently opposes the use of missing_value
ame number
of vertices. Consistent with the last paragraph, I suggest
that we should
recommend the use of the existing convention for that case,
rather than the
simple geometries convention.
Best wishes
Jonathan
- Forwarded message f
Forgive me. Since "X" and "Y" are just placeholders for the actual
variables, it's obviously not important if they were exchanged from
normal practice in the discussion. The important thing is whatever
follows "of" in the construct is the integrand.
thanks,
Ka
Hi all,
I think "X" should be the independent variable and "Y", the dependent
variable (appearing as the integrand). I would then prefer
"integral_over_X_of_Y" or "integral_of_Y_over_X" (although I wouldn't
object if the consensus is that "wrt" should replace "over"). [I don't
like
Dear Jonathan and all,
Regarding the options for representing polygon cells with varying number
of sides (see below), I agree that the "simple geometries" proposal can
indeed handle this case. ( It of course could also handle the case when
all grid cells have the same number of sides.)
I
HI all,
Consider a grid consisting of both triangular and rectangular grid cells
with n total grid cells. In this case the cell_bounds for longitude
could be dimensioned (n, 4) because there are a maximum of 4 cell vertices.
My question is, for the triangular grid cells do we *require* the
not to mention your tremendous direct contributions to climate science.
Congratulations and best wishes,
Karl
On 7/27/17 9:59 AM, V Balaji - NOAA Affiliate wrote:
... on being elected a Fellow of the AGU!
CF would not be even a smidgen as useful in enabling so much science
without your
Yes I agree.
Karl
On 7/21/17 2:41 AM, Jonathan Gregory wrote:
Dear Martin
The words upwelling and downwelling were chosen specifically with the intention
of indicating the sign convention! Upwelling means positive upwards,
downwelling means positive downwards, in standard names. If that's not
that, for the moment, this discussion won't prevent the
creation of this new standard_name !
Best regards
Stéphane Tarot
Le 21/06/2017 à 17:57, Karl Taylor a écrit :
Hi all,
I don't like "from_direction" as a construct (I know it's already
accepted for "wind_from_direction&quo
Hi all,
I don't like "from_direction" as a construct (I know it's already
accepted for "wind_from_direction" and it is clearly explained in the
notes but wouldn't
"direction_of_wind_vector_tail" or
"wind_vector_tail_direction or
"tail_direction_of_wind_vector"
be more obvious?
(for the
level_for_geoid:m
s-1
surface_geostrophic_northward_sea_water_velocity_assuming_sea_level_for_geoid:m
s-1
surface_geostrophic_sea_water_x_velocity_assuming_sea_level_for_geoid:m
s-1
surface_geostrophic_sea_water_y_velocity_assuming_sea_level_for_geoid:m
s-1
Best wishes
Jonathan
- Forwarded message from Karl Taylor <taylo...@llnl.go
Dear all,
I kinda like the idea of changing "above sea level" to "above mean sea
level", but it still remains somewhat vague, since the period over which
the mean is computed isn't specified. Or is there some accepted time?
In any case maybe it is o.k. to be vague
best regards,
Karl
Hi all,
I don't think the issue of 2-d auxiliary coordinates entered the
discussion leading to their allowance by CF 1.6 (but I only quickly
reviewed the discussion). I think that allowing the axis attribute to
be attached to an auxiliary coordinate that is 1-d can be useful (e.g.,
when a
Hi Sebastien,
More than one group stored output on a tripolar grid in CMIP5. I'm
pretty sure they did it in a CF-conforming way. I know at least some of
the GFDL model output was reported on a tripolar grid, as described at
http://nomads.gfdl.noaa.gov/CM2.X/oceangrid.html (or search on
ttom of
the atmosphere
> differently.
>
> Having said that, I can't recall the discussion about the new
OMIP surface
> names, so I think we should wait for Alison's summary.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message f
rently.
Having said that, I can't recall the discussion about the new OMIP surface
names, so I think we should wait for Alison's summary.
Best wishes
Jonathan
- Forwarded message from Karl Taylor <taylo...@llnl.gov> -
Date: Thu, 23 Mar 2017 09:27:08 -0700
From: Karl Taylor <taylo
On 3/21/17 9:20 AM, Jonathan Gregory wrote:
Dear Karl
sea_surface_height_above_geoid
I'm not sure it's true that "In an ocean GCM the geoid is the
surface of zero depth". Many ocean models have an ocean surface
that rises above the geoid in some areas and falls below in other
areas.
Hi all,
I've been looking at the standard names used to describe the vertical
location of the sea surface and have some questions.
sea_surface_height_above_geoid
The geoid is a surface of constant geopotential with which mean sea
level would coincide if the ocean were at rest. (The volume
Dear Bob and all,
I have not had time to follow this thread in detail, but a remark (in
the most recent email) that seemed unnecessarily sarcastic caught my
eye, and impelled me to look into what might have led to this dip in our
normally courteous, respectful discourse. As Chair of the CF
Hi Alison and Jonathan,
I'm confused by the following discussion:
17. land_ice_mass_not_displacing_sea_water (kg)
The name and units are agreed. I suggest the following as the definition:
' "Land ice not displacing sea water" means land ice that would not alter sea
level if removed. It
From my perspective, it would make sense to use the existing
convention and look into a more structured encoding if there is a specific
requirement for it.
regards,
Martin
________
From: Karl Taylor [taylo...@llnl.gov]
Sent: 06 January 2017 17:29
To: Jonathan Gre
Hi Martin and Jonathan,
An alternative would be to (generally) allow elemental area_types to be
combined with logical not/and/or connectors. area_types are used either
as labels (stored in a variable pointed to by the coordinates attribute)
or in cell_methods. In both cases parsing combined
Hello,
The histogram records frequencies of a single characteristic of a
variable (in this case for cloud top height). I think that information
about whether or not a cloud exists should not be formally a part of the
histogram. We could adopt the convention for this variable that in the
Hi all,
I have a question from Robert Pincus that I don't know that answer to:
Is it ok to use a one-dimensional “string” variable instead of a
two-dimensional character variable to encode expt_label? This might be asking
whether it’s ok to use netCDF4, which I certainly hope is the case.
strings as numbers in a data variable, but since the process is reversible the
mechanism works both ways! If you think that this use of the convention is not
obvious as it stands, then I would propose that we insert an extra sentence in
Sect 3.5 pointing out the use of this mechanism to encode strin
Hi all,
Perhaps we should define a new standard_name: e.g., basin_index (or
region_index) to replace the misused "region" standard_name.
I would note that in the conventions document in example 3.3 there is a
standard name: "sea_water_speed status_flag"
"status_flag" is a standard "name
Hi All,
Note that "cloud" is listed as a valid area_type in
http://cfconventions.org/Data/area-type-table/4/build/area-type-table.html
In CMIP5 I used the following to describe the time mean surface
temperature of sea ice.
cell_methods = "time: mean (weighted by area of sea ice)"
At the
Hi all,
For unstructured grids when some cells are quadralaterals and others are
pentagons, the convention stipulates that bounds should be dimensioned
(n,5) so that the lat and lon locations of all 5 penatagon vertices can
be recorded. My question is what to do about the extra vertex for
ng, please edit your Subject line so it is more specific
than "Re: Contents of CF-metadata digest..."
Today's Topics:
1. Re: Confusing skin temperature and interface temperature
(Karl Taylor)
------
M
each the person managing the list at
cf-metadata-ow...@cgd.ucar.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CF-metadata digest..."
Today's Topics:
1. Re: Co
re for Environmental Data Analysis Email:
alison.pamm...@stfc.ac.uk <mailto:j.a.pamm...@rl.ac.uk>
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Campus, Didcot, OX11 0QX, U.K.
*From:*CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] *On
Behalf Of
Dear Alison and all,
For "sea_surface_temperature", there is a problem stating definitively
that it is "not the skin or interface temperature". In most models the
skin and interface temperatures over ice-free (i.e., open) ocean are
indeed the same as sea_surface_temperature (by
agreed a convention for doing that, as extra info.
Alternatively you could record it as unstandardised info as a comment in () in
the cell_methods, as you note.
Best wishes
Jonathan
----- Forwarded message from Karl Taylor <taylo...@llnl.gov> -
Date: Wed, 10 Feb 2016 15:37:01 -0800
the climatologies?
best regards,
Karl
On 2/11/16 10:15 AM, Jim Biard wrote:
Karl,
I think you should be able to handle this in the bounds variable. If
you write the first entry as "2000-12-1", "2010-03-01", doesn't that
describe things correctly?
Grace and peace,
Jim
On 2
Dear Alejandro,
I hope someone else will also check this, but I'm pretty sure you've
done it correctly. I would note that "time: mean within days time: mean
over days" implies in your example that fluxes are 1-hour mean amounts
averaged for each hour of the day over all days in the month.
Dear CF community,
In representing the seasonal climatology based on data available for the
period January 1, 2000 through December 31 2010, what would be the
correct climatology_bounds?
climatology_bounds = "1999-12-1", "2011-3-1",
"2000-3-1", "2010-6-1",
ket #98 could be reopened as an enhancement ...
All the best,
David
Original message from Karl Taylor (01PM 21 Dec 15)
> Date: Mon, 21 Dec 2015 13:59:33 -0800
> From: Karl Taylor <taylo...@llnl.gov <mailto:taylo...@llnl.gov>>
> To: cf-metadata@cgd.uc
points out
that this is not a convention. That's as close as it gets. If it was
there in the past it is gone now.
Grace and peace,
Jim
On 12/22/15 12:07 PM, Karl Taylor wrote:
Hi John,
this is a bit of a tangent, but you state:
"Another possible use case is to represent contiguous bounds, where
l
Hi David,
I can't think of anyone needing these constructs, although there are
cases when both the "parent" and ancillary or formula_terms variable
might *both* have a scalar dimension.
Karl
On 12/21/15 7:41 AM, David Hassell wrote:
Hello,
I was wondering if anyone has ever had use for an
Dear Ajay,
Since "month" is not a proper unit of measure, convert your times to
days and use a unit "days since ...".
Also, it is normally a bad idea to have your base time set to a date
before the switch from Julian to Gregorian calendar. I suggest using a
base time of "1955-01-01" (i.e.,
Yes.
Karl
On 8/5/15 3:12 PM, John Kerfoot wrote:
Hello,
This is likely a noob question, but I'm wondering if CF conventions
allow for multiple variables to have the same standard name in the
same NetCDF file?
Thanks,
John
___
CF-metadata
Hi all,
This addresses the issue of how to associate an ensemble size with a
variable. It also suggests an alternate way of proceeding that is more
general and will allow us to record, for example, which models were
included in a multi-model mean.
First to consider Jim's suggestion:
I
in the CF documentation.
Jim
On 7/20/15 12:51 PM, Karl Taylor wrote:
Dear Jim,
Yes, there are definitely cases like the one you mention where one
shouldn't use the simple (approx.) gregorian calendar. Any
measurements taken during the leap second would have to be either
shifted in time or dropped
...@cgd.ucar.edu] on behalf of Karl Taylor
[taylo...@llnl.gov]
Sent: 08 July 2015 01:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Specifying latitude and longitude of transects and
regions
Hi Martin, Mark, and all,
I can see that theoretically one might want to define a transect
Hi Jonathan and Jim,
Thanks for bearing with me as I educate myself and think about this
stuff. I rethought further about what I said yesterday and realized
that maybe we were still making this too complicated. Jonathan's
discussion helped me to come up with the following:
Starting with
Dear Jim and Jonathan,
Having tried to learn about UTC and GPS time systems, I think we'll need
to find a way to explain to CF users in a simple way what calendar they
should use and when.
The GPS system relies on 24-hour (exactly 86400 sec) wall-clock
without leap seconds added, which
Dear Jonathan and Jim,
I'm o.k. with placing UTC or GPS as part of the calendar attribute
(rather than in the units). Your arguments in favor of that option make
sense to me now.
Jim, I think the second bullet (*) point is important and makes sense to
me. I hope this doesn't mean we're
Hi Martin, Mark, and all,
I can see that theoretically one might want to define a transect, but do
we have any compelling use case to do this at the moment? I don't think
CMIP6 is such a case.
cheers,
Karl
On 7/1/15 6:33 AM, Hedley, Mark wrote:
Hello Martin,
If the two end points can be
Hi all,
I haven't followed all this as closely as I would have liked, but will
hazard some comments anyway:
1. I think we should require that elapsed time (recorded by the
time-coordinate in CF files) be correct no matter what the calendar. So
samples taken at a specific interval have
, Jim Biard wrote:
Karl,
On 6/29/15 2:00 PM, Karl Taylor wrote:
Hi all,
I haven't followed all this as closely as I would have liked, but
will hazard some comments anyway:
1. I think we should require that elapsed time (recorded by the
time-coordinate in CF files) be correct no matter what
Hi Martin,
I guess the question is why the longitude and latitude of end points
would be of interest to anyone. I guess you could make a case for
seeing whether a modeler had computed the transect for some region that
doesn't correspond to the strait (or comparable feature) of interest,
but
Hi Charlie (Carlos),
I'm pretty sure the cell_methods should only be an attribute of a
non-coordinate variable (*not* an attribute of time).
Your 1-step and 2-step methods will yield the same answer (if you keep
track of how long each season is when you do the averaging, and you
weight the
Hi Jim,
Looks helpful. I wonder if you could convince the unidata folks to link
to this from their udunits webpage. That would be quite useful. It
would of course have to be kept up to date.
cheers,
Karl
On 6/12/15 6:27 AM, Jim Biard wrote:
Hi.
I have just made a web page that contains
Hi all,
Normally CF doesn't prohibit extra attributes being defined, so I'm not
sure whether the checker should be objecting. That being said, I don't
think the convention should sanction attaching a cell_methods to a
coordinate variable *instead* of attaching it to a regular variable
In a similar position (of understanding) as John, I agree with him.
Karl
On 5/20/15 7:43 AM, John Graybeal wrote:
Without fully appreciating _all_ the particulars (sorry!), I think Jonathan's
diagnostic (that people would tend to keep using gregorian) is correct. I like
the idea of a warning
Dear all,
I have not followed all the arguments over the last few weeks, but the
summary below seems sensible to me. I don't think it will cause
significant harm to eliminate standard calendar as an option and
restricte the gregorian calendar to be one without leap seconds.
best regards,
Dear all,
I agree with this view.
Karl
On 5/5/15 9:52 AM, Jonathan Gregory wrote:
Dear all
I agree with the view that we shouldn't be more restrictive about which year
should be chosen for supplying climatological time coords. It is an arbitrary
choice (in fact the coord is always arbitrary
thanks, Brian, for attending to this. We'll hold off. Let us know if
we need to make changes once you've got things in order on your end.
best regards,
Karl
On 4/21/15 9:57 AM, Brian Eaton wrote:
Hi John,
Thanks for your comments. I completely agree. The archive should be
public, and
Dear all,
Just to confirm, that I've verified there's a problem and we're looking
into it.
thanks,
Karl
On 4/20/15 8:54 AM, Jonathan Gregory wrote:
Dear all
I can't access the CF trac ticket server http://cf-trac.llnl.gov/trac at
present. Is it having problems, does anyone know?
Cheers
techniques) but
1.I'm not sure there has been much exchange of non-model data using
'realization' (please correct me if I'm wrong)
2.The term 'realization' has caused confusion
Jamie
*From:*CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] *On
Behalf Of *Karl Taylor
*Sent:* 07 November 2014
Hi Mark,
One example I know of:
area_type is a string type variable with standard values taken from:
http://cfconventions.org/Data/cf-standard-names/27/src/area-type-table.xml
This was used in CMIP5. The units in the standard name table are given
as 1.
best regards,
Karl
On 10/3/14, 3:59
further comments or ideas then please let me know.
Thanks,
Dan
*From:* CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] *On
Behalf Of *Karl Taylor
*Sent:* 11 September 2014 00:44
*To:* cf-metadata@cgd.ucar.edu
*Subject:* Re
Russ and all,
One aspect of netCDF-4 we almost certainly expect to make use of for
CMIP6 is the automated compression option. As far as I know, this
does not affect the conventions. If you see a problem with this, please
let me know right away.
Karl
lem any
On 9/10/14, 9:16 AM, Russ Rew
Hi Dan, Seth, and all,
I'm not sure I understand what the practice is; do you calculate the
daily mean from the max and min temperature that you read at 0900 GMT.
If so, then I think it is straight-forward: the max and min
temperatures occurred in the 24 hour period ending at 0900 GMT, and
Dear Mark,
I agree with Jonathan, that it is a different quantity and needs a
different standard name. Since it is extensive, the default (and
correct) cell_methods is sum. Although no longer a function of lat,
lon, and depth, you would probably want to define those as (scalar)
coordinate
I forgot to reply to list. Here it is.
Original Message
Subject: Re: [CF-metadata] Request for new standard-names: graupel,
wind_gust, inland_water_area_fraction
Date: Thu, 22 May 2014 09:47:37 -0700
From: Karl Taylor taylo...@llnl.gov
To: John Graybeal john.grayb
Dear Natalia, Jonathan, and all,
I don't think maximum (interval: 1 day) would be explicit enough for
the variable precipitation_amount. It wouldn't distinguish between
precipitation_amounts accumulated over each 24 hour period or some
shorter interval (say, from 8 to 11 each morning).
Dear Rich and all,
PCMDI lost its server a while back and we're in the process of migrating
to github: http://cf-convention.github.io/ where much of the website
has been reconstructed (but we're still working on the standard names doc).
In the meantime the standard name table can be
Hi Stephen, Charlie, and all,
I was unaware that there was a cfchecker based on cdat. Is that the one
at the CF Trac site or the one at https://bitbucket.org/mde_/cfchecker ?
Does anyone know whether one of the cfcheckers is more
complete/correct/robust than the other?
If one is superior,
All,
Yes, that statement seems quite definitive and unambiguous, and for the
reasons stated in other emails, I support retaining it.
regards,
Karl
On 1/15/14 9:37 AM, Steve Hankin wrote:
On 1/15/2014 9:24 AM, Jim Biard wrote:
Chris,
The point is, the Conventions themselves state that
10, 2014, at 11:30 AM, Karl Taylor taylo...@llnl.gov
mailto:taylo...@llnl.gov wrote:
Dear Randy, Jonathan, and all,
I agree that the hybrid choice with twilight rather than
terminator, is clearest.
Just to cover all the options (or maybe to revisit a suggestion I
missed earlier), could new
Dear Randy, Jonathan, and all,
I agree that the hybrid choice with twilight rather than terminator,
is clearest.
Just to cover all the options (or maybe to revisit a suggestion I missed
earlier), could new area_type(s) be defined -- day, night, twilight --
and then we could just use the
Hi all,
I don't find area_fraction_of_solar_zenith_angle to be understandable
and I'm not sure the phrase makes sense. I don't see how you can have
an area of a solar zenith angle (or an area_fraction of an angle).
One could also be misled into thinking this was somehow related to the
directions lately. Hopefully, it is
possible to bring back to life a submission that I had made for the
land_surface_skin_temperature.
Revisiting my previous proposal and a few e-mails by Karl Taylor and
Evan Manning, I have made some modifications to the definition of
this standard name so that I
Hi all,
Again, I may be unaware of all the possible uses of hierarchies, but
here's our experience with CMIP.
It seems to me if hierarchies are for the purpose of organizing
datasets (or organizing a bunch of files), this should fall outside CF's
purview because a single hierarchy is rarely
1 - 100 of 171 matches
Mail list logo
