This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Daphne, re: > Thank you very much for producing these images for us! No worries. re: > I am able to display and get > values for the points in both brightness counts and the temperature > difference in K. Excellent! re: > 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. re: > 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. re: > 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! re: > 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 temperature differences using McIDAS-X. I would need to write a shell script, but this should be easy enough given that the processing is simple. The question will be how you want the output to look. re: > Thanks!! No worries. Request: I would appreciate it if you let me know what your conclusions are... you have piqued my interest :-) Cheers, Tom -- **************************************************************************** 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