Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Jeff, It doesn't seem to be an issue with EET, rather GDRADR is writing the grid of only the first defined GDPFUN value. Hopefully can get a fix out soon. -Michael On Tue, Oct 18, 2011 at 8:06 AM, Jeff Lake <admin@xxxxxxxxxxxxxxxxxxxx> wrote: > Not sure if I found a bug, or if I don't have it set up properly.. > below is my script .. > problem is ... EET is not in the 'gdradr' assembled file > I can see it processing EET just like N0Q when I invoke the > script manually.. > So based on below, do I have something set wrong > or .. ??? > > > gdradr << EOFW > proj = lcc/29.5;-96;45.5 > grdarea = 20.0;-120.0;53.0;-65.0 > KXKY = 1000;1000 > GDPFUN = N0Q ! EET > GDFILE = $GEMDATA/radar/YYYYMMDD_radr.gem > RADTIM = current > RADDUR = 20 > RADFRQ = 0 > CPYFIL = > STNFIL = nexrad.tbl > MAXGRD = 1000 > RADMODE = P > r > > e > > EOFW > > -- > -Jeff Lake > MichiganWxSystem.com > WeatherMichigan.net > TheWeatherCenter.net > GRLevelXStuff.com > > _______________________________________________ > gembud mailing list > gembud@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
gembud archives: