JLBLine
commented
2 months ago In the end, edited run_hyperbeam_cuda to be able to run in both cases. User now has to supply the num_ants variable, which means you can run everything with same primary beam for all antennas if num_ants=1. All old tests were updated, and new test test_run_hyperbeam_multi_antennas.c checks it works for a different primary beam for each antenna. Everything changed in 15337e2e3ea18f19c2d974a212f1e73734406871
I think we can make a single function that works for however many antennas there are.
run_hyperbeam_cudacallskern_map_hyperbeam_gains, which has the number of tiles as the second dimension in the block/grid. So if we make the a single dimension when all the beams are the same, it shouldn't incur any more calculations. Will need to slightly update existing tests as we'll have to have number of antennas as an input. Need to make sure the outputs are ordered slowest changing to fastest changing as antenna,time,freq,component. This means when using the same primary beam for everything, weTesting:
/cmake_testing/CUDA_code/primary_beam_cuda/test_run_hyperbeam_multi_antennas.c. Make a 5 tile array layout. Have the X dipole amplitudes be 0.1, 0.2, 0.3, 0.4, 0.5 and the Y dipole amplitudes be 0.6, 0.7, 0.8, 0.9, 1.0. Run a single zenith point source for a zenith pointing; should just get back the amplitude we expect. Feed it intohyperbeamand check that the outputs come out as expected. Along with this test, also run multiple directions the sky for multiple frequencies, dump outputs and plot them as a sanity check. If time allows, chuck in a few asserts on some values to ensure future development doesn't break anything. This plotting should allow testing that the beam gain outputs are ordered by antenna,time,freq,component.cmake_testing/CUDA_code/primary_beam_cuda/test_run_hyperbeam.cto specify we only have one antenna. Nothing else should change in that test, so we can ensure we have broken anything.