STEPPropagator: Try to avoid converting magnetic fileld values from double to float and then back to double

The magnetic field returns double. There should be no reason to convert to float and the back implicitly to double when we do math operations with other double variables or constants.

Actually, we should be losing a bit in accuracy and a bit of time converting from one to the other.

Curious to see if something changes in the CI outputs prb like this is a bit more numerically stable ...

Mentioning @goblirsc and @npetters

WARNING: big files (>100K) are found in the changeset

124K in file Tracking/TrkExtrapolation/TrkExSTEP_Propagator/src/STEP_Propagator.cxx

This merge request affects 1 package:

• Tracking/TrkExtrapolation/TrkExSTEP_Propagator

This merge request affects 2 files:

• Tracking/TrkExtrapolation/TrkExSTEP_Propagator/TrkExSTEP_Propagator/STEP_Propagator.h
• Tracking/TrkExtrapolation/TrkExSTEP_Propagator/src/STEP_Propagator.cxx

Adding @amorley ,@gavrilen as watchers

added Tracking master review-pending-level-1 labels

changed the description

CI Result FAILURE (hash 21bd46fa)

	Athena	AthSimulation	AthGeneration	AnalysisBase
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
AthGeneration: number of compilation errors 0, warnings 0
AnalysisBase: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 25094]

OK this is a bit interesting so let me mention @nkoehler and @emoyse .

If you look the changes (remove the whitespace ones ...) this really changes converting from double to float (mag field is double , array are double) and then back from float to double (as math are done with double...). And changes the muon output. Even if we do not want to merge perhaps another kind of point where are reconstruction is quite sensitive .

I would assume using the double is more stable in the other hand do not know if we want to change things now , so no hard feelings...

by accident or "success" also , the 2 lines changing in q431 are the same when one moves from IPatFitter to chi2 (another MR ) . This is not prb directly related to threading issues (as is the purpose on that MR) but prb something is not also very stable numerically.

Hi @christos - this is very interesting! I agree that it suggests that the muon is more stable after the change.

changed the description

added 1 commit

• 478de389 - STEP_Propagator avoid double -> float -> double conversions for mag field .update references

Compare with previous version

WARNING: big files (>100K) are found in the changeset

124K in file Tracking/TrkExtrapolation/TrkExSTEP_Propagator/src/STEP_Propagator.cxx

This merge request affects 3 packages:

• Tools/PROCTools
• Tracking/TrkExtrapolation/TrkExSTEP_Propagator
• Trigger/TrigValidation/TrigAnalysisTest

Affected files list will not be printed in this case

Adding @okumura ,@amorley ,@amete ,@gavrilen ,@jpanduro as watchers

added Tools Trigger changes-trigger-counts labels

CI Result SUCCESS (hash 478de389)

	Athena	AthSimulation	AthGeneration	AnalysisBase
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
AthGeneration: number of compilation errors 0, warnings 0
AnalysisBase: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 25108]

added review-approved label and removed review-pending-level-1 label

MR looks fine. Approving (L1)

merged

mentioned in commit 4391a01d

added sweep:ignore label