UGRID face-centered velocities with ncWMS 2.1?

[rsignell-usgs]

I installed ncWMS 2.1 and added a UGRID dataset OPeNDAP URL: http://www.smast.umassd.edu:8080/thredds/dodsC/FVCOM/NECOFS/Forecasts/NECOFS_GOM3_FORECAST.nc

I get back this error:

Status of dataset NECOFS-GOM3 (for debugging)

State: ERROR
Loading progress

Starting loading
Using dataset factory: class uk.ac.rdg.resc.edal.dataset.cdm.CdmGridDatasetFactory
Error report

Stack trace:
java.lang.IllegalArgumentException :This plugin needs the variable u, but this dataset does not supply it.
uk.ac.rdg.resc.edal.dataset.AbstractDataset.addVariablePlugin(AbstractDataset.java:156)
uk.ac.rdg.resc.edal.dataset.cdm.CdmDatasetFactory.createDataset(CdmDatasetFactory.java:86)
uk.ac.rdg.resc.edal.catalogue.jaxb.DatasetConfig.createDataset(DatasetConfig.java:254)
uk.ac.rdg.resc.edal.catalogue.jaxb.DatasetConfig.refresh(DatasetConfig.java:213)
uk.ac.rdg.resc.edal.catalogue.jaxb.CatalogueConfig$1.run(CatalogueConfig.java:154)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)

I'm not sure what that means, as this dataset does have the variable u, but perhaps that's a red herring? u wouldn't be required anyway, right? We have a lot of UGRID data with just water level.

[guygriffiths]

The error is appearing when we try to associate u/v components to add a vector field.

The variables "u" and "v" have not been added to the dataset because they are not defined on the same node-based grid as most variables, but rather on a separate face-based grid. I haven't implemented the optional "face_coordinates" attribute and the associated grids - none of the example UGRID files I found had this attribute.

Can you send me the NetCDF file for this dataset? Debugging over the network is too slow to be practical, and whenever I try and download it, I get "DAP server error".

[rsignell-usgs]

I used the NCO tools to extract the 1st time step as a netcdf file:

 ncks -d time,0 "http://www.smast.umassd.edu:8080/thredds/dodsC/FVCOM/NECOFS/Forecasts/NECOFS_GOM3_FORECAST.nc" ugrid_face_velocity.nc

I put the resulting file on our TDS: http://geoport.whoi.edu/thredds/catalog/usgs/data2/rsignell/models/fvcom/catalog.html?dataset=usgs/data2/rsignell/models/fvcom/ugrid_face_velocity.nc

So you should be able to use the HTTPServer link to download: http://geoport.whoi.edu/thredds/fileServer/usgs/data2/rsignell/models/fvcom/ugrid_face_velocity.nc

[guygriffiths]

Thanks - I tried ncks but that's what was giving me the "DAP server error".

I've got a proof-of-concept version working which supports this dataset - I'll tidy it up tomorrow.

Note that several of the variables will not be available since:

• Only spatial variables are supported
• The vertical dimension is dependent on the horizontal dimension - i.e. all variables with a vertical dependence are fully 3d unstructured grids, which are not supported (as opposed to layered 3d grids made of unstructured 2d layers with a common vertical axis).

The supported variables are: h, icing_0kts, icing_10kts, x, xc, y, yc, zeta, ua, va

[rsignell-usgs]

@guygriffiths , regarding download via ncks, probably your NCO install has issues. If you are on linux or mac, you could install an up-to-date and working version of NCO by downloading miniconda (free) and then doing "conda install -c ioos nco". I bet it would work (since that's what I used).

Regarding this FVCOM data, it's a layer model just like most others (except for ICOM, I guess). All vertical layers share the same horizontal unstructured mesh.

[guygriffiths]

Does this mean that there is no horizontal variation in the vertical co-ordinate? It is specified as a 2D variable, so I would have assumed that there is horizontal variation (i.e. it is not a simple layering). We currently have no provision in our data model for 2D vertical / time axes so it could be a difficult one to implement...

[rsignell-usgs]

@guygriffiths , oh I see. Yes, there is horizontal variation in the vertical coordinate. We never interpolate to standard levels (a 1D vertical coordinate) because we don't want to lose information, so all of our coastal ocean models have the CF dimensionless coordinates (e.g. "ocean_sigma_coordinate", "ocean_s_coordinate_g1", "ocean_s_coordinate_g2" where the actual z level has to be computed via the specified formula (http://cfconventions.org/Data/cf-conventions/cf-conventions-1.0/build/apd.html)

Could a workaround be to just allow selection of the vertical levels via the WMS request? (e.g. elevation=0 for top layer, elevation=39 for bottom layer?

We find that most people just want to look at the surface layer or bottom layer anyway...

[guygriffiths]

I'll have a think about it. It may be straightforward to create a vertical axis which has units of "level" out of the 2D axis. That would have the effect you suggest.

[guygriffiths]

OK, I've implemented face-based grids and a level-based vertical coordinate in the develop branch. This dataset is now working properly for local datasets. I can't yet get it to work over OPeNDAP but that's due to a different issue (https://github.com/Reading-eScience-Centre/edal-java/issues/45). Once I've fixed that I'll retest and close this one.

[rsignell-usgs]

I can confirm that both the face-based velocity and level-based vertical coordinate are working great!

Here are plots from Godiva3 of bottom temperature field (nodes) and surface velocity speed (face centered) from a UGRID-compliant FVCOM model output: