VIMS SELFE problems continued

[brandonmayer-zz]

Issue #17 may be more pervasive throughout the VIMS SELFE datasets then first anticipated.

I'm having a problem with this dataset as well:

http://comt.sura.org/thredds/dodsC/data/comt_1_archive/inundation_tropical/VIMS_SELFE/Hurricane_Ike_3D_final_run_with_waves.html

While some variables successfully deliver data, I cannot access u or v which are typically quantities of interest. Just using the ncml interface to issue an ascii get for u and v I get

Error { code = 500; message = "NcSDArray InvalidRangeException=Number of ranges in section (2) must be = 3"; };

I was asking for u [time=0:1:3,nodes=0:1:15], v[time=0:1:3,nodes=0:1:15] just as a small test.

@brianmckenna confirms.

@rsignell-usgs please review, thanks!

[rsignell-usgs]

The reason these datasets are not working is that the NcML has u and v dimensioned as 2d variables (time, node) without the vertical dimension. I'm taking a look now. .

[rsignell-usgs]

@drf5n, is the vertical coordinate in these selfe run ocean_sigma or ocean_s_coordinate_g1? I see the variable Cs, which would suggest ocean_s_coordinate_g1, but I don't see the depth_c term that would also be required: http://cf-metadata.github.io/cf-conventions.html#_ocean_s_coordinate_generic_form_1

If there is in fact a depth_c value, we can just add it into the 00_dir.ncml file.

[drf5n]

I think the depth_c is 1000m for these runs.

It could be much more awkward than that -- SELFE uses a hybrid S over Z coordinate, somewhat like http://cf-metadata.github.io/cf-conventions.html#_ocean_sigma_over_z_coordinate, but S rather than sigma. In this particular case, it was configured with the Z cutoff at 9000m, which, with a max depth of 8012.3 degenerates into a pure S, and h_c or depth_c is 1000m.

Also, the new SELFE/SCHISM LSC2 scheme has a spatially-varying S over vanishing cells: http://ccrm.vims.edu/schism/paper-LSC2.pdf . These might fit into ocean_s_coordinate_g1 (_g3?) but with an explicitly spatially varying S(k,j,i) or S(k,node) field.

[rsignell-usgs]

Okay, fixing the reported problem was easy.

It turns out the Selfe 00_dir.ncml files are specifying:

<variable name="u" shape="time node" type="float">

which is incorrect for the 3D data. This was probably cut-and-pasted from a 2D run.

We could fix this for the 3D runs by changing the above line to:

<variable name="u" shape="time nv node" type="float">

But a more flexible fix is to realize that since we are merely modifying the metadata for these variables, we don't need to specify the shape or type. So a better solution is to simply change all the 00_dir.ncml files to:

<variable name="u">

This works, as you can see here: http://comt.sura.org/thredds/dodsC/data/comt_1_archive/inundation_tropical/VIMS_SELFE/Hurricane_Ike_3D_final_run_with_waves.html

As a bonus, I added the proper specification of the vertical coordinate, even though I don't think we have any 3D CF/UGRID compliant software yet.

The fix for this one dataset is here: https://github.com/ioos/comt_1_archive/commit/3951c576497b467c0b2d3a1de6bf69a44a3f2a24

I'll go ahead and change the other 00_dir.ncml files.

[rsignell-usgs]

The files are changed. @drf5n would you mind taking a look at the 3D selfe files here: http://comt.sura.org/thredds/comt_1_archive_summary.html and see if they look okay to you also?

[drf5n]

I plotted a few with NCtoolbox, and they seemed OK to me

uris={'http://comt.sura.org/thredds/dodsC/data/comt_1_archive/inundation_tropical/VIMS_SELFE/Hurricane_Ike_3D_final_run_with_waves' 'http://comt.sura.org/thredds/dodsC/data/comt_1_archive/inundation_tropical/VIMS_SELFE/Hurricane_Ike_3D_final_run_without_waves' 'http://comt.sura.org/thredds/dodsC/data/comt_1_archive/inundation_tropical/VIMS_SELFE/Hurricane_Rita_3D_final_run_with_waves' 'http://comt.sura.org/thredds/dodsC/data/comt_1_archive/inundation_tropical/VIMS_SELFE/Hurricane_Rita_3D_final_run_without_waves'  }

i = 1;
nc=ncgeodataset(uris{i});

trisurf(nc{'ele'}(:,:)',double(nc{'x'}(:)),double(nc{'y'}(:)),squeeze(double(nc{'u'}(3,7,:))));
shading interp;view(2);colorbar

I think the fix is fine.