EXPERIMENTAL: Add a crosshand phase solver which expolits the zero Stokes V assumption.

[JSKenyon]

@landmanbester I believe this is a working prototype of the solver component of zero Stokes V approach. It is by no means complete, and I have not yet tested it in a chain.

There is still a fair amount of additional work to be done, including:

• Include an explicit parallactic angle Jones term. This is required for this specific case as its inverse needs to be applied to the data on the fly inside the solver.
• Make it possible for users to add pi radians to the output phases/specify the expected sign of Stokes U. There is an ambiguity in the results as both visibility = [1, 1, 1, 1] and visibility = [1, -1, -1, 1] correspond to zero Stokes V i.e. there are two valid solutions for the crosshand phase.
• Fix residual computations as the residual will be somewhat meaningless for a term which doesn't actually have a model. A more useful metric would be the residual Stokes V.
• (Possibly) Add a mechanism for identifying circular feeds and doing an on the fly conversion to linear feeds so that the zero Stokes V assumption can be used regardless of the actual feed type. See http://www.aips.nrao.edu/TEXT/PUBL/AIPSMEM125.PDF for the conversion matrices.
• Fix the broken tests (related to the second point above)/come up with better tests.

[landmanbester]

Awesome, thanks @JSKenyon. I should get to testing it out during the week. I will have a think about your second point above. It must be possible to infer the sign by looking at the other visibility products (maybe before and after correcting for crosshand phase)

[JSKenyon]

Ok, this PR now includes a parallactic angle term which can be be included in the chain. I have not tested this extensively but most of the code already existed so I am cautiously optimistic. Currently, I have not put in many checks and balances. Consequently, it is up to the user to disable input_model.apply_p_jones and output.apply_p_jones_inv to avoid double applying the parallactic angle. The frequency solution interval for the parallactic angle term is likely best set to 0 as the parallactic angle is not frequency dependent. Any iterations given in solver.iter_recipe for the parallactic angle term will be disregarded. This should be most of what is required to use the new solver. @landmanbester This should also give you the ability to include the parallactic angle in the net gain.

[landmanbester]

Hooray! Very cool. Thanks @JSKenyon. I have started processing the data but I haven't gotten as far as crosshand phase. I will give it a bash once I get there

[JSKenyon]

I have added a test to check that the parallactic angle Jones term functions correctly for both linear and circular feeds. I also wrote but have not included a test which includes both the parallactic angle term and the null-v solver. That also works, barring the two solution problem.

[JSKenyon]

This serves to summarise the state of this PR.

Include an explicit parallactic angle Jones term. This is required for this specific case as its inverse needs to be applied to the data on the fly inside the solver.

This has been implemented and tested.

Make it possible for users to add pi radians to the output phases/specify the expected sign of Stokes U. There is an ambiguity in the results as both visibility = [1, 1, 1, 1] and visibility = [1, -1, -1, 1] correspond to zero Stokes V i.e. there are two valid solutions for the crosshand phase.

This has not yet been added. I will omit this for the current release as further investigation is required.

Fix residual computations as the residual will be somewhat meaningless for a term which doesn't actually have a model. A more useful metric would be the residual Stokes V.

This has not yet been added but it is not critical.

(Possibly) Add a mechanism for identifying circular feeds and doing an on the fly conversion to linear feeds so that the zero Stokes V assumption can be used regardless of the actual feed type. See http://www.aips.nrao.edu/TEXT/PUBL/AIPSMEM125.PDF for the conversion matrices.

This does not work as the effect is determined by the feed type i.e. conversion doesn't make it possible to do the self consistency trick on circular feed data.

Fix the broken tests (related to the second point above)/come up with better tests.

I will mark the tests as xfail for now - the null v solver is experimental after all. The tests do work in principle, but the sign flipping makes the results inconsistent.