iraf.net

Hi Mike,I was wondering if you knew whether there are any flags that can be set so that when binaries are built, the BITPIX values in the pixel extension header is -32 and not -64?I have found that when I build the binaries for the gemini package on a more recent linux machine, the BITPIX value is automatically set to -64, yet building the binaries on an older linux machine sets the BITPIX value to -32. Is there a way to choose which value is actually used / force newer machines to use BITPIX=-32?Many thanks,Emma

The BITPIX value has absolutely nothing to do with how the binaries are built, it depends on how the application writes the FITS file, i.e. the application has to explicitly create a single or double-precision real image. I can't explain why you're seeing a difference. If you're using v2.14 or older you shouldn't be able to even compile on a 64-bit platform, if you're using v2.15 you can compile and if the task is looking at the size of an int on the platform to determine the BITPIX, then it's a task bug. What task is this?-Mike

Thank you for your quick reply We're not even building on a 64-bit platform(!), we're only building on 32-bit platforms, yet the BITPIX value is still being set to -64 ... there are a few tasks in the gemini package that this is occuring for (i.e., gemarith and gfcube) and I believe these require binaries to work. That's why I thought it might be related to the way the binaries are built.How would you force the application to write a FITS file with a BITPIX value of -32? Perhaps there is something in the SPP code that we should be setting?Emma

I'd say to unlearn the tasks, and if that doesn't work then reinitialize your uparm with a new MKIRAF. The only reasonable explanation is that there is a task 'outtype' param or somesuch set to double on one machine and float on another.

Unfortunately, this "feature" has come about from our testing framework ... the two machines in question are identical 32-bit RHEL5 machines and the only difference between the two machines are the gemini installations. One of the gemini installations was built on the machine itself and the other was built on our regular build machine (32-bit RHEL3). The uparm directory is initialised at the beginning of each test and the input files are the same. But the output files differ ... and only by the BITPIX keyword ... can the 'outtype' parameter or equivalent be set globally somehow?Many thanks,Emma

I used 'outtype' generically: GEMARITH is a script that calls IMARITH and IMEXPR, in IMARITH there is a 'pixtype' param to determine the output pixel type, in IMEXPR there is an 'outtype' param.Point is, some tasks have a parameter to specify the output pixel type to be produced, the names will likely vary. Since most of GEMINI is CL scripts you'll need to figure out what core tasks they call and whether they set a parameter (or should) and how. For GFCUBE it is a compiled that doesn't explicitly set the IM_PIXTYPE header value, it copies those values from the input image being mapped. Since the uparm is initialized each time it might be something like a random value be used in an unitialized structure, or a memory corruption of a properly initialized structure, or .....You'll need to figure out specifically which task is creating the file and debug it from there. We're not aware of this being a problem in the core system.