<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Sergey -- <div>That is a pathological use of GRIB2 format, and I cannot imagine WHY the Japan Meteorological Agency would set up their files that way. Handling it in GrADS requires more than switching a BREAK to a CONTINUE in gribmap. The record length will likely be ultra-long (requiring 8 octets instead of 4, which is not currently supported) and the memory use will be high and I/O will be slow. A file like this be unusable if the grids are very high resolution. If you have a small sample of this kind of grib2 file, I will take a look (please send it to me offline), but I make no promises that we will support this abuse of the GRIB2 format. </div><div><br></div><div>I suggest you use wgrib2 to break up the record into its proper pieces, writing out one one field per record, saving only the fields you are interested in. Then you can read it in GrADS in the normal way. </div><div>--Jennifer</div><div><br></div><div><br><div><div>On Dec 7, 2010, at 11:26 PM, Sergey Varlamov wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Dear GrADS developers and experts,<br><br>My problem is that with the new version of gridmap for<br>grib2 files I can not skip record.fields in grib2 file that do not<br>fit to requested time stepping.<br><br>Working with old versions of grads (1.x) I often used<br>grads description files (ctl) to skip some time steps<br>from analysis by making custom description file<br>where was specified larger time step value (and smaller total<br>number of time steps) compared with these in the grib file(s).<br>Example: select only 0,3,6 etc. hours forecasts from the file<br>that includes 0,1,2,3,4,.. etc. hours forecasts.<br>Gribmap utility for grib1 files perfectly scanned such files (grib+ctl) and<br>generated index file where only matched records were<br>included and other skipped, as I expected.<br><br>But trying to do the same with the Japan Meteorological Agency (JMA)<br>grib2 files and gribmap for grads v 2.0.8, I met the problem that new<br>gribmap utility<br>for grib2 files stops scanning JMA files after the first non-matching<br>field is found:<br><br>1.11: lev1=101 var=0,3,1 valid time 2010110113:00 (t=1.33333) has<br>non-integer grid index<br><br>I was expecting that this field must be skipped as NON-MATCHING<br>and next fields analyzed, but really all following field of analyzed record<br>were skipped.<br><br>As I found, this resulted from both specifics of JMA grib2 files<br>and design of gribmap utility:<br><br>1) JMA grib2 file has only one record where all subsequent<br>forecasts for all parameters are sub-records (fields in terms of gribmap).</div></blockquote></div><div><blockquote type="cite"><div><br>2) Design of gribmap (gagmap.c file) is such that:<br>g2time_check functions return -99 (an error) and gribmap<br>function uses this error information to BREAK sub-records (fields) analysis<br>cycle, leaving all other VALID fields inside of the same grib2<br>record do not tested/indexed.<br><br>I would like to change BREAK statement to CONTINUE<br>in the fields analysis cycles of gribmap function.<br><br>Is it possible or I do not see some hidden problems of<br>such modification?<br>Could it be done in the official gribmap<br>utility distributed with grads (possibly with some new<br>option key added as it could increase analysis time and<br>verbose output size)?<br><br>Sincerely yours,<br>Sergey Varlamov<br><br>Senior Scientist<br>Research Institute for Global Change<br>JAMSTEC, JAPAN<br>E-mail: <a href="mailto:vsm@jamstec.go.jp">vsm@jamstec.go.jp</a><br><br><br>_______________________________________________<br>gradsusr mailing list<br><a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>http://gradsusr.org/mailman/listinfo/gradsusr<br></div></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>--</div><div>Jennifer M. Adams</div><div>IGES/COLA</div><div>4041 Powder Mill Road, Suite 302</div><div>Calverton, MD 20705</div><div><a href="mailto:jma@cola.iges.org">jma@cola.iges.org</a></div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></span></div></span> </div><br></div></body></html>