uvw troubles?

[IanHeywood]

I'm trying to subtract an off-axis troublemaker by predicting its components into a MS column using crystalball.

I made a dirty image of the resulting model column and the source ends up diametrically opposite from where it should be with respect to the phase centre, and seems to have w-errors. I imaged with wsclean, so I'm not sure I can even turn off w-corrections.

Maybe the --invert-uvw switch will fix the rotation? It wasn't clear to me whether I should enable this routinely.

I'm also running this from the stimela codex-africanus container, so perhaps that's just out of date...

Do you have any thoughts on what I might be doing wrong here?

Thanks.

[sjperkins]

The UVW inversion is needed if you want to correspond to the CASA/MeqTrees/(wsclean?) convention regarding the sign of the exponential [e^(2*pi*1*...].

By contrast, the standard interferometry maths specifies [e^(-2*pi*1j*...]. @landmanbester and I decided to go with that in codex.

[sjperkins]

It might be better to replace invert-uvw with uvw-convention which has two choices, ['casa', 'white-book']

[o-smirnov]

By contrast, the standard interferometry maths

"Standard" in what sense? If CASA, MeqTrees and wsclean assumes the opposite, then that's a good chunk of modern userspace right there -- which makes anything else counter-standard by sheer weight of numbers.

I went through a similar thought process with the factor of 2 in the brightness matrix. Mathematical purity suggests XX=(I+Q)/2, which is what we initially did in MeqTrees. Conventional usage is XX=I+Q. Being pure & proud ended up causing too much pain to the end user, so I gave up and went over to XX=I+Q and rewrote the math to accommodate (in RIME1). I would say there's even less reason to cling on to a "pure" sign than there was onto a "pure" factor of 1/2.

So yeah I support --uvw-convention, with the default being CASA/MeqTrees compatible.

[IanHeywood]

OK this makes sense, I'll enable --invert-uvw and re-run.

However I agree with Oleg here, enabling this by default and renaming it seems like the best move. I think that if basically every piece of software you encounter adopts a convention then it becomes a question of etiquette as to whether you should strictly adhere to a textbook definition or do what everyone else is doing (something I utterly failed to convince the ASKAPsoft folks on regarding Stokes I).

Thanks everyone.

[sjperkins]

"Standard" in what sense? If CASA, MeqTrees and wsclean assumes the opposite, then that's a good chunk of modern userspace right there -- which makes anything else counter-standard by sheer weight of numbers.

By standard, I mean Interferometry and Synthesis in Radio Astronomy (3rd Edition), Equation 3.2 or 3.7.

Quibbling aside, as long as we name things appropriately and the convention is appropriately defaulted in the application, then 99.9995% of users won't need to care. :-)

[IanHeywood]

The source is where it should be with --invert-uvw enabled.

[paoloserra]

Excellent, thanks @IanHeywood . We should try to give some guidance to users on this.

[sjperkins]

I've inverted the default sign convention in crystallball in PR #20

[paoloserra]

I think that as far as crystalball is concerned this is resolved. Please re-open if I'm mistaken.