This is likely still a bug. The class that would do this is PolynomialTransferMap in it's Transport() function. I took out the V-V_{ref} because it didn't seem to be transporting V properly. The other relevant code is in PolynomialOpticsModel::CalculateTransferMap() where the maps are generated. The input and output vectors that are used to fit the polynomial are not relative to the reference trajectory. It sounds like I should have adjusted this code instead of removing the code in the Transport function.

Well, think about it carefully. I have to confess, given you are having trouble with time recon I would at least look at this code carefully...

I recently finished a mapper that creates residuals between virtual detector hits (MC truth) and "hits" produced by transporting the primary to the virtual detector locations using the polynomial maps. I ran some tests on two geometries: 1) a 7.8 meter drift with virtual detectors instead of TOF detectors, and 2) the same as #1 except with three quads right before the TOF1 virtual detector (where the quads would be in step 4).

I first generated residuals using absolute phase space vectors. I then modified the code to calculate the polynomial maps using phase space vectors relative to the reference particle and transport the vectors again relative to the reference particle.

I observed no significant difference between the absolute and relative versions of the code for both geometries, with all but the transverse momenta residual RMS being identical. The transverse momenta experienced a 10% drop between absolute and relative at TOF0, but those residuals are on the order 1e-7 (i.e essentially zero).