Closed r-pascua closed 1 year ago
Thanks @r-pascua, this is really impressive. With the timing, I suppose the killer will be the matrix product (I assume the initial 15 sec for computing coupling matrix is a one-off for the array, and that each integration uses the same coupling matrix?). Multiplying by ~8000 is only about 14 hours, which is very doable. At that point it is almost certainly not the bottleneck any more.
Base: 96.54% // Head: 96.52% // Decreases project coverage by -0.03%
:warning:
Coverage data is based on head (
ac9fed1
) compared to base (3a2c1f8
). Patch coverage: 96.71% of modified lines in pull request are covered.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Check out this pull request on
See visual diffs & provide feedback on Jupyter Notebooks.
Powered by ReviewNB
Thanks @r-pascua , this is excellent work. I would love to see a notebook demo with some plots that "show" what the tests test. If we could go through such a notebook on a validation call, I think that would be the best final review. Otherwise, the code changes look good to me.
Funnily enough, I thought I saw such a notebook in the files changed in this PR, but now I can't see it...
Thanks for the review! I do have a notebook in the works, but it was a little messy and I wasn't sure if it was necessary for this PR. I'll have it ready by next week's validation call.
This PR implements the "first order coupling" model described in Josaitis et al. 2022 via the
sigchain.MutualCoupling
class. Some additional utility functions were also added to help speed things up. This should support fully or partially (linearly) polarized data, although the implementation is a little more memory hungry than it needs to be for unpolarized data (this is a design choice I made arbitrarily—the code is much neater this way).At a high level, the procedure goes like this:
xt_vis = data @ coupling.H + coupling @ vis
This isn't currently ready to be merged; I still need to add documentation and a few unit tests. I'm a bit hesitant to try optimizing further—the only things I can really think of to improve performance require writing some wrapped C-code, or figure out how to access the BLAS/LAPACK functions that
numba
uses under the hood (assuming I actually have an idea of hownumba
works...). Here are some specs for timing tests I did for a H4C-sized file with NRAO resources, using 8 cores (I don't think I had any other processes running, but I'm not sure if anything else was running on the same node at the time I ran the tests).First, the data parameters:
Now for the various steps:
Will add some plots at a later date, but preliminary simulated visibilities look good.