Hi All,
Here's a bit more info from the NCAR system admins regarding the recent
problems with the mailman list:
> Our mailman server came under heavy attack last week, and still is. The
focus
> is attempted bogus subscriptions to the exposed lists at a rate of about
4 every
> 10 seconds. We have
Hi All,
An extra bit of info on this. The trac and mailman lists are indeed
independent. They are synchronized by hand. As moderator of the
cf-metadata mailman list I keep a list of new subscriptions and removals
from the list and every now and then I forward that list to folks at
PCMDI. So
Hi Martin and David,
When I was writing about scalar coordinate variables in the CF convention,
I considered a scalar to be a zero dimensional object. That is distinct
from a 1 dimensional array which happens to only have 1 component. A
coordinate array in the NUG sense is a one dimensional
David,
Looks like the problem is on the CGD end. I've asked the sys admins to
have a look. Thanks for the report.
Brian
On Tue, Apr 21, 2015 at 9:04 AM, David Hassell d.c.hass...@reading.ac.uk
wrote:
Hello,
Another website issue, I'm afraid: When I click on CF Metadata
Mailing List
All,
Our sys admins have informed me that a mailman software upgrade has changed
the URL. The archive is now at
http://mailman.cgd.ucar.edu/mailman/private/cf-metadata/. The
cfconventions.org site will need to update this link.
I found that accessing the archive required me to enter a password
Hi John,
Thanks for your comments. I completely agree. The archive should be
public, and if its URL does change then we should deal with the redirect
here. I've spoken with admins here and made these requirements known.
Apparently this last mailman upgrade caused plenty of headaches, so we
I agree with Heiko's comment.
Jonathan, are you thinking that CF disallows packing of coordinates because
we neglected to explicitly include them in Table A.1? I think this was
just an oversight. I don't have any recollection that we intended to
disallow packing coordinates, and I don't find
Hi All,
I don't believe there was ever an intention to disallow missing values from
auxiliary coordinate variables. First, note that the definition of an
auxiliary coordinate variable in section 1.2 makes no mention of this while
it is explicit in the definition of a coordinate variable that
Hi John,
You might have a look at the ESMF time handling utilies for some ideas
about what a library that supports modelling (i.e., non-standard calendars)
contains.
http://www.earthsystemmodeling.org/esmf_releases/public/last/ESMF_refdoc/
Brian
On Fri, Apr 01, 2011 at 05:04:42AM -0600, John
The checker also didn't recognize that the a and b variables are being
used to describe a dimensionless vertical coordinate. So I'm wondering
whether the coordinate variable, lev(lev), has the standard_name and
formula_terms attributes that should allow the checker to recognize them.
Brian
On
) ;
lev_bnds:formula = p = a*p0 + b*ps ;
lev_bnds:standard_name =
atmosphere_hybrid_sigma_pressure_coordinate ;
lev_bnds:units = 1 ;
lev_bnds:formula_terms = p0: p0 a: a_bnds b: b_bnds
ps: ps ;
- Kyle
On 02/23/2011 01:37 PM, Brian Eaton wrote
Hi Karl,
The discussion concerning the introduction of the scalar coordinate
variable is available in the archive (July 2003 under the subject size-one
axes). There was never a decision to disallow the bounds attribute.
Although it could be more explicitly stated in the current document, I
Hi Jonathan,
I'm wondering about this statement:
I don't think it's misleading. This is a consistent rule in CF standard
names: quantities with different canonical units must have different standard
names.
Isn't the use of cell_methods with a value of variance an example where
we don't
Hi John,
I agree. The first version is incorrect.
Brian
On Sat, Oct 11, 2008 at 03:29:28PM -0600, John Caron wrote:
Not sure if this is a typo or a minor misunderstanding, but in Chapter 5,
intro, paragraph 3, this line
We recommend that the name of a multidimensional coordinate
14 matches
Mail list logo
