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
>
|