<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Tim, John,<div><br></div><div>NCAR has been using a structure similar to option 2 for TIGGE based NetCDF files that is not</div><div>technically CF compliant, but was reviewed by colleagues at ECMWF, UK MetOffice, and BADC </div><div>(Dec 10, 2007, ECMWF workshop) and deemed acceptable. The structure is designed to handle multiple</div><div>ensemble forecast systems, and multiple init times with varying forecast periods. </div><div><br></div><div><br></div><div><div>i.e. </div><div><br></div><div><div> int reftime(reftime) ;</div><div> reftime:data_type = "int" ;</div><div> reftime:units = "hours since 1950-01-01 00:00:00" ;</div><div> reftime:standard_name = "forecast_reference_time" ;</div><div> reftime:long_name = "Time of model initialization" ;</div><div> int leadtime(reftime) ;</div><div> leadtime:data_type = "int" ;</div><div> leadtime:units = "hours" ;</div><div> leadtime:standard_name = "forecast_period" ;</div><div> leadtime:long_name = "Hours since forecast_reference_time" ;</div></div></div><div><br></div><div>The structure was based on </div><div>the proposal by <span class="Apple-style-span" style="font-family: arial; font-size: 13px; "><em style="font-weight: bold; font-style: normal; text-decoration: inherit; ">Francisco</em> J. Doblas-<em style="font-weight: bold; font-style: normal; text-decoration: inherit; ">Reyes </em><em style="font-style: normal; text-decoration: inherit; ">for the "Ensembles" project. A thread related to this proposal </em></span></div><div><font class="Apple-style-span" face="arial" size="3"><span class="Apple-style-span" style="font-size: 13px;">can be found at:</span></font></div><div><font class="Apple-style-span" face="arial" size="3"><span class="Apple-style-span" style="font-size: 13px;"><br></span></font></div><div><font class="Apple-style-span" face="arial" size="3"><span class="Apple-style-span" style="font-size: 13px;"><a href="http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2007/001470.html">http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2007/001470.html</a></span></font></div><div><div><br></div><div>A sample file is available for download at:</div><div><br></div><div><a href="http://dss.ucar.edu/download/doug/data.nc">http://dss.ucar.edu/download/doug/data.nc</a></div><div><br></div><div>The metadata "CDL" dump of the file can be accessed at:</div><div><br></div><div><a href="http://dss.ucar.edu/download/doug/data.dump">http://dss.ucar.edu/download/doug/data.dump</a></div><div><br></div><div>Doug</div><div><br></div><div><br></div><div><div>On Jan 7, 2009, at 7:19 PM, Timothy Hume wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi John,<br><br>This seems a reasonable proposal to me. Often when storing NWP forecasts option (2) will suffice. Most centres will always include the same forecast lead times each time new NWP model data are disseminated (for example some centres will send out +6, +12, +18, +24, +36, +42, +48, +60 and +72 hour forecasts for two model runs per day, ever day). Data users will then often want to extract particular forecast lead times (e.g. +48 hours). Option (2) makes this a trivial task.<br><br>On the other hand option (1) is also useful, even when the time offsets are fixed. For example, one can construct an auxilliary coordinate variable called valid_time which is two dimensional. This aids in the cases when the user wants to extract all forecasts which are valid at a particular time. In fact, using both options (1) and (2) often yields the most useful files.<br><br>Tim.<br><br><br>-----Original Message-----<br>From: John Caron [<a href="mailto:caron@unidata.ucar.edu">mailto:caron@unidata.ucar.edu</a>] <br>Sent: Thursday, 8 January 2009 12:56<br>To: Karl Taylor<br>Cc: Timothy Hume; <a href="mailto:cf-metadata@cgd.ucar.edu">cf-metadata@cgd.ucar.edu</a><br>Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED]<br><br>Hi Karl, Tim:<br><br>I think the original wording doesnt fully anticipate multiple datetime coordinates:<br><br>Section 4.4:<br>" A time coordinate is identifiable from its units string alone. The Udunits routines utScan() and utIsTime() can be used to make this determination. Optionally, the time coordinate may be indicated additionally by providing the standard_name attribute with an appropriate value, and/or the axis attribute with the value T. "<br><br>In Tim's example, his "forecast/valid time" is actually an offset from the base time, in units of time, not a udunit datetime. This allows it to be a 1D coordinate variable. But in the general case, if the forecast time spacing depends on the basetime, it must be 2D. We see this a lot in NCEP model output.<br><br>In general, when storing multiple forecast model runs in the same file there are two options:<br><br>1. A 1D "basetime/runtime" coordinate variable identified by standard name "forecast_reference_time" which holds udunit datetimes, and a 2D "forecast/valid time" auxiliary coordinate variable with standard name "time" which also holds udunit datetimes. It must be dimensioned by the runtime and the time dimensions. Data variables will need to use the "coordinates" attribute to reference the time auxiliary coordinate, as usual.<br><br>2. A 1D "basetime/runtime" coordinate variable identified by standard name "forecast_reference_time" which holds udunit dates, and a 1D or 2D "forecast offset time" auxiliary coordinate variable identified by standard name "forecast_period" which holds a udunit time unit (eg hours), which is added to the basetime to get the forecast datetime. If 1D, it will be dimensioned by time, if 2d it will be dimensioned by runtime and time, and must be referenced by the "coordinates" attribute<br><br>As an aside, the utIsTime() function is ambiguous as to whether we have a time unit or a datetime unit (which udunits calls "having an offset"). I think we need to carefully distinguish time and datetime, and specify where each is allowed.<br><br>If this seems reasonable, I can write up a proposal.<br><br><br>Karl Taylor wrote:<br><blockquote type="cite">Hi Tim,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Section 4.4 (just before section 4.1) states "The methods of identifying<br></blockquote><blockquote type="cite">coordinate types described in this section apply both to coordinate<br></blockquote><blockquote type="cite">variables and to auxiliary coordinate variables named by the coordinates<br></blockquote><blockquote type="cite">attribute." Since the axis attribute is one of the methods used to<br></blockquote><blockquote type="cite">identify a vertical coordinate, it would seem to be allowed for the<br></blockquote><blockquote type="cite">level in your file.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On the other hand, in the 4th paragraph of section 5.7, it says that<br></blockquote><blockquote type="cite">"The axis attribute is not allowed for auxiliary coordinate variables".<br></blockquote><blockquote type="cite"> This seems to contradict the earlier statement.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We need to revise the document to be internally consistent. Does anyone<br></blockquote><blockquote type="cite">recall why we would want to prohibit the use of the axis attribute for<br></blockquote><blockquote type="cite">auxiliary coordinate variables?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">cheers,<br></blockquote><blockquote type="cite">Karl<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Timothy Hume wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Hi Karl,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I have just checked one of my files, and get two errors:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The first error is:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Checking variable: forecast<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ERROR (4.4): Invalid units and/or reference time<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This is the error I am aware of. My file should become compliant if I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">switch the "T" axis to basetime.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The second error is:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Checking variable: level<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ERROR (4): Axis attribute is not allowed for auxillary coordinate<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">variables.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I was unaware that the axis attribute should not be used for scalar<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">coordinate variables (as describe in Section 5.7). Is this intended?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In any case, I don't think this small error should cause the NetCDF<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">viewers I tried (IDV and Joe Sirott's web application) to not work.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cheers,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Tim.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-----Original Message-----<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: Karl Taylor [<a href="mailto:taylor13@llnl.gov">mailto:taylor13@llnl.gov</a>] Sent: Thursday, 8 January<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2009 11:03<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To: Timothy Hume<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cc: <a href="mailto:cf-metadata@cgd.ucar.edu">cf-metadata@cgd.ucar.edu</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- CF file [SEC=UNCLASSIFIED]<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Hi Tim,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Other than the axis attribute for time, I didn't see any issues. You<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">might run the CF compliance checker on the file (http://<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cf-pcmdi.llnl.gov/conformance), but it might not run if the other<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">utilities stumbled. Maybe someone else has some ideas.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cheers,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Karl<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Timothy Hume wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I am writing NetCDF files which hold surface fields (2m temperature<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">etc) from multiple NWP model runs (all the runs from the same model<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">for the last month or so). The files are for operational use, so I<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">want them to strictly follow the CF conventions. I am running into a<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">couple of problems, where the conventions don't seem to be ideally<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">suited for storing more than a single model run.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Here is what I do:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I have four dimensions and associated coordinate variables:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">basetime: The base time for the model run (units: seconds since<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">1970-01-01 00:00:00.0 +0:00)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">forecast: The forecast lead time, relative to the basetime (units:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">hours)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">latitude<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">longitude<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">There is no need for a vertical dimension, because I am using surface<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">fields. Never-the-less I make use of a scalar vertical coordinate<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">variable as described in Section 5.7 of the CF-1.3 metadata<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">conventions document.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The use of two dimensions to store the time information (basetime and<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">forecast) seems to be a natural way to store multiple NWP model runs,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and is the standard way used in the very old NUWG conventions. As far<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">as I can tell, what I am doing is supported by the CF conventions,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">provided the time axis is taken to be the basetime dimension. This is<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">because Section 4.4 of the conventions specifies the units of the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">time coordinate must include a reference time. Obviously the units of<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the forecast coordinate cannot include a reference time, because the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">reference time varies, and is determined by the value of the basetime<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">coordinate.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The difficulty I am encountering is that some applications which read<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">web based NetCDF data viewer) seem to choke on my data. I suspect<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">(but am not 100% certain in the case of the IDV) that the reason is<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">because of the way I handle the time information in my files.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">To illustrate in more detail what my files look like, I am attaching<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the CDL from an example file. The CDL is non-CF compliant, because I<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">have specified the "T" axis (via the axis variable attribute) to be<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the forecast coordinate, and the forecast coordinate has invalid<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">units (no reference time). I am planning on switching the "T" axis to<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the base time coordinate, which as far as I can determine should make<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the file CF compliant.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">My question is: is there a better (or more standard) way of storing<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">multiple NWP model runs in a single file than what I am doing?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Cheers,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Tim Hume<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Centre for Australian Weather and Climate Research<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Australian Bureau of Meteorology<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Melbourne<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Australia<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">--- Example CDL follows ---<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">netcdf gasp_1p0deg_ocf_t2m_rtdb_opn {<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">dimensions:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> forecast = 69 ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> basetime = UNLIMITED ; // (100 currently)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude = 96 ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude = 121 ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> bounds = 2 ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">variables:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> double forecast(forecast) ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> forecast:long_name = "Time of model forecast, relative to the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">basetime" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> forecast:units = "hours" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> forecast:standard_name = "forecast_period" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> forecast:axis = "T" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> forecast:bounds = "forecast_bounds" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> double forecast_bounds(forecast, bounds) ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> forecast_bounds:long_name = "forecast interval" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> forecast_bounds:units = "hours" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> int basetime(basetime) ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> basetime:long_name = "Model basetime" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> basetime:calendar = "gregorian" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> basetime:standard_name = "forecast_reference_time" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> double latitude(latitude) ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude:long_name = "latitude" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude:units = "degrees_north" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude:bounds = "latitude_bounds" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude:valid_min = -90. ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude:valid_max = 90. ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude:standard_name = "latitude" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude:axis = "Y" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> double latitude_bounds(latitude, bounds) ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude_bounds:long_name = "grid cell latitude boundaries" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude_bounds:units = "degrees_north" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude_bounds:valid_min = -90. ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> latitude_bounds:valid_max = 90. ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> double longitude(longitude) ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude:long_name = "longitude" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude:units = "degrees_east" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude:bounds = "longitude_bounds" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude:valid_min = -360. ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude:valid_max = 360. ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude:standard_name = "longitude" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude:axis = "X" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> double longitude_bounds(longitude, bounds) ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude_bounds:long_name = "grid cell longitude boundaries" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude_bounds:units = "degrees_east" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude_bounds:valid_min = -360. ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> longitude_bounds:valid_max = 360. ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> float temperature_2m(basetime, forecast, latitude, longitude) ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> temperature_2m:long_name = "Air temperature 2m above the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">surface" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> temperature_2m:units = "K" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> temperature_2m:_FillValue = 9.96921e+36f ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> temperature_2m:missing_value = 9.96921e+36f ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> temperature_2m:valid_min = 180.f ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> temperature_2m:valid_max = 330.f ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> temperature_2m:standard_name = "air_temperature" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> temperature_2m:cell_methods = "lat: lon: mean (area weighted)" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> temperature_2m:coordinates = "level" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> double level ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> level:long_name = "Height above the surface" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> level:units = "m" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> level:positive = "up" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> level:standard_name = "height" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> level:axis = "Z" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">// global attributes:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> :Conventions = "CF-1.3" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> :history = "File created by the Gridded OCF data ingest<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">system" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> :institution = "Australian Bureau of Meteorology" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> :source = "model" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> :title = "GASP forecasts of temperature_2m; resolution: 1.0<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">degree; source: rtdb" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> :topography = "MSAS" ;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">}<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">CF-metadata mailing list<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">http:// mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">CF-metadata mailing list<br></blockquote><blockquote type="cite"><a href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a><br></blockquote><blockquote type="cite"><a href="http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata">http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata</a><br></blockquote>_______________________________________________<br>CF-metadata mailing list<br><a href="mailto:CF-metadata@cgd.ucar.edu">CF-metadata@cgd.ucar.edu</a><br>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata<br></div></blockquote></div><br></div></body></html>