[daip] Limited number of visibilities in AIPS ?

Arnaud Collioud Arnaud.Collioud at obs.u-bordeaux1.fr
Wed Jun 8 18:14:14 EDT 2011


Hi Eric,

I ran again MK4IN without the scan which aborted the task before, and it ran successfully. So finally, it was pure coincidence! This scan data must be corrupted...Sorry for bothering with that!
(At the end, I got almost 10 million visibilities.)

Thanks for your time and help! It is really good to have AIPS experts as efficient as you are.
Best regards,

Arnaud

Le 8 juin 2011 à 17:26, Eric Greisen a écrit :

> Arnaud Collioud wrote:
>> 
>> The IYA09 session is like a normal IVS RDV session, excepted the number of participating stations.  This means I have:
>> * 1 polarisation (RR)
>> * 4 IFs at X-Band, 4 IFs at S-Band
>> * 16 spectra channels per IF (<-- I am not about this point)
>> * I am compressing the data (DOUVCOMP=1)
> 
> 4 bytes * (8 IFs * 16 channels + 10 random parameters) * 6000000 is about 3 * 2^30 or more bytes than can be counted in a 32-bit integer.
> 
> That said, MK4IN does not occur in our distributed AIPS.  The closest we have is MK3IN.  The AIPS routines that handle file sizes (.e.g. ZCREAT, ZEXPND) take an argument in kilobytes giving us 2^41 -1 bytes for file sizes.  So far we are okay.  I notice in MK3IN there are a number of places that use the variable FILSIZ as the size of the file in visibility records.  However, that variable is used to call ZEXIST which returns the size in kilobytes and then
>     filsiz = (filsiz * 256.0D0) / lrec
> This depends on the compiler allowing the promotion of filsiz*256.d0 to double precision.  Our Intel optimizer would probably revert this to integer and so get the wrong answer!  I do not know where MK4IN that you are using came from or what compiler was used.  The subroutine MK3XPN is used in MK3IN to expand the file and that may be where things are going wrong.
> 
> I'm sorry but I cannot help further with the old version and unknown task.
> 
> Eric Greisen
> 





More information about the Daip mailing list