Hi,
re:
> Just touching base again
> Is there any news on update for v2021 HRIT changes?
Yes, but the issue at hand turned out to be more involved than a simple
update of the ADDE server code could fix.
I just sent a note of to the UWisc/SSEC folks outline the problems that
I found and asking which of two approaches they would like followed to
rectify the problems. Aside: one of my primary objectives is to create
code that will be incorporated into the core of McIDAS that SSEC maintains.
So, I am not in a bit of a waiting mode until I hear back from SSEC...
In case you are interested, here is what I just sent to the SSEC
folks:
"I have updated WARC server code that handles the Himawari HRIT images
that are available from JMA (and are presumably the same as are being
distributed in HimawariCAST) and the Himawari HRIT images that are
being distributed in EUMETCAST. In addition, the code now handles the
so called HIRES band 7 Himawari HRIT images that JMA makes available.
That's the good news!
The bad news is that the approach that the WARC server uses for doing
calibration requires that the calibration block be LARGE. What I
mean by LARGE is that the size of the calibration block will need to
be
16*16384+36 4-byte integers
because the code creates the lookup tables used to calibrate the
images, and the HIRES band 7 from JMA and regular band 7 from
EUMETCAST, and these images use 14 bits to define their raw values
while the rest of the images use 10 bits.
After spending multiple days trying to figure out why the code that
I had updated was not working, I finally decided to check to see
if code outside of the WARC server was placing a limit on the maximum
size that a calibration block can have. I first looked in imgdisp.pgm
and that led me to examine mcaget.for where I found:
mcaget.for: approx. line 88:
INTEGER MAXCALSIZ ! max word size of cal block
PARAMETER (MAXCALSIZ = 20000)
Not being satisfied with this being the only place that the maximum
size of the calibration block might be set, I did a grep for
MAXCALSIZ in all Fortran modules, and I found another, different
definition for the maximum calibration size:
areaagetsub.for: approx. line 48:
INTEGER MAXCALSIZ ! max word size of cal block
PARAMETER (MAXCALSIZ = 10000)
Comment(s):
- the different settings for MAXCALSIZ in mcaget.for and areaagetsub.for
strike me as being a problem that must be addressed
- it strikes me that setting a value like MAXCALSIZ should be done in
an include file, not in individual routines
For instance, why is this value not defined in areaparm.inc?
To my mind, there are two approaches that can be taken to eliminate the
problem I have been fighting:
- increase the definition of MAXCALSIZ everywhere that it is specified
There may be other places where it is either explicitly or implicitly
defined, and those will need changing also.
NB: this approach might have unforeseen/unintended consequences
for other routines.
- rewrite the way that the WARC AGET server creates a calibration block
and then modify the WARC calibration module, kbxwarc.dlm, to work with
the revised approach
The question for you all is which approach should be taken?"
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: CXH-788694
Department: Support McIDAS
Priority: Normal
Status: Open
===================
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.
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.