Add the following NOS models to the data catalog:

[cpaternostro]

1. SJROFS
2. NGOFS2
3. LEOFS
4. LOOFS
5. LSOFS
6. SFBOFS

[jamesdoyle21]

@patrick-tripp

[mpiannucci]

To Flesh this out.... they currently are mis configured in thredds and therefore the catalog doesnt have their data and then oceansmap and its data catalog will not work because they do not show in ncwms.

Once their thredds config is fixed they should be able to be added back into oceansmap

[jamesdoyle21]

ngofs2 appears to be working fine. The others worked fine with TDS 5.0 beta version we were using. There is an issue with the time axis on at least some of those that TDS or ncWMS2 is complaining about.

-from Patrick

[mpiannucci]

I added NGOFS2 to OTT catalog today so hopefully it will be up tomorrow

[mpiannucci]

Tracking missing NOS models:

• [ ] SJROFS
• [x] NGOFS2
• [x] NYOFS
• [x] LEOFS
• [x] LOOFS
• [x] LSOFS
• [x] SFBOFS

[mpiannucci]

For SFBOFS... There error shows as such:

Which is saying that the time axis does not increase monotonically. But if we query the time variable from THREDDS it does indeed look correct:

https://eds.ioos.us/thredds/dodsC/ioos/ofs/sfbofs/forecast/regulargrid/SFBOFS_Forecast_Regulargrid_best.ncd.ascii?time%5B0:1:1366%5D

Ok, So then looking at the time_run variable and these are not monotomic:

https://eds.ioos.us/thredds/dodsC/ioos/ofs/sfbofs/forecast/regulargrid/SFBOFS_Forecast_Regulargrid_best.ncd.ascii?time_run%5B0:1:1366%5D

Which is expected because this is an FMRC. and the best timestep may vary by model run. OK so do the other RG files just work? Lets check CBOFS:

https://eds.ioos.us/thredds/dodsC/ioos/ofs/sfbofs/forecast/regulargrid/SFBOFS_Forecast_Regulargrid_best.ncd.ascii?time_run%5B0:1:1366%5D

That looks monotomic:

So either some of the timesteps for SFBOFS are missing data but NCWMS cant handle that (even though it definitely should), or there is a configuration gap between how CBOFS is configured in thredds and how sfbofs is. CC @patrick-tripp

[mpiannucci]

I noticed that the CBOFS thredds config declares <dimension name="time" orgName="ocean_time"/> but SFBOFS doesnt. But then I checked and DBOFS doesnt declare it either and that works fine so im not sure that matters at all

[mpiannucci]

Success. @patrick-tripp was able to nail down the fix tonight and the other models will be filtering in soon as the fix is applied and data-catalog for OceansMap is updated to match.

[patrick-tripp]

The fix is only working intermittently. I will continue to investigate.

[patrick-tripp]

FYI: time_run and time_offset are axis created by THREDDS when computing the Best timeseries.

[mpiannucci]

@cpaternostro Is it possible to get NYOFS to be published with regulargrid data like CBOFS and DBOFS etc (including the zetatomllw field)? If not its no big deal, but it wont be consistent with the other models we have

[mpiannucci]

Update data catalog for a bunch of these, hoping to see more rendering correctly tomorow

[mpiannucci]

Ok! So all of these now show up in the UI, but the Fields ones have messed up time ranges and so they do not render because data-catalog is confused by them:

data-catalog-dev    | 2022-06-16 14:51:11,902 - 1 - data_catalog - models:161 - ERROR - Failed to load WMS Layer - NYOFS/u:v-group
data-catalog-dev    | Traceback (most recent call last):
data-catalog-dev    |   File "/usr/share/data-catalog/data_catalog/generic/models.py", line 144, in from_wms
data-catalog-dev    |     start_time, end_time, timestamps = self.get_times(wms_service, layer)
data-catalog-dev    |   File "/usr/share/data-catalog/data_catalog/generic/ncwms2.py", line 249, in get_times
data-catalog-dev    |     date = dateparse(d)
data-catalog-dev    |   File "/usr/local/lib/python3.6/site-packages/dateutil/parser/_parser.py", line 1358, in parse
data-catalog-dev    |     return DEFAULTPARSER.parse(timestr, **kwargs)
data-catalog-dev    |   File "/usr/local/lib/python3.6/site-packages/dateutil/parser/_parser.py", line 654, in parse
data-catalog-dev    |     ret = self._build_naive(res, default)
data-catalog-dev    |   File "/usr/local/lib/python3.6/site-packages/dateutil/parser/_parser.py", line 1229, in _build_naive
data-catalog-dev    |     naive = default.replace(**repl)
data-catalog-dev    | ValueError: year 10014 is out of range

[patrick-tripp]

NYOFS has already been fixed and shows up okay in Godiva. LSOFS and LOOFS are fixed now and should start to appear normal soon. The problem was this line in the tds collection config.

attribute name="units" value="days since 9999-12-31T23:59:59.99"

[mpiannucci]

@patrick-tripp yeah they show up fine, but something is different about their metadata that data catalog is reading. It's a problem on my end I think, I'll let you know when I figure out more.

Thanks for the hard work

[patrick-tripp]

@mpiannucci, I might be able to use ncml to modify the funky metadata.

[mpiannucci]

The only one left now is SJROFS

[mpiannucci]

The others will be working in OM beta after data catalog and oceansmap deployment today

[mpiannucci]

SJROFS:

[jamesdoyle21]

I don't see water level for LOOFS or LSOFS. Do we expect these layers to be avaiable?

[mpiannucci]

LOOFS and LSOFS dont have water level

[jamesdoyle21]

Gotchya. Closing this

[cpaternostro]

Because the NYOFS is a different grid, I hear that it doesn't do well to interpolate it into a regulargrid. This is probably the same reason why you need it. Would it be helpful for me to hold a meeting with you and the modeling team so you can ask questions?

--

Chris Paternostro

https://tidesandcurrents.noaa.gov/

On Thu, Jun 2, 2022 at 1:16 PM Matthew Iannucci @.***> wrote:

@cpaternostro https://github.com/cpaternostro Is it possible to get NYOFS to be published with regulargrid data like CBOFS and DBOFS etc (including the zetatomllw field)? If not its no big deal, but it wont be consistent with the other models we have

— Reply to this email directly, view it on GitHub https://github.com/asascience/ott-coops/issues/468#issuecomment-1145108212, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO77FKMKY7XCMVK7RLKNRQTVNDT5FANCNFSM5VWGDJHQ . You are receiving this because you were mentioned.Message ID: @.***>