[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[McIDAS #EBG-395236]: Jython Scripting

Hi Daphne,

> Thank you very much for producing these images for us!

No worries.

> I am able to display and get
> values for the points in both brightness counts and the temperature 
> difference in K.


> One
> thing I was wondering about was the fog algorithm. I had been using 
> 128+10*(T10.7-T3.9)
> and was wondering if there was any significance in using 150 instead?

There is no great significance to using an offset of 150 vs 128.  
As I recall, we found the formula on a CSU/CIRA web site a _long_ time
ago, and have been using it ever since.  The objective in the formula
was/is to be able to save the TEMP values with 1 digit of precision
( 10*(T10.7-T3.9) ) in a 1-byte variable that can range in values from 0
to 255.  If the range of differences between the 10.7 and 3.9 um point
values is even spread evenly (e.g., Gaussian) around 0 (zero), then
choosing an offset of 128 would make the most sense.  If the values are 
skewed by there being more negative values, then it would make sense
to make the offset larger than 128, say 150.  The important value is, 
of course, the temperature difference.

> In terms of the station data, we had written a python script that would would 
> read in
> the station lat/lon locations from the csv file and write the pixel values at 
> each
> station for each image to an output file. Since before we were requesting 
> data from both
> Ch4 and Ch2 images (and then subtracting the two values obtained), we kept 
> running into
> a java heap error when running the script for all 366 days. After processing 
> 50 days or
> so we get this message:
> 22:32:33.397 [MainThread] INFO  jython - print: java.lang.OutOfMemoryError:
> java.lang.OutOfMemoryError: Java heap space

Hmm... I think that this is very strange.  I would have thought that Java's
garbage collection would take care of memory use as long as enough memory
was allocated for the Java virtual machine at start-up.

> I am going to tweak the script and run it on the images you provided us with. 
> I'm hoping
> that processing the data from one image instead of 2 will prevent it from 
> crashing.

Sounds like a plan!

> I'll
> let you know what I run into, if it keeps crashing we may need some help in 
> obtaining
> these station pixel values.

OK.  Just let me know if you want me to create the list of station-depended 
differences using McIDAS-X.  I would need to write a shell script, but this 
be easy enough given that the processing is simple.  The question will be how 
want the output to look.

> Thanks!!

No worries.


I would appreciate it if you let me know what your conclusions are... you have
piqued my interest :-)


Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
Unidata HomePage                       http://www.unidata.ucar.edu

Ticket Details
Ticket ID: EBG-395236
Department: Support McIDAS
Priority: Normal
Status: Closed

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.