Re: [CF-metadata] More background on the burned area (Jonathan Gregory)
Jonathan, Kevin, I don't think that it is necessary to further qualify burned_area. If you do an internet search for this term you always come up with hits related to wildfire which would suggest that there is little ambiguity in this term. I propose to add the vegetation fire relationship in the definition of the term but keep the term short and concise. Should there ever be a conflict we can still create an alias or re-define. (Just imagine you start arguing about air_temperature: is this the temperature of air inside a box or a house? ...) Cheers, Martin Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] new TEOS-10 standard names
To follow on from Trevor's comments, most CMIP3-grade ocean models were initialised, at least in their pre-coupled ocean state from a variant of the World Ocean Atlas (WOA). Listed on the CMIP3 Climate Model Documentation, References, and Links webpages (http://www-pcmdi.llnl.gov/ipcc/model_documentation/ipcc_model_documentation.php) these suggest that initialisation fields were sourced mostly from: LEV82: Levitus (1982); LEV94: Levitus et al., (1994), Levitus and Boyer (1994); LEV98: Conkright et al.,(1999); LEV: unspecified Levitus database Just selecting one model from the ~24 or so which comprise the CMIP3 suite, CNRM-CM3, under section 5 - Simulation Details indicates: Picntrl/Run_1: This preindustrial control simulation was initialized from a coupled simulation of a previous version of CNRM coupled model initialized an ocean at rest with temperature and salinity profiles specified from Levitus (1982) climatology, integrated for 30 years with a relaxation of surface temperature to the monthly mean Reynolds climatology for 1950. Subsequent runs are often then initialised from a previously completed spinup.. So I think it is fair to say that most model fields are then a modelled version of practical salinity.. Cheers, P From: McDougall, Trevor (CMAR, Hobart) Sent: Wednesday, 27 July 2011 6:27 AM To: Jonathan Gregory Cc: ngalbra...@whoi.edu; CF-metadata@cgd.ucar.edu; Durack, Paul (CMAR, Hobart); Barker, Paul (CMAR, Hobart); rainer.feis...@io-warnemuende.de; r...@eos.ubc.ca; b...@noc.soton.ac.uk; stephen.griff...@noaa.gov Subject: RE: [CF-metadata] new TEOS-10 standard names A couple of quick comments following on from Jonathan's post. (1) I know of at least 6 pre-TEOS-10 expressions for density used in models, with authors like Fofonoff Millard, Cox, Wright, Jackett McDougall, McDougall et al. Jackett et al. and they are all written in terms of Practical Salinity. I know of none used in ocean models that use any other type of salinity (until TEOS-10 has come along). So we can safely say that ocean and climate models have had their sea water equations of state written in terms of Practical Salinity. (2) The fact that a model variable drifts should not be a reason to use a different name for that variable. For example, we do not change the name potential temperature to something else just because model temperatures are not perfect and they drift. Trevor -Original Message- From: Jonathan Gregory [mailto:j.m.greg...@reading.ac.uk] Sent: Wednesday, 27 July 2011 1:45 AM To: McDougall, Trevor (CMAR, Hobart) Cc: ngalbra...@whoi.edu; CF-metadata@cgd.ucar.edu; Durack, Paul (CMAR, Hobart); Barker, Paul (CMAR, Hobart); rainer.feis...@io-warnemuende.de; r...@eos.ubc.ca; b...@noc.soton.ac.uk; stephen.griff...@noaa.gov Subject: Re: [CF-metadata] new TEOS-10 standard names Dear all I understand the need to be clear, with new standard names, which observational quantity is being collected in future. I do not agree, however, that we should make the plain salinity name an alias for something more precise. This is partly because that might change the meaning of existing data, possibly incorrectly as Trevor points out. Partly it is also because I think it is quite possible that models, perhaps idealised, may be used in which it would not be meaningful to be more precise than just salinity. Trevor argues that existing ocean models use practical salinity because (a) they are initialised with observations of that and (b) they assume so in their equation of state. I don't think (a) is necessarily so. In some cases, they might not be initialised with observations, for instance in idealised investigations of spin-up. Even when initialised from obs, they will almost certainly drift to a less realistic state. I don't know enough about it to be sure about (b). Unless we could be certain this is always the case, I think plain salinity should be retained for possible use in models. However, we could certainly recommend that models should use one of the new more precise terms if definitely appropriate. This recommendation could be included in the standard_name definition of plain salinity. I understand the existing standard name sea_water_temperature to mean in-situ temperature, as it does for air temperature. This could be stated in the definition. The purpose of standard names themselves is not to prescribe or recommend what quantities people should store in netCDF files. It is to allow them to describe with sufficient precision the quantities they have chosen to store, in order to make it possible to decide which quantities from different datasets should be regarded as comparable. Standard names are all in lower case, regardless of what case is used in ordinary writing. This is for simplicity in matching strings. Case-sensitive matching would inevitably trip people up and cause a
Re: [CF-metadata] the need to store lat/lon coordinates in a CF metadata compliant netCDF file
Without the grid_mapping, the lat and lon still make sense in the common case (and original CF case) of GCM data, and in many other cases, the intended usage of the data does not require precision about the figure of the Earth. Although this metadata could be valuable if it can be defined, I think it would be too onerous to require it. I hope to present on this very issue at AGU. The problem we see with ambiguous definition of datums is a cascade of non-recognition of datums through processing algorithms and in the output of some processes that generate very detailed data. The prime example is downscaled climate data. Because the climate modelers involved generally consider lat/lon to be a lowest common denominator, the datum used to geolocate historical data (like rain gages) is neglected. What results is, in our case, a 1/8deg (12km) grid with no datum. This is unacceptable. As at this resolution, the errors in a wrong assumption of datum for the grid can cause very substantial (a full grid cell or more) geolocation errors. If the CF community intends to consume any ground based data, then datums must be preserved from ingest of ground based forcing throughout data storage and processing. This is fundamental information that is required for ALL data comparison operations. I would argue that CF compliance should require this information. This puts the requirement to make metadata assumptions on data publishers/producers rather than data consumers. It is unacceptable to have different data consumers making different assumptions of geolocation on the same data. Off soapbox. Dave Blodgett Center for Integrated Data Analytics (CIDA) USGS WI Water Science Center 8505 Research Way Middleton WI 53562 608-821-3899 | 608-628-5855 (cell) http://cida.usgs.gov On Jul 26, 2011, at 5:24 AM, Jonathan Gregory wrote: Dear all For datasets which are intended for analysis by end-users I think it would be undesirable to remove the requirement of providing explicit lat and lon coords even if a grid_mapping is provided. I think it is unrealistic to expect all software which someone might use to analyse netCDF files to be able to recognise and act upon all possible values of the CF grid_mapping attribute, and without the lat and lon information the user would have a problem. If the issue is storage space in the file I think the much better choice is to store the explicit coordinates in another file, by extending the CF convention to allow datasets to be distributed over several linked files, as gridspec does for example. Steve appears to suggest that grid_mapping is required in some circumstances, but I don't think it is at present. However, the text Steve quotes may not be quite right: /When the coordinate variables for a horizontal grid are not longitude and latitude,*_it is required that the true latitude and longitude coordinates be supplied_* via the coordinates attribute/. The text should make it clear that this requirement applies when the data has a geolocated horizontal grid. It doesn't necessarily apply to idealised cases. We could clarify this with a defect ticket. Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] the need to store lat/lon coordinates in a CF metadata compliant netCDF file
Jonathan and Karl, I don't disagree with the GCM examples or lack of model resolution being talked about here, I just don't think that is the only argument. There are cases, like downscaled climate projections, reanalysis products, or radar indicated rainfall, where a datum is critical to interpreting the data accurately. My concern is that the justified disregard for datums at course resolution (and lack of requirement for it in the spec) fosters a lack of awareness that datums become critically important at finer scales. Jonathan, you have a point that an analyst should be free to make their own assumptions. However, I would prefer that they know they are making assumptions. It would be helpful if the CF specification paid some tribute to this issue rather than treating lat/lon coordinates as base-equivalent coordinates. Are there any arguments against CF recommending a standard datum assumption when intersecting data without a datum specified with data that does have a datum specified? Cheers, Dave On Jul 27, 2011, at 12:14 PM, Karl Taylor wrote: Hi all, (I think the horse still shows a few signs of life) what I'm arguing is that if the results the scientists are using come from a GCM, then although the two scientists got differences, those differences (no matter how large) should not be considered significant in terms of their reliability (as opposed to in some statistical sense). Just as one wouldn't rely on a climate model to predict global mean temperature to within 0.001 K (and surely it would be silly and perhaps misleading to report temperatures to this precision) one shouldn't expect to pin down the *location* of the grid cell temperature reported by a GCM to a point given with higher precision than the spacing of the grid cells (at least when comparing with observations). I will grant you that at some time far in the future, it is possible our models' resolution and accuracy will have improved to the point that we might have to alter the precision with which we report the locations of their output values, but we're not there yet. Best regards, Karl On 7/27/11 9:23 AM, David Blodgett wrote: Not to beat a dead horse, but this issue has been a huge stumbling block in our work to integrate data and software across the climate and geographic communities. The argument here is: Since CF data is usually so coarse and low precision complete geolocation metadata should not be required. An example of why this matters: Two scientists take the same downscaled climate data that doesn't have a datum specification and import it into their application. One application assumes one datum, the other assumes another datum. Scientist 1's results differ from scientist 2's results. In situations where their are steep gradients in downscaled data, these differences may be substantial. One solution would be to adopt a default datum for data lacking datum definition. So, given a file that uses lat/lon and claims to follow CF spec, a scientist could follow the specs guidance on what datum to assume. Without this type guidance or a requirement to include the information, lat/lon without a datum amounts to providing any other value without units. Dave On Jul 27, 2011, at 10:59 AM, Karl Taylor wrote: Dear all, another view: Can't remember *all* the issues here, but certainly reporting the latitude and longitude points for GCM grids without further precision (e.g., information on the figure of the Earth) is sufficient for any comparison with observations. Only certain (usually prescribed) conditions at the earth's surface (e.g., surface height) coming from a GCM should be trusted at the individual grid point scale, and no sub-grid scale information is directly available from the GCM (normally). So, even if a station data is near the boundary of a GCM's grid-cell, it should hardly matter which of the grid cells it straddles you compare it to. The GCM sort of gives you a grid cell average value that applies to some region in the vicinity of the cell. So, it doesn't matter where you think it is precisely located. Down-scaled output from the GCM will be at higher resolution, but again since the original data doesn't apply at a point but for a general region (usually quite a bit larger than 12 km, and even if it weren't we wouldn't believe stuff going on at that scale), so where the cell is exactly located again doesn't matter. best regards, Karl On 7/27/11 4:38 AM, David Blodgett wrote: Without the grid_mapping, the lat and lon still make sense in the common case (and original CF case) of GCM data, and in many other cases, the intended usage of the data does not require precision about the figure of the Earth. Although this metadata could be valuable if it can be defined, I think it would be too onerous to require it. I hope to present on this very
