Hi,
I'm trying to set up a Forecast Model Run Collection using THREDDS. I have a
collection of netCDF files, where the time at which the simulation was run is
part of the filename:
forecast_yyMMddHHmm.nc
In the files, the time variable is an integer, and gives time as number of
hours since a given date. This date is the same in all my files. Since the
times are given in integer hours, there should be absolutely no uncertainty as
to whether two timesteps are the same.
However, when the THREDDS server presents this as an FMRC using the "best"
model (for a given timpstep, it always serves data from the most recently
performed simulation), it converts the time variable to a double, and somehow
manages to present some timesteps which are actually the same as slightly
different. For example, all of these are actually the same in my data, yet are
presented as three different timesteps:
-65.10000033333334, -65.10000033333333, -65.1
The reason that the numbers are not whole hours is that the server also changes
the reference point for the time axis from that specified in my files, to the
simulation run time of the first file. This is fair enough, if only the data
would be presented correctly.
Interestingly, if I restart the thredds server, it manages to read and
correctly present the files that are there at the time of restart, but later
on, if it does a rescan triggered by the cron expression in the xml file, it
doesn't get the timesteps right.
Any suggestions as to what I'm doing wrong?
The dataset definition in the xml-file looks like this:
<dataset name="FMRC Example">
<featureCollection name="BOM" featureType="FMRC" harvest="true" path="BOM">
<metadata inherited="true">
<serviceName>fmrcServices</serviceName>
<dataFormat>netCDF</dataFormat>
<documentation type="summary">Example BOM</documentation>
</metadata>
<collection spec="/system/data/forecast_#yyMMddHHmm#.*\.nc$"/>
<update startup="test" rescan="0 0/10 * * * ? *" trigger="allow"/>
<fmrcConfig regularize="false" datasetTypes="Best"/>
</featureCollection>
</dataset>
Thanks,
Tor
