Hi Tor:
Finally looking closely at this problem. One question I have is the "run
time", in your case its taken from the filename, eg
sediment_thickness_1503081251.nc -> runTime="2015-03-08T12:51:00Z"
What we mean by "runtime" is not the clock time when the run was made, but
the starting point of the simulation. Just wondering if thats the case here.
I have a fix for the problem youve reported, its due to that strange 51
minute offset, plus a bug that was doing strict floating point compare
instead of allowing for some roundoff,
The fix will be in the 4.6.0 release soon.
thanks,
John
On Mon, Dec 15, 2014 at 8:31 AM, Tor Nordam <Tor.Nordam@xxxxxxxxx> wrote:
> 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>
>
>
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
