Siphon - A collection of Python utilities for retrieving data from Unidata data technologies.
like adding the dataset query parameter - I still get no datasets
In that top-level catalog, there are not any datasets, but there are references to other catalogs, which are available from the
.catalog_refs attribute.
@mikebelanger Pretty much, unfortunately since the RDA does not have the data set up (as far as I can tell) using a TDS Grib Collection. Another option for you is to programmatically generate the url, like:
base_url = 'https://rda.ucar.edu/thredds/catalog/files/g/ds084.1/'
dt = datetime(2017, 10, 1)
url = base_url + f'{dt:%Y/%Y%m%d}'
Not completely sure I got the syntax completely correct, but hopefully the idea comes across
I just wanted to make sure I wasn't missing some other method, or some archive feature
hey guys I'm having an issue accessing RDA's archives. An issue similar to here: GIS4WRF/gis4wrf#25. Basically I'm getting a
HTTPSConnectionPool(host='rda.ucar.edu', port=443): Max retries exceeded with url: /thredds/catalog/files/g/ds084.1/2019/20190224/catalog.xml (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fec30e04650>: Failed to establish a
new connection: [Errno 110] Connection timed out',))
I'm getting that error from running a script on my remote machine.
I can still access that url from my local laptop
so its probably something to do with IP configuration?
hmm, looking more into this issue - I've found the following e-mail thread: https://www.unidata.ucar.edu/support/help/MailArchives/thredds/msg02351.html
The email from Unidata THREDDS Support, sent on Tuesday, April 18, 2017 11:36 AM, references the above error
judging from the rest of the e-mail exchange - the problem is related to an overload of the server
if this is a THREDDs issue - I can stop reporting it here, and contact support
but I want to make sure I'm using siphon properly
I think there may be an error in the way that either netcdf-java or thredds is interpreting accumulated precip valid times. I know there's a weirdness already, that the NCEP GFS grib files have both a T0-now accumulation, and an either 3 or 6h accumulation (depending on if the valid time is divisible by 6 or not) and thredds/netcdf-java has no way of distinguishing between those two things, since they both use the same variable name and are valid at the same time. But..
I've been trying to plot accumulated precip valid at a time, using python pulling from a thredds server, where I am only including the T0 to now grib records in the file I'm pulling from, and the values were always wrong, when compared to a few other sources of plots. I think I just figured out that either thredds or netcdf-java is assuming the T0 to now accumulated precip is actually valid at the midpoint, e.g. (T0 to now)/2, because if I plot the precip at that time, it matches the other (gempak, etc) plots at T0-now. Has been driving me nuts for a long time.
Let me know if I can help demonstrate what I'm talking about or othewise help get this fixed.. Not sure if it's thredds or netcdf-java - I suspect the latter.
Seems like although it has a time start and time end, it's not an average value over that time, but rather valid at the end time.
Greetings Pete! Can you point me to the problematic dataset? When you pick a time to use for the plot, are you pulling from just the time variable, or are you looking at the the time variables "bounds" attribute to get the full picture of the time associated with the interval? Have you tried looking at the data through the IDV shudders?
Unfortunately, NCSS does not allow requesting multiple levels. (Correct me if I’m wrong @lesserwhirls )
Dang...sorry for the delay here @PTH1_twitter @dopplershift ! Currently in 5.0, NCSS can only pull out a single level, but all the variables in the request need to be on the same vertical coordinate system. For example, in GRIB collections, you'll often see coordinates like isobaric1, isobaric2, height_above_ground, altitude_above_msl, etc...the variables would all need to use the same coordinate in order to subset a single level from the vertical (e.g. all using isobaric1 and not isobaric2). Also, the value you'd use in the request needs to be of the same unit as the coordinate system is defined, as the NCSS API does not support supplying a unit. So, for GFS 0.25 degree forecast temperatures on isobaric surfaces, we'd have pressure in Pa, and would request something like vertCoord=85000.
I can shoot you the notebook I was using to test if that helps. I did notice that if I pull from thredds-test.unidata.ucar.edu and ask for data valid at what would be time 0 of the data set, it gives me the 3h precip values, but marked with a time of 1.5h. If I request the same from thredds.unidata.ucar.edu or thredds.aos it bails with a time out of bounds type error.
But on all of those, if I request data valid at 3h, I get data that looks exactly like the 6h gempak/pivotal/wxp/whatever plots. The max value from thredds at 3h is identical to the gempak max value at 6h too
No, that's not right. it's still wrong. If I request data from the 12 UTC run for 18 UTC (a 6h forecast) the time listed in the ncss subset is 6h but the data actually matches the 12h forecast from gempak/pivitol/wxp/etc. thredds is assuming that the 6h time is in the middle of the begin/end periods, rather than at the end.
It doesn't show in the notebook I'm testing with, but it does in a python plotting program. It's not the cleanest looking program but I can send it to you if it would help.
Ok, I think I see what the TDS is doing here. It looks like the way the NCSS handles mixed interval variables changed between 4.6 and 5.0, so that's one reason why you are seeing different behavior between thredds.ucar.edu and thredds.aos (thredds-test, thredds-dev, etc.). However, we'll focus on 5.0 here.
It all comes down to trying to pick which interval to use when a requested time is contained within more than one grid. For example, let's suppose that we have two grids for Total_precipitation_surface_Mixed_intervals_Accumulation valid at 2019-11-30 18Z, but one is a 6 hour accumulation and one is a 3 hour accumulation.
Now, let's say a user uses NCSS requesting a single time, 2019-11-30T18:00:00. What should the server do?
I think the line of thought was that the user supplied one date/time, and generally expects to receive one grid in return. If we go with that assumption, then the question becomes which grid does the server return - the one representing a 3 hour total or the one representing a 12 hour total?
What the server does is compute the mid-point value from the bounds of the two accumulation totals, and chooses the one whose mid-point is closest to the requested time (effectively the one with the smallest accumulation time period).
What if a time range is given instead of a single value? Well, NCSS bombs out and returns a message that basically says "not yet implemented". What should we do there? Probably an extension of the same idea for a single value. But is that right, or should we return any grid that overlaps with the interval requested?
What could help here, for both cases, is for the NCSS API to allow a user to specify an interval size in addition to the time, something like
time=2019-11-30T18:00:00&timeInterval=P6h, which would signal a 6 hour duration for the accumulation valid at 2019-11-30 18Z. Then, for a request with a time range, it would return any 6 hour accumulation intersecting the time_start and time_end parameters of the request. We'd still need to decide what to do by default if no timeInterval was specified in the request.
That might do it. I'm trying to relate what the thredds/ncss is doing when compared to how you'd do it in GEMPAK. In GEMPAK, let's look at the 9h forecast time. There are two variables valid at that forecast hour which are accumulated precip. One is a 3h (6 to 9h accum) and the other is a total (time zero to 9h) accumulation. These both show up as valid at the 9h forecast time, but one is named P03M (that last M means millimeters) and the other is named P09M. Similaraly, at, for example, 48h, there is one that is a 6h accumulation (42 to 48h - don't ask me why NCEP uses 6-hourly accumulations at 6/12/18... and 3h at 3/9/15/21... ) and the other is the total (time zero to 48h) - both are valid at the 48h forecast time - one is named P03M and the other is P48M.
I understand that thredds is trying to be forgiving and give me some data at the time that I requested, but I would like a way to say give me this exact data at this exact time or give me an error.
I think being able to tell ncss the timeInterval might fix that - because I could ask for a Total_precipitation_surface_Mixed_intervals_Accumulation from the 12 UTC 29 Nov, 2019 data set, valid at 21 UTC (9h forecast) and either set timeInterval to 3 to get the 3h accumulation product, or timeInterval to 9h (I guess?) to get the 9h product. Or maybe there's a special time/word that would use the 0 to now accumulation? Is that kind of thing going to be really specific to this data?
Unfortunately, yes, a lot of this is specific to GRIB. However, I think this particular extension to NCSS is needed, otherwise you cannot uniquely request a known combination of valid time and time interval. The 0-valid time (run total) is a special case, and we'd want to be able to handle that. I've started a github issue at Unidata/tds#55 - let's see what ideas we can come up with.
Sounds good, thanks! I'm just glad I finally figured out what was happening. Was driving me nuts, because the plots I was making matched my wxp ones for pressure, height, temp, etc, but the precip was always wrong. I'm kind of surprised that people haven't come across this problem already. If you just request a certain time accumulated precip from thredds, it's most likely incorrect..
For mixed interval variables in which there are multiple grids at the same valid time (but with differing interval widths), then it gets nasty for sure. If there are no overlaps, then the mid-point stuff should not come into play. My guess is people grab from OPeNDAP or cdmremote, although if they don't inspect the bounds attribute to see exactly what they are dealing with, then there will be issues as well. The funkiness of translating a collection of GRIB messages to something that looks like netCDF introduces all kinds of weird stuff. I don't think anyone would write a netCDF file with these kinds of mixed intervals on purpose, at least without a lot of soul searching.