<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi, Shaun -- <div>In your first example, when you just open the URL and then define the 3-D object, the I/O is done 1 2D grid at a time, looping over time, so you will hit the server 29 times, bringing back your lat/lon subset grid for each time step. The server does not cache the subset data, so if you were to ask for this same data set again, it would take just as long. </div><div><br></div><div>In your second example, you are using the _expr_ syntax to create a new data set that is not an analysis result, merely a subset. The difference is that this time the GDS will write out this 3-D data set as a binary file in its cache and then send it you across the network as you make data requests from the GrADS client for the variable called 'result'. Because you invoke 'define' again, with the same 3-D grid dimensions, the network traffic will be the same from the server to you, 29 hits, one 2-D grid per time step. </div><div><br></div><div>This second technique requires an extra I/O step, once to read the grib2 data from the original file and write it out to the cache as a binary file, and then a second I/O step to read the binary file in the cache to fulfill your data request from the client. So, for small subsets, it will be faster to just open the URL and invoke 'define'.</div><div><br></div><div>However, the GDS does not invoke GrADS to do the I/O to read the binary data in the cache -- it is a direct file read, so if the cached file is sufficiently big, then the second technique will end up being faster. In this case, "sufficiently big" means BIG, and you are likely to run into configuration limits on the size of a _expr_ result before you notice a performance difference. Also, you will populate the server's cache with a lot of binary files, causing their server to gobble up local resources and slow down. </div><div><br></div><div>The bottom line is this: don't use _expr_ syntax for basic subsetting. </div><div>--Jennifer</div><div><br></div><div><br><div><div>On Aug 10, 2011, at 10:28 AM, Shaun Carney wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hello,<br>I have what hopefully is a simple question. I'm trying to do a clip of<br>a precip grid to a small area on a grads server rather than opening<br>the entire dataset and then doing the clip. The following works:<br><br>'sdfopen <a href="http://nomads.ncep.noaa.gov:9090/dods/nam/nam20110808/nam_crb_00z'">http://nomads.ncep.noaa.gov:9090/dods/nam/nam20110808/nam_crb_00z'</a><br>'set lon 269 273'<br>'set lat 12 15'<br>'set t 1 29'<br>'define namprecip = apcpsfc'<br><br>However, when I try to give an expression so that I only get the<br>subset from the server, it will not work:<br><br>baseurl = '<a href="http://nomads.ncep.noaa.gov:9090/dods/nam/_expr_'">http://nomads.ncep.noaa.gov:9090/dods/nam/_expr_'</a><br>datasets = '{nam20110808/nam_crb_00z}'<br>expression = '{apcpsfc}'<br>dimensions = '{269:273,12:15,1000:1000,00Z08AUG2011:12Z11AUG2011}'<br>'sdfopen '%baseurl%datasets%expression%dimensions<br>'set t 1 29'<br>'define namprecip = result'<br><br>Grads gives the following error:<br>gadsdf: Couldn't ingest SDF metadata<br><br>Any ideas why this will not read? On a more basic level, will there be<br>any speed improvement using the second method rather than the first,<br>or does setting the coord box before defining namprecip reduce the<br>data transfer?<br><br>This will be implemented on a computer with slow connection speed so I<br>want to minimize data transfer.<br><br>Thanks!<br>Shaun<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>