>From: "Jennie L. Moody" <address@hidden> >Organization: UVa >Keywords: 200004091534.JAA08082 XCD DMGRID ETA MRF FTP backup Tony, >I finished with the first batch. I noticed that you are saving >the forecast gridfiles too; Not knowing exactly what you were after, I decided to try and save off all ETA and MRF files. >we don't archive those, so you don't >need to ftp them. We only need these files: > >5011-5020 >5041-5050 >5101-5110 >5401-5410 >5431-5440 OK. >(One thing though - it lookes like your NGM gridfiles are stepping >on your forecast ETAs. You probably already know that.) The same >would be happening with us if our grids acually got made. That would have been happening on the first or first and second day of the "save" effort. After some point, I changed the way I was saving grids. I moved the NGM grids to GRID files starging at 5501 and used all numbers from 5011 - 5070 for the ETAs. This was accomplished by a modification to my RTMODELS.CFG: # History: 20000403 - Changed ETA grid filing format (3 -> 1) in order to # file grids out to 60 hours (March 29, 2000 NWS change) # Moved start of NGM grids to 5501 SCRATCH=5001 ETA= 1 5011 120000 240000 480000 MRF= 1 5101 120000 240000 960000 MAPS= 0 5201 30000 MDR= 2 5301 AVN= 3 5401 120000 240000 720000 NGM= 3 5501 120000 240000 480000 My setup is now saving the 0 and 6Z runs in one set of GRID files and the 12 and 18Z runs in the next. >I wrote to Penn State, our upstream server, and they said they decode >their grids for GEMPACK, and haven't had a problem with it. The problem is in McIDAS. Jennie proved this to me by noting that you are logging the receipt of the grib products; the ETA grib messages are making it to your machine with no problmes. What your problem is, I don't know. We need to address this _soon_. I am under the impression that you are now in a position to start changing configurations since your forecasting and archiving responsibilities are over for awhile. If this is the case, we really should start making the changes that are called for: o move NGM grids to new GRID file numbers o change how ETA grids are supposed to be saved o split MRF ingestion into MRF and AVN o update your system with the most current bugfixes o attach the large set of processes that run to produce products; this would be the biggest headache since there are so many files that potentially need modification >I think you'll agree that this whole ftp process is for the >birds. Yes, I do! >I was looking through the config files to desparately >find an answer, and I noticed that the file type "84" was >referenced twice in NOGRIB.CFG: > >#83 |-1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 >#86 |-1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 >#89 |-1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 >84 |-1 | -1 | -1 | -1 | 207| 207 | -1 | -1 | -1 | -1 >#77 |-1 | -1 | -1 | -1 | 37 | 44 | -1 | -1 | -1 | -1 >#78 |-1 | -1 | -1 | -1 | 37 | 44 | -1 | -1 | -1 | -1 >#39 |-1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 >#64 |-1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 | -1 > >#39 |-1 | -1 | -1 | -1 | 211 | 211 | -1 | -1 | -1 | -1 >#64 |-1 | -1 | -1 | -1 | 211 | 211 | -1 | -1 | -1 | -1 >#77 |-1 | -1 | -1 | -1 | 21 | 26 | -1 | -1 | -1 | -1 >#78 |-1 | -1 | -1 | -1 | 21 | 26 | -1 | -1 | -1 | -1 >77 |-1 | -1 | -1 | -1 | 211 | 211 | -1 | -1 | -1 | -1 >78 |-1 | -1 | -1 | -1 | 211 | 211 | -1 | -1 | -1 | -1 >81 |-1 | -1 | -1 | -1 | 211 | 211 | -1 | -1 | -1 | -1 >77 |-1 | -1 | -1 | -1 | 203 | 203 | -1 | -1 | -1 | -1 >78 |-1 | -1 | -1 | -1 | 203 | 203 | -1 | -1 | -1 | -1 >80 |-1 | -1 | -1 | -1 | 203 | 203 | -1 | -1 | -1 | -1 >81 |-1 | -1 | -1 | -1 | 203 | 203 | -1 | -1 | -1 | -1 >82 |-1 | -1 | -1 | -1 | 203 | 203 | -1 | -1 | -1 | -1 >84 |-1 | -1 | -1 | -1 | 215 | 215 | -1 | -1 | -1 | -1 > >Is that a problem? No, this is not a problem. NOGRIB.CFG is a list of the grids to not decode. Back on March 29, the model number for ETA grids changed. The change had ones previously labeled as 89 switched to 84, and ones previously labeled as 85 switched to 84. You will note that the entries above reference grids on different projections (207 vs 215), so the entries are not redundant. Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.