Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reverse order of Stokes/freq axes in im.wsclean #41

Open
o-smirnov opened this issue May 29, 2015 · 13 comments
Open

reverse order of Stokes/freq axes in im.wsclean #41

o-smirnov opened this issue May 29, 2015 · 13 comments
Assignees

Comments

@o-smirnov
Copy link
Contributor

im.wsclean currently assembles the cubes as RA,DEC,FREQ,STOKES. lwimager and CASA produce tham as RA,DEC,STOKES,FREQ.

It would be useful to make im.wsclean follow the CASA ordering, since it simplifies e.g. image arithmetic in Tigger.

@SpheMakh
Copy link
Contributor

SpheMakh commented Jun 2, 2015

This is something that is always a pain to deal with. But the culprit is not wsclean, its lwimager and MeqTrees (uv-brick). CASA, wsclean and most packages I've used follow the convention RA,DEC,FREQ,STOKES.

Which convention should we use when making images in pyxis?

@o-smirnov
Copy link
Contributor Author

Ah really? Now that I hadn't realized... lt me think about that...

On Tue, Jun 2, 2015 at 2:05 PM, Sphesihle Makhathini <
[email protected]> wrote:

This is something that is always a pain to deal with. But the culprit is
not wsclean, its lwimager and MeqTrees (uv-brick). CASA, wsclean and most
packages I've used follow the convention RA,DEC,FREQ,STOKES.

Which convention should we use when making images in pyxis?


Reply to this email directly or view it on GitHub
#41 (comment).

@IanHeywood
Copy link

Hold up because it gets worse, and CASA isn't even internally consistent. FITS images produced by CASA's exportfits task are RA,DEC,FREQ,STOKES but the CASA format images that the imager creates are RA,DEC,STOKES,FREQ.

The best course of action is probably to assume nothing and read the ordering from the image header each time.

@o-smirnov
Copy link
Contributor Author

Yeah but here the question is, if Sphe is forming up those FITS files in a
script anyway, what ordering must he use?

On Tue, Jun 2, 2015 at 2:31 PM, IanHeywood [email protected] wrote:

Hold up because it gets worse, and CASA isn't even internally consistent.
FITS images produced by CASA's exportfits task are RA,DEC,FREQ,STOKES but
the CASA format images that the imager creates are RA,DEC,STOKES,FREQ.

The best course of action is probably to assume nothing and read the
ordering from the image header each time.


Reply to this email directly or view it on GitHub
#41 (comment).

@SpheMakh
Copy link
Contributor

SpheMakh commented Jun 2, 2015

As we say in isZulu, "Insumansumane le".
I assumed that CASA was at least self consistent; I thought the exportfits convention was the CASA convention.

@o-smirnov
Copy link
Contributor Author

Is that translated as "if a man unwisely uses CASA, he deserves the shit he
gets"?

On Tue, Jun 2, 2015 at 3:17 PM, Sphesihle Makhathini <
[email protected]> wrote:

As we say in isZulu, "Insumansumane le".
I assumed that CASA was at least self consistent; I thought the exportfits
convention was the CASA convention.


Reply to this email directly or view it on GitHub
#41 (comment).

@SpheMakh
Copy link
Contributor

SpheMakh commented Jun 2, 2015

he he he, that is quite close though. Its translated as "A situation which is beyond comprehension"

@IanHeywood
Copy link

I've always held RA,DEC,FREQ,STOKES to be the proper order because that's the way AIPS does it, and also that's ordering the axes in descending order of how often astronomers care about them (RA and DEC occupying the joint first position).

@o-smirnov
Copy link
Contributor Author

Well I find that very hurtful, as I care very deeply about the Stokes axis!
If only because it fucks me over so often -- I guess it's Stockholm
syndrome.

Anyway, I guess the only solution is to create a little tool to reorder
axes in a FITS file. fitstool.py in Owlcat is a logical recipient for
this functionality...

On Wed, Jun 3, 2015 at 12:39 AM, IanHeywood [email protected]
wrote:

I've always held RA,DEC,FREQ,STOKES to be the proper order because that's
the way AIPS does it, and also that's ordering the axes in descending order
of how often astronomers care about them (RA and DEC occupying the joint
first position).


Reply to this email directly or view it on GitHub
#41 (comment).

@SpheMakh
Copy link
Contributor

SpheMakh commented Jun 3, 2015

I've written a function that does this ( im.argo.swap_stokes_freq). But maybe this is the time to move this function as well as other FITS file related functions to fitstool.py.

@SpheMakh
Copy link
Contributor

SpheMakh commented Jun 3, 2015

In fact they are couple of functions in im.argo that really ought to be moved elsewhere, like the addcol function should really be in ms. Its time to clean up after younger me. I'll create a branch for this, and hopefully be done in a few days.

@IanHeywood
Copy link

"You may not be interested in the polarization, but the polarization is interested in you."

Also:

"if a man unwisely uses CASA, he deserves the shit he gets"

Sphe, can you translate this please? I'm going to get a t-shirt made.

@SpheMakh
Copy link
Contributor

SpheMakh commented Jun 4, 2015

@IanHeywood give me a few days to come figure out the correct phrasing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants