Closed JLBLine closed 1 week ago
I think it makes sense actually to have do_QUV
set inside each components_t
; that way we have some kind of granularity around doing full pol vs doing just stokes I, depending on what is inside that particular chunk of the sky model
Really should be setting up some tests that check for incorrect sky model formatting, e.g. missing V_MOD_TYPE
and LIN_MOD_TYPE
columns. At a minimum, should have some warnings spat out if multiple model types are present and we end up assuming a type.
If we're being REALLY smart, we should come up with a way to not calculate Stokes I when a source doesn't have Stokes I (e.g. it's just doing a linear polarised power law or something like that). It's a whole kernel call we can avoid. BUT need to think hard about how that source would get chunk, as things get ordered by the Stokes I flux model type. Might have to just assign Stokes I 'pl' to them all, chunk 'em as normal, then adjust the "num_power" numbers after the fact? Needs more thought that
Done in 061260f
While reading in things, register whether we need to calculate
QU
and/orV
. Currently we have ado_QUV
switch inside the GPU code, so will need to revisit that and see if it's enough. But at the very least, setdo_QUV=1
inwoden_settings
if we have any polarisation info in the sky model.IF we want to be efficient, we should really only be setting
do_QUV
for visibilities that have full pol asapply_beam_gains_stokesIQUV
is far more expensive thanapply_beam_gains_stokesI
. But it'll take a decent bit of work to get that indexing correctTesting need to update
cmake_testing/wodenpy/skymodel/test_read_FITS_skymodel_chunk.py
to check all these news values are read in, and updatecmake_testing/wodenpy/skymodel/common_skymodel_test.py
andcmake_testing/wodenpy/skymodel/read_skymodel_common.py
with new polarisation options. Should probably write a new testtest_read_yaml_radec_count_components.py
as we don't explicitly test that at the moment (it's tested withintest_read_FITS_skymodel_chunk.py
)