Rotational symmetry tests

No rotational symmetry tests

As mentioned in https://github.com/UCL/STIR/issues/999#issuecomment-1050071059, there are no rotational symmetry tests run right now because the two implemented scanner configurations have non-zero intrinsic_azimuthal_tilt (related to #181), which disables these symmetries for all tests (even though they are enabled in the tests).

Adding an additional test scanner with 0 intrinsic_azimuthal_tilt

During development of https://github.com/UCL/STIR/pull/1001 I tried adding a new scanner geometry with 0 intrinisic tilt:

      {
        cerr << "Testing scanner with no-tilt\n";
        shared_ptr<Scanner> scanner_sptr(new Scanner(Scanner::Advance));
        proj_data_info_sptr.reset(ProjDataInfo::ProjDataInfoCTI(scanner_sptr,
                /*span=*/2,
                /*max_delta=*/3,
                /*num_views=*/scanner_sptr->get_max_num_views(), // Cannot use view mashing
                /*num_tang_poss=*/5,
                /*arc_corrected*/false));

        check(proj_data_info_sptr->get_scanner_ptr()->get_intrinsic_azimuthal_tilt() < 0.01,
              "Tilt present in the 0 intrinsic_azimuthal_tilt test");
        run_tests_for_1_projdata(proj_data_info_sptr);

      }

This is a scanner with 336 views. This resulted in the following errors. These errors only occured at 112 and 280 views when rotational symmetry was applied.

Error. comparing lors
Current bin: 	segment = 1, 	axial pos 29, 	view = 280, 	tangential_pos_num = 0
Symm bin: 	segment = 1, 	axial pos 29, 	view = 280, 	tangential_pos_num = 0

No Symmetries Iterator || Symmetries Iterator 
                       ||   {61, 3, 2}:0.520858
                       ||   {62, -3, -2}:0.520858
                       ||   {62, 3, 2}:0.520858
                       ||   {63, -3, -2}:0.520858

There are additional coordinates/elements in the in the ProjMatrixElemsForOneBin that used symmetries than the ProjMatrixElemsForOneBin that didn't. In summary, there are small discrepancies between projector matricies when using symmetries and not, but it is partially expected that this is a minor issue.

Investigation

These errors occured at the extemities of the LOR, see above. This is likely due to the start and end positions of the ray trace:
https://github.com/UCL/STIR/blob/77ec42303521e3a84d8053d7511d929e06003084/src/recon_buildblock/RayTraceVoxelsOnCartesianGrid.cxx#L227-L230
https://github.com/UCL/STIR/blob/77ec42303521e3a84d8053d7511d929e06003084/src/recon_buildblock/RayTraceVoxelsOnCartesianGrid.cxx#L158-L162

The suggestion was to set float a = 0; and

const float xmax = stop_point.x();
const float ymax =  stop_point.y();
const float zmax =  stop_point.z();

but we found that this can still introduce issues with the values assigned to the end voxels when symmetries are applied. There is no obvious solution to this issue right now.

Start with src/recon_test/test_DataSymmetriesForBins_PET_CartesianGrid.cxx, especially the scanner configurations and run_tests_for_1_projdata, then reproduce the failures at 112 and 280 views. Read the referenced sections of src/recon_buildblock/RayTraceVoxelsOnCartesianGrid.cxx to investigate endpoint handling. Done means rotational symmetry tests with zero intrinsic azimuthal tilt no longer produce projector-matrix discrepancies, or the remaining behavior is covered by an agreed test expectation.