Creating GFS maps using OpenGrads

Internet Graphics
21

This is more difficult than I thought. I’ve not given up but I need to do more research into how OpenGrADS works!

22

That took longer than I hoped it would but I got there in the end. I’ve attached v1.3 which has the following changes included in it:

  • Increased number of hours to 121 (max NOMADS data available).
  • Resolved cumulative precipitation issue. Precip is now for the previous hour step rather than cumulative from hour 1.
  • Added 300hPa wind plot (as suggested by Budgie).
  • Added check that run hour is one of 00/06/12/18.
  • Limited hour step to one of 1/2/3/4/6/12/24. This was required to sensibly fix the cumultaive precipitation issue.
  • Added check that there is enough NOMADS data available for the selcted combination of start hour, number of maps and hour step.

I’ve done a fair bit of testing, but please confirm that it works for the combinations you wish to use before replacing your current version of the script.

weather-watch-1-3.txt (36.8 KB)

cbarm.gs.txt (7.13 KB)

23

Thanks Chris, I will check it tomorrow morning and report back.

Chris

24

Hi,

I’ve run into a problem with my GFS map creation: I get this error message - see attached file

Error: nc_open failed to open file https://nomads.ncep.noaa.gov:9090/dods/gfs_0p25_1hr/gfs20200823/gfs_0p25_1hr_00z
NetCDF: Access failure
gadsdf: Couldn’t ingest SDF metadata.
No Files Open

The installation have been working fine since spring. Can it be a firewall issue? All inputs are appreciated.

Thanks, Soren

error_message_opengrads.txt (659 Bytes)

25

Soren,
Change the port from 9090 to 443. It worked for me. NOAA changed the ports a few days ago.

Chris

26

Chris,

Thank you … issue solved.

Just out of curiosity… how did you figure out that Nomad changed port to 443?

Thanks,
Soren

27

Soren,
Sorry to take so long to reply but we have had a family bereavement. I found out about the port changes after sending an email to the helpdesk at noaa.gov.
I received the following reply

Changes that were previously advertised to our Opendap service on nomads.ncep.noaa.gov were finalized last week. The changes disabled the 9090 port for Opendap and now utilize port 443 as indicated in the SCN found at https://www.weather.gov/media/notification/scn20-13nomads_website.pdf

Chris

28

Hi Chris,
Thank you so much for all your work on this, greatly appreciated.
I ran these for years, though when 0.25 res came out I could not figure out the fix for Precip Accumulation, so I stopped using it. Thank you for the fix.
I have only automated a few maps so far. https://beaumaris-weather.com/wxgfs_precip.php
kind Regards,

29

Hi Chris,

I always find that leaving something and coming back to it later works wonders.

Today I had another attempt at installing and running the OpenGrads software and got everything working. I believe that the problem was a dodgy version that I downloaded before.

I have also implemented Martin’s Animation script, many thanks for that. I still have to automat the batch file yet, and maybe write a C# program to upload the PNG files.

Many Thanks, :smiley:

Dave.

30

It’s good to know that the scripts are useful and work eventually if not always first time!

31

Hi Chris,

I managed to edit weather-watch.gs to do “Precipitation Type” using a copy of pcptype.gs by “EmsiWx” in a post from 2014.

Thanks, Dave

32

Hello Chris, first of all, let me just say that you are absolutely awesome. Your help with the provided scripts have saved me - days - of hard work.

However, I must say that opendap has not been working well with the provided weather-watch scripts. I get inconsistant results (malformed or inaccessible DAP DAT DDS / gadsdf: Couldn’t ingest SDF metadata. No Files Open).

I have been researching the situation for a long time now and I believe some rate-limiting feature of NOAA’s servers are causing the issues. Still, my solution was to stop using opendap altogether. Now, I am downloading the grib2 filtered data from their site, so that I can recreate the .nc file with wgrib2. Then I load it with this script and it works well.

Just wanted to let you know - it may help someone in the future.

33

Hi and welcome to the forum.

There’s definitely something odd going on with the script and/or the NOAA server. For example, I get what seems to be a similar error to what you’ve seen if I try to generate four six-hourly tmp2m charts for what should be to the current data set (00z on 30/05/2021). If I re-run the script immediately after the error for the previous dataset (18z 29/05/2021) it works perfectly with the charts looking as I’d expect them to look. If I was being rate limited I should see the same error for both datasets because I’d be using the same number of data access attempts for both runs of the script. Also I ran grads in command line mode and used sdfopen to download the tmp2m data for the current dataset (00z today) and sdfwrite it back to disk without any error being displayed. So I’m a little puzzled what’s happening and why it seems to be intermittent.

