[thredds] Problem with time run choice in best time series (fmrc aggregation) when the files contains hindcasts/analysis times

• To: THREDDS community <thredds@xxxxxxxxxxxxxxxx>
• Subject: [thredds] Problem with time run choice in best time series (fmrc aggregation) when the files contains hindcasts/analysis times
• From: Kristian Sebastián <ksebastian@xxxxxxxx>
• Date: Wed, 24 Sep 2014 14:44:18 +0200

Hi,

We think that we have found a problem with the time_run variable values in
the "Best Time Series" aggregation, when the files of the aggregation
contains hindcasts/analysis times.


Now, I am going to explain the problem with one of our model runs, named
wmopv2 (a roms application). The name of the file (roms_wmopv2_20120402)
contains the time when the run was done. Each run contains 1 day of
analysis data (from -1 day to the time run) and 3 days of forecast. Below
there is an opendap link to one this files, it is our first run of the
wmpov2 model (the ocen_time variable is the time):

http://thredds.socib.es/thredds/dodsC/operational_models/oceanographical/hydrodynamics/model_run_aggregation/wmopv2/files/2012/04/roms_wmopv2_20120402.nc.html

We have configured the frmc aggregation (long time ago) for this model.
Now, we have found that the time_run variable doesn't contain the expected
values. The documentation (as far as I know) points that, the "Best Time
Series" gets the time_run values from the file name with the Date Extractor
(also is needed to sort the collection files). But the time_run values of
our aggregation are the first time of the variable time (ocean_time in our
model). So, the first time_run values are the dates 2012/04/01 (the first
analysis time), which should be 2012/04/02. Below, you can find the opendap
link and the definition and ascii output (only the first times) of the time
variables.

The opendap link of the aggregation is:
http://thredds.socib.es/thredds/dodsC/operational_models/oceanographical/hydrodynamics/model_run_aggregation/wmopv2/wmopv2_best.ncd.html

The time variable is defined as:

long_name: Forecast time for ForecastModelRunCollection
standard_name: time
units: hours since 2012-04-02T00:00:00Z
missing_value: NaN
_CoordinateAxisType: Time

And the time_run variable:

long_name: run times for coordinate = time
standard_name: forecast_reference_time
units: hours since 2012-04-02T00:00:00Z
missing_value: NaN
_CoordinateAxisType: RunTime

Ascii output:


time[33]

-24.0, -21.0, -18.0, -15.0, -12.0, -9.0, -6.0, -3.0, 0.0, 3.0, 6.0, 9.0,
12.0, 15.0, 18.0, 21.0, 24.0, 27.0, 30.0, 33.0, 36.0, 39.0, 42.0, 45.0,
48.0, 51.0, 54.0, 57.0, 60.0, 63.0, 66.0, 69.0, 72.0

time_run[33]

-24.0, -24.0, -24.0, -24.0, -24.0, -24.0, -24.0, -24.0, 0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0, 24.0, 24.0, 24.0, 24.0, 24.0, 24.0, 24.0, 24.0, 24.0,
24.0, 24.0, 24.0, 24.0, 24.0, 24.0, 24.0, 24.0


Maybe is not a problem (if yes, it isn't critical), it is the way the "Best
Time Series" works but the time_run values could be misleading.

Best regards,
Kristian


-- 

Kristian Sebastian Blalid
SOS Division: Data Center Technical
Tel: 971439860 - Fax: 971439979
E-mail: kristian.sebastian@xxxxxxxx