[CF-metadata] Use of axis attribute in an auxillary coordinate

would make it clearer to you that CF declares that the height scalar variable mentioned in this discussion qualifies as a true or full or complete (or whatever word you prefer) coordinate and is not relegated to auxiliary coordinate status? Grace and peace, Jim On 7/31/17 10:10 AM, martin.juckes at

Re: [CF-metadata] Definiton of solar_irradiance

nce * diffuse_horizontal_irradiance * global_horizontal_irradiance with solar_irradiance as an alias for total_solar_irradiance, or vice versa, but I think we shouldn't alter the definition of solar_irradiance. Grace and peace, Jim On 1/26/18 11:52 AM, martin.juckes at stfc.ac.uk<http://mailman.cgd

Re: [CF-metadata] Definiton of solar_irradiance

Hello Roy, Jim, OK, I agree with Jim that renaming "solar_irradiance" as "total_solar_irradiance" will remove any problems with the definition (the definition is fine, but "solar irradiance" has a broader meaning outside CF). For the horizontal irradiance, there is a specific CMIP6 requirement

Re: [CF-metadata] Definiton of solar_irradiance

Hello Roy, maybe .. but I was talking about the current definition of the CF standard name "solar_irradiance", which, currently, has nothing to do with the vertical, regards, Martin From: Lowry, Roy K. [r...@bodc.ac.uk] Sent: 26 January 2018 20:35 To: Juckes,

Re: [CF-metadata] Definiton of solar_irradiance

Dear Roy, If we were starting from scratch I would recommend the following: Solar irradiance is the power per unit area of the solar radiation received from above at horizontal surface. It is distinct from the Direct Normal Irradiance (which refers to radiation received by a surface

Re: [CF-metadata] Definiton of solar_irradiance

Hello Roy, I suspected that there might be such a usage ... but don't you agree that the current CF definition, which I've quoted below, is inconsistent with this? But it could be adapted with a small change of wording, regards, Martin From: Lowry, Roy K.

[CF-metadata] Definiton of solar_irradiance

Hello, the cf standard name has a definition: The quantity with standard name solar_irradiance, often called Total Solar Irradiance (TSI), is the radiation from the sun integrated over the whole electromagnetic spectrum and over the entire solar disk. The quantity applies outside the

Re: [CF-metadata] Use of axis attribute in an auxillary coordinate

;mailto:jbiard><mailto:jbiard<mailto:jbiard>>>> > at > cicsnc.org<http://cicsnc.org><http://cicsnc.org><http://cicsnc.org><http://cicsnc.org>>> > wrote: > > Martin, > > We just had some discussion ab

Re: [CF-metadata] Use of axis attribute in an auxillary coordinate

on about the proper use of the axis > attribute, but this seems to me like it might be a flaw in the > checker. As a scalar coordinate, height can only be associated > with the tas variable via the coordinates attribute (per section > 5.7), but I don't think that makes it

Re: [CF-metadata] Use of axis attribute in an auxillary coordinate

gt; We just had some discussion about the proper use of the axis > attribute, but this seems to me like it might be a flaw in the > checker. As a scalar coordinate, height can only be associated > with the tas variable via the coordinates attribute (per section > 5.7), but

Re: [CF-metadata] Use of axis attribute in an auxillary coordinate

ly be associated > with the tas variable via the coordinates attribute (per section > 5.7), but I don't think that makes it an auxiliary coordinate, > does it? > > What do other people think? Chime in! > > Grace and peace, > > Jim > > >

[CF-metadata] Use of axis attribute in an auxillary coordinate

te, height can only be associated > with the tas variable via the coordinates attribute (per section > 5.7), but I don't think that makes it an auxiliary coordinate, > does it? > > What do other people think? Chime in! > > Grace and peace, > >

[CF-metadata] Another CF complaince checker -- from IOOS --- with some issues

Dear All, Jonathan makes a fair point that there is no such thing as certified CF compliance. On sample files with interesting errors, the CMIP5 archive provides an interesting range of examples. In the process of trying to provide constructive feedback to the IOOS team I shrank (by reducing

[CF-metadata] Sign convention of upwelling and downwelling fluxes

Hello All, there are standard names for a number of upwelling and downwelling fluxes, defined clearly as the component of radiation which is travelling upwards or downwards. The sign convention of these fluxes is not specified .. CMIP uses the convention that downwelling is positive down and

[CF-metadata] Another CF complaince checker -- from IOOS --- with some issues

Hello All, Following discussions with a colleague (As Stephens) I've taken a look at the IOOS compliance-checker, which contains a module for checking how files comply with the CF convention. I looked at 4 files with known CF errors, and found an average of two erroneous reports per file

Re: [CF-metadata] Is "psu" a valid cf unit?

Hello All, This appears to have stirred up quite a lot. I think Balaji is raising a point that has not been picked up: if we have a physical quantity which varies in a small range around 35, then reporting the full value (e.g. 35.346) is going to give less precision than reporting an anomaly

Re: [CF-metadata] Is "psu" a valid cf unit?

Hello All, After some hunting, I found a copy of a letter from Frank Millero (1993 - "What is PSU") ( http://www.marbef.org/wiki/Salinity_sensors -- box on right) which is adamant that PSU is not a unit and the "Joint Panel on Oceanographic Tables and Standards" has made this clear in their

Re: [CF-metadata] Is "psu" a valid cf unit?

Thanks Roy, David, Ros: do you accept Roy's answer? If so, cf-python and the cf-checker should presumably be updated to flag "psu" as an invalid unit? regards, Martin From: Lowry, Roy K. [r...@bodc.ac.uk] Sent: 18 July 2017 14:00 To: Juckes, Martin

[CF-metadata] Is "psu" a valid cf unit?

Hello David, all, Is "psu" a valus CF unit? It is not in Udunits, but it is added in cf-python as a unit alias and also appears to be accpeted by the cf-checker. I can't see any mention of it in the CF Convention document: the latter only lists level, layer, and sigma_level permitted

[CF-metadata] Use of axis attribute in an auxillary coordinate

Hello All, I'd just like to check one aspect of the conformanc document, which came to our attention when somebody ran the CF checker on some CMIP5. If you check using the convention version declared in the file, 1.4, it will raise an error if there is a scalar coordinate variable with the

[CF-metadata] An area type for non-ocean water surfaces

Hello All, Stephane Senesi has raised the issue that some CMIP6 models may have a finite area of river water, and this should be recorded as an area type (https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/85).

[CF-metadata] New standard names for OMIP biogeochemistry and chemistry

Hello All, I'd like to support Alison on point 4 (see http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2017/059357.html ), regarding the proposal for new standard names for near surface tracer fields. The statement 'The surface called "surface" means the lower boundary of the atmosphere'

Re: [CF-metadata] Overstated restriction on references to external variables in version 1.7

Hi David, my point is indeed that you should be able to put anything in them, so have a standards document which says that you can't put references to external variables in them would be a mistake . cheers, Martin From: David Hassell

[CF-metadata] Overstated restriction on references to external variables in version 1.7

Hello All, Section 2.6.3, External Variables, of version 1.7 of the standard contains the statement that:"The only CF standard attribute which is allowed to refer to external variables is cell_measures." I believe this is stronger than intended: it should be possible, for instance, to refer

Re: [CF-metadata] Silicate vs. dissolved inorganic silicon

Dear Jim, thanks. I think that means that we need a corrections to the statements, from the CF Standard Name list, that: (1) '"Dissolved inorganic phosphorus" means phosphate ions in solution' in the CF Standard Name definition for

[CF-metadata] SIMIP: ridged_sea_ice area type

Hello Alison, just following up on some SIMIP issues. In an exchange last year Jonathan suggested that we introduce a ridged_sea_ice area type ( http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2016/058902.html ), instead of the new standard name ridged_sea_ice_thickness proposed by SIMIP.

[CF-metadata] Silicate vs. dissolved inorganic silicon

Hello Alison, others, the standard name list includes both (1) mole_concentration_of_dissolved_inorganic_silicon_in_sea_water and (2) mole_concentration_of_silicate_in_sea_water The definition of the first says that "dissolved inorganic silicon" means silicate ions in solution. Both have units

Re: [CF-metadata] Composite area types in CMIP6 data

Hello Karl, Jonathan, before writing this email, I had a look at a CMIP5 variable using a similar coordinate, the variable "treeFracSecEver". That variable was provided by one institution (MIROC). I mention that, because I feel we should be cautious about extendin the convention in ways which

Re: [CF-metadata] Composite area types in CMIP6 data

Hi David, Yes, "type" and "ftype" are conceptually independent. "pasture" refers to a land usage category and "C4" refers to a plant functional type which can occur in and land usage category. cheers, Martin From: David Hassell [david.hass...@ncas.ac.uk] Sent:

[CF-metadata] Composite area types in CMIP6 data

Hello, In CMIP6 we have a request for some data on pasture land with C4 functional type. We already have CF area types for pasture and c4 plants in general. We could construct the required information as follows: float pastureFracC4(time, lat, lon) ; pastureFracC4:coordinates =

[CF-metadata] New Standard Names: frequency_distribution_..... and fractional_X_over_Y

Dear List, There are two variables from the CMIP5 and 6 data request with standard names of the form "histogram_of_X_over_Z". Following some discussion on the thread "Usage of histogram_of_X_over_Z " which has clarified the

Re: [CF-metadata] Usage of histogram_of_X_over_Z

Dear Jonathan, thanks for that detailed overview. I accept your justification for having the the key physical quantity of interest in the standard name. In broad usage, I have the impression that a "histogram" can be expressed as either a count or a percentage, so we should be explicit in the

[CF-metadata] Metadata/standard names for variables involving thresholds (e.g. climate indices)

Dear Lars, see comments in line below: Martin --- Dear all, Before the summer I asked in separate emails a few questions related to standard names. Based on the responses I have worked on this a bit more and made some good progress, but there still are some open issues

[CF-metadata] Usage of histogram_of_X_over_Z

less there is a way of distinguishing between both cases with the use of attributes. Another detail is that these histograms provide relative frequencies (values between 0 and 1, not counts), not absolute frequencies. Is that inconsistent with the current definition of histogram in CF? Regards, Aleja

[CF-metadata] Missing data bins in histograms

Dear Jonathan, I'm sorry I didn't respond on the point about it being the first bin: I had not intended the special value to be restricted to the first bin, so I guess there is something ambiguous in my intial formulation which is giving this impression. I agree that we should formulate any

[CF-metadata] Usage of histogram_of_X_over_Z

Hello, There are two standard names of the form histogram_of_. in the CF Standard Name list (at version 36): histogram_of_backscattering_ratio_over_height_above_reference_ellipsoid and histogram_of_equivalent_reflectivity_factor_over_height_above_reference_ellipsoid. Both of these where

[CF-metadata] Missing data bins in histograms

Dear Karl, Jonathan, Jim, thanks for those comments. The CMIP6 variable in question is clmisr (http://clipc-services.ceda.ac.uk/dreq/u/59151ed6-9e49-11e5-803c-0d0b866b59f3.html) with a coordinatte of 16 altitude bins (http://clipc-services.ceda.ac.uk/dreq/u/dim:alt16.html ). I'd be happy

[CF-metadata] Missing data bins in histograms

Hello, the CF standard name list has two "histogram_ " entries, and in the CMIP6 data request we may need to add a third, a histogram_of_cloud_top_height. Besides the standard name, we also need, for this new variable, a method of encoding the "missing data" bin in the histogram. That is,

Re: [CF-metadata] CMIP6 Sea Ice MIP: Ice thickness

Dear Dirk, OK. For the snow thickness, do you want a weighted time mean? For example, if there is a 1m snow layer over 50% of a grid cell for half the month and 3m over 25% for the 2nd half of the month (the rest of the cell being snow free), do you want a weighted time mean of 1.6667m or a

[CF-metadata] CMIP6 Sea Ice MIP: Ice thickness

Dear Jonathan, Dirk, Alison, It looks as though you have resolved all the issues nicely, but I have one concern about Jonathan's suggestion for dealing with the thickness of ice floating in melt ponds on the surface of sea ice. The suggestion is to use the existing standard name

[CF-metadata] CMIP6 Sea Ice MIP: Integrated quantities

Dear Jonathon, Dirk, I agree with Jonathon that it is a good idea to follow the approach used in other names (e.g. number_of_days_with_air_temperature_above_threshold) and use a coordinate for the threshold value .. though I would prefer to make it obligatory to state the threshold in order to

Re: [CF-metadata] Recording requirements expressed in standard name definitions

Hello Roy, Thanks, in that case I agree completely. It will be an interesting challenge to come up with a suitable set of RDF predicates. I hope your optimism about reaching agreement on a place for the list in CF is justified, cheers, Martin From: Lowry, Roy

Re: [CF-metadata] Recording requirements expressed in standard name definitions

Hi Roy, I can see how that might work. However, I still think it would still be useful to have a clearly structured list as an intermediate step. After posting the email it occurred to me that it may be better to have such a list either as part of the conformance document or as an additional

Re: [CF-metadata] Recording requirements expressed in standard name definitions

Dear Roy, Having the constraints expressed in a machine readable way in the NVS sounds good in principle, but do you have a clear idea about how to make it work in practise? The constraints described in ticket 151 are quite complex, so I'm not sure how they would be expressed. e.g. Either:

[CF-metadata] Recording requirements expressed in standard name definitions

Dear All, in connection with ticket 151 (http://cf-trac.llnl.gov/trac/ticket/151) I had proposed a section in appendix B listing standard names whose definitions impose additional constraints on variable attributes etc. Jonathan convinced me that ticket 151 was not the right place for this.

[CF-metadata] Use of CF standard name region

Dear Jonathan, I can understand the argument that the concept of "region" is what you want in the standard name, and I'm happy to accept that. The problem that started this discussion remains, however. Namely, the current standard name definition for region includes a reference to the list of

[CF-metadata] weighted time mean vs. conditional time mean.

Dear Jonathan, yes, it is absolutely clear that "where" can only be used with area types. It is also clear, I thought, that some of these area types may vary with time: the area type list includes "fire" and "cloud", for example. 7.3.3 gives a template for the cell_methods element: dim1:

Re: [CF-metadata] weighted time mean vs. conditional time mean.

Hi David, that is true. My question was whether there should be, as Jonathan proposes, a restriction on the dimensions that "where type1" can be associated with, cheers, Martin From: David Hassell [david.hass...@ncas.ac.uk] Sent: 20 May 2016 13:03 To: Juckes,

[CF-metadata] Use of CF standard name region

Hello All, In CMIP5 the variable "basin" was used as a fixed spatial field with integer values and the CF Standard Name "region", which has the definition "A variable with the standard name of region contains strings which indicate geographical regions. These strings must be chosen from the

[CF-metadata] weighted time mean vs. conditional time mean.

Hello Jonathan, Jim, Just picking up the thread again. There is an issue, it appears, about the use of the "where" modifier for cell_methods elements other than "area:". Jonathan believes "where" should only apply for area on the basis that this where the motivation comes from in the first

[CF-metadata] Soil litter definitions

Dear All, I've been checking through the definitions of some of the land variables used in CMIP5 and the CMIP6 request, and there may be some ambiguity in the concept of "litter". Two terms (litter_carbon_flux, litter_carbon_content) have definitions which include the phrase '"Litter carbon"

[CF-metadata] weighted time mean vs. conditional time mean.

Hello, We have two similar but distinct temporal averaging use cases in the CMIP6 data request and I'd be grateful to some advise about CF encoding. (1) Grid cells have a temporally varying sea-ice fraction, and a mean is wanted over the sea-ice area. Is this a correct cell_methods

[CF-metadata] Confusing skin temperature and interface temperature

Hello All, I'm happy with Karl's suggestion: including "subskin" in the list is a clear improvement, cheers, Martin ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Negative emissions?

Dear Karl, Jonathan, I'm happy with that interpretation. There is a slight problem in the detail: standard name definitions containing the word "emission" often have the sentence '"Emission" means emission from a primary source located anywhere within the atmosphere, including at the lower

[CF-metadata] Negative emissions?

Hello All, The CMIP6 data request will, like the CMIP5 data request, include a request for a variable defined as "Carbon Mass Flux into Atmosphere Due to All Anthropogenic Emissions of CO2" with CF Standard Name

[CF-metadata] Confusing skin temperature and interface temperature

Hello All, Karl has raised an objection to the wording " not the skin " which was carried over from the current CF Standard Name definition for sea_surface_temperature in my suggested update. The update is intended to correct a currently erroneous reference to "surface_temperature" as

[CF-metadata] Confusing skin temperature and interface temperature

Hello All, The CF Standard Name sea_surface_temperature includes the statement that it is " not the skin temperature, whose standard name is surface_temperature". The last phrase here is incorrect: the standard name of the skin temperature is sea_surface_skin_temperature, not

Re: [CF-metadata] On scalar coordinate variables

Hi David, In case (1) "double dim1" is a an NUG scalar coordinate variable. My point is that the #104 text appears ambiguous to me, because it is using the term "scalar coordinate variable" in a way which is different from the NUG usage, but at the same time relies on reference to the NUG text

Re: [CF-metadata] On scalar coordinate variables

Hi David, Aren't there two cases here, one in which the scalar coordinate does have the same name as a dimension and one in which it doesn't? i.e. (1) scalar NUG coordinate variable Dimensions: dim1 = 1 ; variables: float myvar(dim1); double dim1; (2) Scalar CF coordinate variable

[CF-metadata] On scalar coordinate variables

Hello, The CF Convention 1.6 and draft 1.7 both include, in the discussion of dimensions in Section 2.4, the statement that: "It is also acceptable to use a scalar coordinate variable which eliminates the need for an associated size one dimension in the data variable." However, the convention

[CF-metadata] Weighted means and cell_methods in the CMIP6 data request

Hello All, There are a number of variables in the CMIP6 data request which are requested as weighted means, such as the age of snow as a time mean weighted by mass of snow. We also have area weighted means, as in the monthly mean temperature of sea-ice weighted by sea ice area. The latter can

Re: [CF-metadata] Specifying latitude and longitude of transects and regions (Karl Taylor)

Hello Karl, In your email of 17th July you ask the use case for providing the spatial coordinates of data. I was under the impression that this was an accepted objective: the proposal here was to close a gap whereby there is a small collection of CMIP5 and CMIP6 variables, namely those on

Re: [CF-metadata] Applying multiple conventions

Continuing thread: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2015/058036.html Hello All, I'd like to pick up this thread again. The min motivation of raising it was to get a change to the following line in the draft 1.7 conformance document (in section 2.6.1) 'Files that conform to

Re: [CF-metadata] Specifying latitude and longitude of transects and regions

Hello Mark, If the two end points can be specified with bounds within the existing convention, it might be simpler to use that. Can you explain to me how this is done? The only reference to bounds which I could find in the convention was in connection with cell boundaries. The flow direction

[CF-metadata] Specifying latitude and longitude of transects and regions

Hello All, There are some variables in the CMIP5 archive which lack explicit latitude and longitude information, such as mfo (standard name sea_water_transport_across_line) and msftzzzba (ocean_y_overturning_mass_streamfunction_due_to_bolus_advection). The first is a mass flux across a

[CF-metadata] Specifying latitude and longitude of transects and regions

Hi Jonathon, I'm afraid I don't have much to add -- the use case is to record endpoints so that people can find out what the endpoints are. The transects are requested by specification of the endpoints. I'm requesting this for the CMIP6 metadata. What would be the use case for more detailed

[CF-metadata] Conventions global attribute and the conventions playground

Hello All, I'm going through the draft NetCDF metadata convention for CMIP6, and would like to clean up the way the convention is declared in the NetCDF file. The way that Unidata advices users to do this is with an appropriate string in the Conventions global attribute, using a space or comma

Re: [CF-metadata] area_type: convention and usage: bringing the checker and convention into line

Hello Ros, If you have access to JASMIN, the file is at /badc/cmip5/data/cmip5/output1/MIROC/MIROC-ESM/historical/mon/land/Lmon/r1i1p1/latest/landCoverFrac/landCoverFrac_Lmon_MIROC-ESM_historical_r1i1p1_185001-200512.nc. Otherwise, select model=MIROC-ESM, experiment=historical and

[CF-metadata] area_type: convention and usage: bringing the checker and convention into line

Hello, I have a question about the specification of area_type in the CF Convention and its usage in CMIP5 -- motivated by the need to define how it might be used in CMIP6. The convention document appears clear: Some standard names (e.g. region and area_type) are used to indicate quantities

[CF-metadata] Applying multiple conventions

Hello, There is a proposal floating around to use the UGRID conventions for unstructured grids in CMIP6 data. One issue is that the CF Convention specifies a specific string for the Conventions and the UGRID convention specific a different specific string. Is there any chance of modifying CF

Re: [CF-metadata] Dealing with large numbers of flag values in netcdf cf -- what are words

Hello Jonathan, There does not appear to be any objection to the suggestion below. Does it need a formal proposal, or can it be put in as a minor clarification? Cheers, Martin -Original Message- From: Jonathan Gregory [mailto:jonat...@met.reading.ac.uk] On Behalf Of Jonathan Gregory

Re: [CF-metadata] Dealing with large numbers of flag values in netcdf cf -- what are words

Hello, Rosalyn has very quickly cleared up one problem I was having: I couldn't get the cf-checker to accept my string of 800 flag_meanings. The problem lies in the interpretation of Section 3.5 of the CF Conformance Requirements and Recommendations: The type of the flag_meanings

Re: [CF-metadata] Dealing with large numbers of flag values in netcdf cf -- what are words

Hello Jonathan, That sounds fine to me. Concerning non-ascii -- you may be right. Cheers, Martin -Original Message- From: Jonathan Gregory [mailto:jonat...@met.reading.ac.uk] On Behalf Of Jonathan Gregory Sent: 28 October 2009 15:14 To: Juckes, Martin (STFC,RAL,SSTD) Cc:

Re: [CF-metadata] Dealing with large numbers of flag values innetcdf cf

Thanks for the responses. Seth is right, I was looking for an alternative to having a gigantic flag_meanings attribute. I have tried Seth's approach, but can’t get it past the cf-checker. There appears to be a character set restriction: I can get the first 547 flag_meaning strings accepted

Re: [CF-metadata] Dealing with large numbers of flag valuesinnetcdf cf

Hello Roy, That is an interesting idea. There are definitions of these areas on a WWF site, of the form http://www.worldwildlife.org/wildworld/profiles/terrestrial/nt/nt0908_full.html where nt0908 is a tag associated with a particular flag value. My first thought was: URI=

Re: [CF-metadata] Dealing with large numbers of flag valuesinnetcdf cf

Hello Ed, To Roy's comment I'll add that I would like to complement in-file metadata with additional online info, not replace it. E.g. for the tag NT0908 I have a name Paraná flooded savanna which can go in the file, but there is a web page giving the full characterisation of what is meant by

[CF-metadata] Dealing with large numbers of flag values in netcdf cf

Hello, I wonder if anyone can help with this problem: I have a file with a map of index values, ranging from 1 to 827. The flag meanings range from Admiralty Islands lowland rain forests to Zambezian halophytics. I'm reluctant to combine all 827 flag meanings into a single string for the