34

During my experiments, I have seen that error happening even outside of grads, with ncdump for example. If it is not some sort of rate-limit, it is a implementation problem with how opendap works within these apps (they all rely on the same opendap library). I believe that during transmission the noaa server has a few hiccups that are misunderstood “as download completed”. But I am especulating. I really don’t know for sure why that is happening. But I can confirm that the problem extends beyond grads & opengrads.

35

Hi chris is a php file mike

36

Quote from: strandvejr on August 23, 2020, 09:07:17 PM

Chris,

Thank you … issue solved.

Just out of curiosity… how did you figure out that Nomad changed port to 443?

Thanks,
Soren

Hi have the Same Error i run it on windows 10 i have change the port to 443 in the link but when you open the there an error on the link also mike

Landscape mode? ('n' for portrait):
GX Package Initialization: Size = 11 8.5
Command line history in \Users\tanya/.grads.log
ga-> Run C:\OpenGrADS-2.2\Contents\Resources\Scripts\weather-watch-1-3.gs
Enter forecast date - YYYYMMDD, e.g. 20200608 --> 20220221
Enter forecast run hour - must be one of 00, 06, 12 or 18 --> 06
Enter start hour for forecasting, e.g. 6 (minimum = 1) --> 3
Enter hour step - must be one of 1, 2, 3, 4, 6, 12 or 24 --> 6
All files closed; all defined objects released;
All GrADS attributes have been reinitialized
OC xxdr depends on the assumption that sizeof(off_t) == sizeof(void*)
syntax error, unexpected WORD_STRING, expecting WORD_WORD
context: Error { code = 0; message = "/gfs_0p25/gfs20200203/gfs_0p25_18z.info is not an available dataset"^;};
Error: nc_open failed to open file http://nomads.ncep.noaa.gov:80/dods/gfs_0p25/gfs20200203/gfs_0p25_18z.info
NetCDF: Malformed or inaccessible DAP DDS
gadsdf: Couldn't ingest SDF metadata.
No Files Open
37

is it ok to put the to

C:\OpenGrADS-2.2\Contents\Resources
38 
Enter forecast date - YYYYMMDD, e.g. 20200608 --> 20220221
Enter forecast run hour - must be one of 00, 06, 12 or 18 --> 06

Something odd is going on. You requested to start from 06z hour but the code is looking for files from the 18z run…


context: Error { code = 0; message = "/gfs_0p25/gfs20200203/gfs_0p25_18z.info is not an available dataset"^;};
Error: nc_open failed to open file http://nomads.ncep.noaa.gov:80/dods/gfs_0p25/gfs20200203/gfs_0p25_18z.info

I’m wondering if it’s something to do with time zones. I modified the code on my PC which runs UTC/GMT (+1), but I know you’re in Australia so I assume your PC is set to an Aus time zone. Maybe something is happening when the code runs in a very different time zone?

Unfortunately I’m busy with other projects at the moment so don’t really have time to dig back into this code right now to try to debug it.

39

For anyone having problems with the current script which produces hourly charts, I’ve created a new version which generates 3 hourly charts. The 3 hourly data seems more reliable than the 1 hourly data.

Use this script in the same way as described in the first message of this thread. The significant differences are:

  • You can plot charts out to 384 hours rather than 121 hours for the hourly data.
  • Hour steps are limited to multiples of 3 up to 24 hours, i.e. 3, 6, 12 and 24 hours between charts.
  • There is a 5th parameter/prompt which is the number of charts of each variable to create. This was previously set by editing the script. So if you set a start hour of 6, 3 hourly steps and 4 charts you will get charts for 6, 9, 12 and 15 hours. This value defaults to 4.

I’ve done a few test runs to check the input validation and it seems to work OK, but as I’ve said previously there are a myriad of possible input combinations and I might have missed testing one of them! Please let me know if you hit any snags.

Finally, as with the hourly script, make sure you run it when data is (or should be) available. At the moment the 3 hourly data appears to become available about 5.5 hours after the run initialization time. So the 00z run data would be available around 05:30 UTC.

weather-watch-1-4-3hr.gs.txt (37.1 KB)

cbarm.gs.txt (7.13 KB)

40

Thanks Chris,

The updated script is working fine with the 3 versions of it that I currently run. =D> :thumbright: