I think I may have got to the bottom of this...
Our statement that makecube has never assumed 16 detectors is true,
but prior to 3/12/09 makecube had a built in assumption that the group
of input files was internally consistent. That is, all input files
contained data for the same set of detectors, whatever that set may
be.
So if you run just the 12-detector data through makecube you would get
a decent map, and if you ran just the 16 detector data through
makecube you also would get a decent map. But if you process both 12
and 16 detector data together in a single invocation of makecube, the
output cube is bad.
This is caused by the fact that, pre-3/12/09, makecube calculated the
input pixel->focal plane position transformation for the first input
file, and then cached this transformation for use with all later input
files. After 3/12/09, makecube re-calculates the transformation each
time a new input file is encountered.
A further twist is that all this only applies if you over-ride the
default value for parameter USEDETPOS, as Jane was doing. The default
value of TRUE for USEDETPOS results in a different scheme being used
to calculate the transformation, which was not affected by this
caching problem. The problem seen by Jane disappears - even when using
the lehuakona release - if you retain the default value for USEDETPOS.
David
2009/5/12 David Berry <[log in to unmask]>:
> 2009/5/12 tim.jenness <[log in to unmask]>:
>> On May 12, 2009, at 4:17 AM, Jane Buckle wrote:
>>
>>> Hi David,
>>>
>>> I've tried it again without using mfittrend. Obviously there is more
>>> striping in both cubes, since baselines are not removed at any stage, but
>>> the version with makecube on all the files (pictureA) still has the
>>> checkerboard structure where emission is strong, while the
>>> makecube+wcsmosaic version (picture B) does not. So, the cause of this is
>>> not mfittrend.
>>>
>>> What is the problem that I see in the reduced data? It looks to me like
>>> makecube is not spatially gridding the data correctly if it is supplied with
>>> files that have different numbers of pixels along the spectral axis.
>>
>> by default the spectral extent in the output cube will be the intersection
>> of all the overlaps and not the union (see the SPECUNION and BADMASK
>> parameters).
>>
>>> The other change that has been made between the two dates this data was
>>> taken is that HARP receptors that have been turned off are no longer written
>>> to the file. So, one set of raw data has 12 receptors, while the other set
>>> has 16. Could this be causing a problem?
>>>
>>
>> MAKECUBE has never cared about the number of receptors.
>>
>>> Are you able to run the files through the released version of the software
>>> to try and find out?
>>
>> we can get hold of lehuakona and use it. From the sound of it David has
>> already tried.
>
> Yep. Lehuakona failed for me in the same way Jane describes. Just
> before close of play today, I started to do a git bisect to pin down
> the revision at which the problem disappeared. I had a look through
> all the smurf changes that I have introduced since last October, and I
> only found one (61acbe78525cce8d553d69a4f20fb3a259becbb6) that seemed
> like a likely culprit - if that's the right word. But when I tried
> going back to the version just before, there was still no sign of the
> problem Jane describes. Which is why I'm trying a git bisect.
>
> David
>
>
>>> Do I need to stop reducing any data obtained on the GBS survey to date
>>> until the new starlink software collection is released?
>>>
>>
>>
>> I thought that MRAO were going to rsync the JAC version (as discussed back
>> on March 25th in a conversation with Dave T)? That's got fully up-to-date
>> versions of starlink and oracdr ready for testing at any time.
>>
>> If any one else is interested you can use:
>>
>> $ rsync starlink.jach.hawaii.edu::
>>
>> starlink.i386 Starlink software for i386 (32 bit) systems
>> starlink.x86_64 Starlink software for x86_64 (64 bit) systems
>>
>> so for example something like
>>
>> $ rsync -avz --delete --exclude=local
>> starlink.jach.hawaii.edu::starlink.x86_64/ star/
>>
>> should get all the JAC 64-bit system (including starjava).
>>
>> With the caveats that
>>
>> 0. You have to be running a linux that is compatible with CentOS5 (RHEL5).
>>
>> 1. This is bleading edge so I can't guarantee not to have broken something
>> for any given rsync. If something is broken try again a little later and if
>> breakage continues let us know.
>>
>> 2. the 32-bit version is not kept as up-to-date since it is not a version
>> that we use at JAC very much. In particular oracdr may not run reliably as I
>> don't always instantly update the perl distribution.
>>
>> --
>> Tim Jenness
>>
>
|
