Toberumono / WRF-Runner

A simple script for running WRF.
GNU General Public License v3.0
14 stars 3 forks source link

GRIB #1

Closed DariusLLL closed 8 years ago

DariusLLL commented 8 years ago

Hi Joshua,

Sure I have got your messages and was going to reply to you. Thanks for fast fix. I did like you said (with brew) and wrf-runner is working now :) BUT. As you remember I had problems with timing fraction setting when trying to run at some day time. So I decided to set "use-computed-times" : false. I have made python scripts and they rewrite my namelists like I want so I only need to launch your wrf-runner with "use-computed-times" : false and should be ok. I have run in a problem with GRIB download. My GRIB config line is"url" : "ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.%tY%tm%td%tH/gfs.t%tHz.pgrb2.0p25.f0%iH" This works well when "use-computed-times" : true. But it is not ok when "use-computed-times" : false. For example namelist.wps got dates: start_date = '2016-04-26_03:00:00', '2016-04-26_03:00:00', end_date = '2016-04-27_03:00:00', '2016-04-27_03:00:00', wrf-runner is trying to pick GRIB files starting from hour 00:00:00 and simulation fails. Also question. For me looks like timing offset is working only when "use-computed-times" : false. Is that by design?

Regards

Darius

Toberumono commented 8 years ago

Hi Darius,

I'm putting together some fixes to correctly load the duration data from the namelists now, and I'll push them some time this afternoon. I don't have an eta for the fixing offset data and debugging the grib url issue yet, but it shouldn't be too long.

Toberumono commented 8 years ago

I just pushed the fixes for loading duration data and offsets. The update should be available through homebrew.

Toberumono commented 8 years ago

Upon looking through the logic, the changes to how duration data is loaded should fix the GRIB issue as well. Please let me know if the issue persists.

DariusLLL commented 8 years ago

Hi Joshua,

Hmm.. still the same. I did brew update but..

SEVERE: Failed Transfer: ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.2016042703/gfs.t03z.pgrb2.0p25.f000 -> /home/darius/Working/2016-04-27_03_00_00/wget/gfs.t03z.pgrb2.0p25.f000

Regards

Darius

conf_and_namelist.zip

Toberumono commented 8 years ago

The namelist.input file you attached appears to be set to run a simulation over a time period of 48 hours. However, the end times indicate that it should run for 24 hours. I assume that the run_days and run_hours fields are the incorrect ones?

DariusLLL commented 8 years ago

Good catch.. :) It is mine mistake, run_days should be 0 (mistake in python script)

Toberumono commented 8 years ago

If this solves the problem, I'll mark this as closed.

DariusLLL commented 8 years ago

Hi Joshua,

If you mean namelist.input simulation time - no. It does not.. :( I cant get GRIB files downloading from hour 03:00:00 or hour 06:00:00 in any way. I have tried many options with "use-computed-times" : false and true. The only option is working is when I set simulation time start from 00:00:00 in name lists with "use-computed-times" : false. And of course is working with "use-computed-times" : true, but simulation start time only at 00:00:00 (when I set offset it fails because GRIB files are downloaded without offset)

Regards

Darius

Toberumono commented 8 years ago

Hi Darius,

I'll start working on a more flexible system for grib downloads, but I probably won't be able to do much serious work on it until the weekend.

DariusLLL commented 8 years ago

Hi Joshua,

Great! I will wait.

Darius

Toberumono commented 8 years ago

Hi Darius, The fixes are going to be a bit involved, and I won't be able to do serious work on it for the next week or so. For now, I'd recommend removing the hours flag from the constant portion of the url. (Replace it with 00). Part of the issue was that the source posts new data every 6 hours, so the simulations that were started on the 3, 9, 15, and 21-hour marks were unable to download the GRIB data.

Toberumono commented 8 years ago

Hi Darius, I'm very sorry about the delay. My course load was significantly larger than I expected.

I've resumed active work on the project, and should have a temporary fix within the next couple days, and a more permanent one a few days after that.

DariusLLL commented 8 years ago

Hi Joshua,

Thanks for all the job. But I have to say that i could not wait and made everything in python. The server is running now and looks that all is working well. Especially Grib download because I am running in parallel (server got 32 processors so I launch 24 files download at once).

But please finish your project. I would say your runner is the best public available.

Regards Darius

Toberumono commented 8 years ago

Alrighty, then. I'll finish up the changes and then close this issue.

Toberumono commented 8 years ago

Version 4.1+ (for which documentation is forthcoming) can compute the correct files for downloading. I've attached a configuration file (It's in a .zip in order to satisfy GitHub's upload requirements) that will work. configuration.json.zip