Re: questions from last week

[Richard Signell]

Jim,

I'm cc'ing these the replies to the rest of the IOOS model data
interop group as I think all your questions are of potential interest.
>
> I had a few questions for you...  First, I was wondering how you
> "rename" variables in the xml so that ncWMS can plot the current vectors?
> I tried using the variable attribute, but could not get it to work. I presume
> that if I change "u" and "v" to eastward_velocity" and "northward_velocity"
> it should work?

ncWMS combines vector components and plots sticks when it sees
variables that have both "eastward" and "northward" in their
"standard_name" attribute.

For example, if you look at this OpenDAP Dataset Access Form from the
University of Maine's GOMOOS POM model for the Gulf of Maine:

http://rocky.umeoce.maine.edu:8080/thredds/dodsC/gomoos/gompom_2009/GOMPOM_2009_best.ncd.html

you can see that "barotropic_eastward_sea_water_velocity",
"barotropic_northward_sea_water_velocity" have been supplied for the
depth-averaged velocity components "ua" and "va", while
"eastward_sea_water_velocity", and "northward_sea_water_velocity"
attributes have been supplied for the 3D velocity components "u" and
"v".

And if you go to UMAINE's ncWMS server

http://rocky.umeoce.maine.edu:8080/ncWMS/godiva2.html

and choose "GoMOOS Model 2009" (the best time series from Jan 1, 2009
up to and including the latest forecast) you see the variable
"barotropic sea water velocity" and "sea water velocity" appear. And
if you select one of these you get sticks for direction and colored
map for speed (as in the attached image).

This is a construct used by NcWMS because there is no other clear way
to determine vectors from CF compliant data. The utility of having
a better way of specifying vector components has been discussed
previously in CF but never acted on. In the IDV, when you want to
plot vectors, IDV asks the user to identify the vector components, and
whether they are "grid relative" or "true north and south". Clearly
the method in ncWMS is limited to vector components that are truly
"eastward" and "northward".

So by now, you probably have figured out that for ROMS standard output
files, the U and V vector components are still on the C Grid and have
not been rotated to east and north. So you cannot currently use
ncWMS to plot sticks on native ROMS output. Maybe in the not too
distant future!

> Related, I can't seem to find in the CF conventions where
> the standard variable names are listed (e.g., maybe it ought to be
> "eastward_ocean_velocity" or something like that).

The CF Standard Name List is at:
http://cf-pcmdi.llnl.gov/documents/cf-standard-names/

> Second, I still have
> this odd problem with TDS shutting down every day or so.  I think it might
> be the automatic addition of new data that is the problem.

Is the TDS really shutting down, or does a certain aggregation dataset
stop working?
If so, perhaps you could point me toward it, and send along the
catalog so I could take a look.

> Finally, I was curious about your WMS example.  You showed a really
> long URL that basically displayed a map.  I was wondering if there was a way
> to generate the URL via the server?

Yes, all WMS clients do is provide the user with an easy way to
generate the long WMS URL like

http://rocky.umeoce.maine.edu:8080/ncWMS/wms?LAYERS=gomoos_2009%2Ftemp&ELEVATION=0&TIME=2009-06-09T00%3A00%3A00.000Z&TRANSPARENT=true&STYLES=BOXFILL%2Frainbow&CRS=EPSG%3A4326&COLORSCALERANGE=-6.2614026%2C22.605667&NUMCOLORBANDS=254&LOGSCALE=false&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&EXCEPTIONS=XML&FORMAT=image%2Fpng&BBOX=-72.47000122070312,39,-61.60000228881836,46.30000305175781&WIDTH=256&HEIGHT=256

and display the image that is returned. But of course you can
generate the URL however you want -- via a Matlab or Unix shell
script, for example.

-Rich

--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598

[James T. Potemra]

Rich:

Thanks for the reply. I should have been more specific. TDS does not
shut down,
but the model catalog service does. If you were to go to:

http://oos.soest.hawaii.edu/thredds/catalog/hioos/roms/catalog.html

Then select "best time series", then click on the OPeNDAP Access, the
page that
comes up contains:

Error { code = -1; message = "Server Error on dataset
hioos/roms/HI-ROMS_Forecast_Model_Run_Collection_best.ncd"; };

If instead you select "forecast model run", you don't even get to the
next page,
but an "HTTP Status 404 - Not Found" page appears.

I've noticed this behavior almost every day, and I simply restart TDS
and it seems
okay. There is nothing outstanding in the log file catalogErrors.log.
I will clear
the logs, restart TDS and see if I can track it down.

Jim

Richard Signell wrote:
>> this odd problem with TDS shutting down every day or so. I think it might
>> be the automatic addition of new data that is the problem.
>>

> Second, I still have

[James T. Potemra]

Rich (and maybe others):

I've found something odd with the first time value in the THREDDS forecast aggregation.
In my case, the model run served via TDS should start on March 29, 2009. The time variable
(ocean_time) is in "seconds since Jan 1 2000". If I print out the values of "ocean_time"
it looks reasonable. However, if I print out the variable from the TDS "best forecast"
the first value is off. The URL is:

http://oos.soest.hawaii.edu/thredds/dodsC/hioos/roms/HI-ROMS_Forecast_Model_Run_Collection_best.ncd

If I select "ocean_time" and "get ASCII" I get the following:

Dataset {
Float64 ocean_time[ocean_time = 310];
} hioos/roms/HI-ROMS_Forecast_Model_Run_Collection_best.ncd;
---------------------------------------------
ocean_time[310]
-81000.0, -24.0, -18.0, -12.0, -6.0, 0.0, 6.0, 12.0,...

The TDS seems to recognize the actual first time (March 29, 2009) then compute some kind
of off-set back to the definition of "ocean_time" (i.e., March 29, 2009 minus 81000 hours
is Jan 1, 2000). In any case, you'll notice the first time is off (-81000) but the rest
look reasonable.

This causes some problems in both IDV and GrADS, which want to start my timeseries on
Jan 1, 2000 then jump to March 2009. I've also checked the GOMOOS site you provided in
the previous email, and it looks like a similar problem. In this case:

http://rocky.umeoce.maine.edu:8080/thredds/dodsC/gomoos/gompom_2009/GOMPOM_2009_best.ncd.html

Then select "time_offset", "get ASCII" with the result:

Dataset {
Float64 time_offset[time = 1302];
} gomoos/gompom_2009/GOMPOM_2009_best.ncd;
---------------------------------------------
time_offset[1302]
-21624.0, 0.0, 3.0, 6.0, 9.0, 12.0,

In our case I'm not changing time in the catalog xml file. Any ideas
what is going on here? Thanks,

Jim

[Richard Signell]

Jim,

We are pushing the envelope a bit with the Forecast Model Run
Collection stuff on TDS4, but the good news is that these issues are
both helping us understand how to configure Tomcat and the TDS, and
also helping Unidata work out the bugs. Thanks for sticking with it
and trying to track these issues down, and we'll get it worked out
with the help of Unidata support.

-Rich