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

UVData.write_ms(...reflect_conj: bool) reflect MS #1430

Open
radonnachie opened this issue Apr 17, 2024 · 3 comments
Open

UVData.write_ms(...reflect_conj: bool) reflect MS #1430

radonnachie opened this issue Apr 17, 2024 · 3 comments
Labels

Comments

@radonnachie
Copy link
Contributor

I've produced UVH5 files, the MS of which results in reflected images in CASA.
The fix was to reproduce the UVH5 file with a negation in the uvw_array (flipping the baseline direction).
This breaks the file's self-consistency regarding baseline convention, and pyuvdata complains about the mismatch: The uvw_array does not match the expected values given the antenna positions. The largest discrepancy is 16996.07144383784 meters.

I'd like to not produce inconsistent UVH5 files and thus uphold the convention standard of the file.
The issue is more squarely on CASA's side of my operation after all, not the UVH5 file.

The proposal is to provide a different flag when writing the MS, one that does not negate the uvw_array AND conjugate the visdata, but either or, producing a reflected MS.

I broach this first as an issue to verify it's validity. Will happily open the appropriate PR at positive response.

@kartographer
Copy link
Contributor

@radonnachie -- thank you for the report, can I ask if you've looked at all as to whether or not the visibility data are conjugated in the expected/correct way? Nominally the uvw-convention (ant1 - ant2 versus ant2 - ant1) is linked to the conjugation scheme of the data, and the above would suggest a mismatch between that convention and the uvws being calculated.

@radonnachie
Copy link
Contributor Author

Ah, I did omit that piece of info: I double checked my code to ensure consistency (uvw is ant2-ant1 and ant2 is conj, and further that the index order is consistent between ant_?_array and the correlation) in the convention and don't see an issue.

Is there a visual inspection of the values that I would be able to perform 🤔 the auto-correlations are all real but that isn't very telling... I'm leaning on warnings from pyuvdata to infer correctness and convention consistency, as I implied above.

@kartographer
Copy link
Contributor

There's not a super easy check to do aside from the imaging check you've already done, which does confirm that somewhere a conjugation flip is happening, and that either the uvw_array values need to be negated or data_array needs to be complex-conjugated. I did look through the code, and there's nothing obvious that looks off, though without knowing more about some instrument-specific details, it's difficult to tell if everything is "right" (since there's lots of places where a conjugation can sneak in along a signal chain). But from what you've reported thus far, it may actually be that you've got an internal consistency issue with the data itself, rather than a convention with a particular file format. If one wanted to be aligned to the convention that pyuvdata uses of ant2-ant1 versus ant1-ant2), then the visibilities would need need to be complex conjugated prior to be written to disk.

On a related note, we do actually have some code that looks for the convention flip and attempts to automatically fix it -- it was introduced because of the mixed convention that CASA uses (documented one way, but supports ALMA another way...), which looks at the values in uvw_array and if it sees that the negated version agrees well with what is expected, will automatically do this flip under the hood. That you're seeing the error would suggest that the uvw-values are not quite matching what is expected which may be worth investigating further. Happy to help with this if you're looking for a hand, and can communicate more about this offline.

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

No branches or pull requests

3 participants