On Fri, 1 Jun 2012, Tim Jenness wrote:
> In general, some of those ints look like they could be INT_BIGs
> (anything that looks like a counter).
Yes, I was also surprised to see that strides where HDS_PTYPE, a simple
int. In retrospect we should have used unsigned longs for much of HDS.
> On Fri, Jun 1, 2012 at 10:30 AM, Peter W. Draper
> <[log in to unmask]> wrote:
>> I've been running KAPPA:compave on some large images (2.4Gb) and it was
>> failing with the following error:
>> !! Requested data extends beyond the end of the record; record length is
>> ! 2407034800 bytes (possible corrupt HDS container file
>> ! GAMA/data/VST/ATLAS_r_v1/stacks/o20110823_00072_st.
>> ! ..
>> ! DAT_MAP: Error mapping an HDS primitive: 'DATA'
>> ! ARY_MAP: Error obtaining mapped access to an array.
>> ! NDF_MAP: Error obtaining mapped access to an array component of an NDF.
>> ! COMPAVE: Unable to compress an NDF by averaging neighbouring values.
>> ! Application exit status DAT__INCHK, Integrity check
>> ! in=o20110823_00072_st_exp_mos
>> After a bit of looking I've tracked this down to a problem with mixed
>> integer arithmetic in the the HDS routine dauscatgath.c (the slicing going
>> wrong was caused by an NDF section trimmed to some slightly smaller
>> dimensions than the full image, so I'm sure this problem has been affecting
>> other programs as well). Note I've also changed the similar looking code
>> sections in this file, but they are not tested, so beware... Clearly it
>> raises the question of if there are other mixed arithmetic issue lurking as
Peter W. Draper, http://astro.dur.ac.uk/~pdraper