Clean-up and apply hopefully workable method to efficiently evaluate contributions only from tracks near sample point.


Former-commit-id: a238ad49a96a87dc655a5d4ce589b4e639832575

Attempt to optimize so only tracks with a reasonable distance of the test point are used in the computation.


Former-commit-id: 061ed3f39614b5e3a5340889bcd52d5150a2281d

Former-commit-id: 502565ce18581a49a6d0d301d1de3572fed6137c

Former-commit-id: 6f0360ba4058e820297bf50d7ce89604f9b408e2

Former-commit-id: 8aa4bc3a4f495ccc52ebbafa004bef1922a2da18

Former-commit-id: 275b8d4e47cef05435fffbd31410b10940cf744e

As discussed in !2959, a bug in the extrapolator was in rare cases causing thousands of scatterers to be added to a track.
Thanks to Peter Kluit, we believe that we have now tracked this down to a bug in the STEP_Propagator.
The propagator was getting stuck in a volume and iterating forward in steps of 1-10 um, adding a scatterer each time.
At the time, we implemented a "fix" that simply aborted the track-finding when more than 1000 scatterers were found on a track.
Now, the underlying issue should finally be resolved.
It appears that the problem was occurring when the propagator found two solutions from the starting surface, the first of which was trivial and the second of which gave a negative distance estimate.
In this case, the propagator would automatically flip direction, bringing it back almost to the starting point, where it would add a scatterer.
Then the process would repeat thousands of times, until it got far enough away from the start position that there was no second solution, or one with a postive distance estimate.
By identifying these cases and rejecting their negative-distance second solutions, this problem is avoided.
Given the rarity of this problem, FT0 tests naturally show no violation, results are available at /afs/cern.ch/work/w/wleight/public/MuonSW/tooManyScatterers/RunTier0Tests.log


Former-commit-id: 0c1c0d3b

The previous commit to this class incorrectly used smart pointers,
specifically, their ownership was not released. Moreover, the wrapped
objects were initialised incorrectly, leading to the same
`Trk::PlaneSurface' being duplicated, filling the vector with the same
surface.

Although it appears the owning objects free memory, we play it safe by
keeping the smart pointers here, as opposed to resorting back to raw
ones.


Former-commit-id: d79f604018172cc9533a35c453d05a589554a346

This is mainly to fix ATLASSIM-3588, but there were a few other instances too.
`StreamHITS` is found in `AlgSequence("Streams")` rather than `AlgSequence()` now.
Will make a separate merge request fixing the same issue for `StreamRDO`.


Former-commit-id: 535e9d5cbc652caadf5bd5de6ced117431a47c9a

Allow test reference files to be found outside of the repository.



Former-commit-id: 1aec47c128824c7cf96bf12ce713359fc3325c8f

Vakhtang Tsulaia authored 7 years ago and Atlas Nightlybuild committed 7 years ago

TrkG4UserActions: Comply with ATLAS naming conventions.

See merge request atlas/athena!8698

(cherry picked from commit 1a0ee179 [formerly 1ced3e993ee49e66161ecbe2c8cfa9005b0f74ed])

b0da5e5a TrkG4UserActions: Comply with ATLAS naming conventions.

Former-commit-id: 372718f309739a6b5b9bd8f03997186c10629c50

Former-commit-id: eb98bfc24e40aeb24fa9423f41ec3ed94725b90f

Sascha Caron authored 7 years ago and Marcus Matthias Morgenstern committed 7 years ago

ATR-17470 list->vector migration

See merge request atlas/athena!7355

Former-commit-id: 322376aef3623dd918e9d9e818a0d97966ab3ce9

This reverts merge request !7355

Former-commit-id: 9cef92650e307d66ac86fb3df6095e634f958e2e

Former-commit-id: 54a769d5b0606af15bfc93cb1076e856607adc45

This reverts merge request !7301

Former-commit-id: f304b7ee7e5f9cc6d5e975ffcbb273d731d6d692

This reverts merge request !6822

Former-commit-id: 0b89aea1d09c6eede365029b9a549e1751f8da53

Anthony Morley authored 7 years ago and James Beacham committed 7 years ago

Former-commit-id: b3a22d9f5ec10799da263e376c4e14dc757ee084

Former-commit-id: 39b0086e3a371c950f068478857e76e62676515d

Former-commit-id: 121da896cecec0ccc8f99fe6f03fac0796eaba13

Former-commit-id: 196c3ffe631b1f5c8d4cf0b741bc081735a3a0cb

This provides a fix for ATLASRECTS-3973 by downgrading an unnecessary WARNING message to DEBUG.


Former-commit-id: 7d23eef3ad9ae601f1c1c9a1e5a75c9ed5671f40

Former-commit-id: 2b5a333df8c66f61b7e5ec6fcd94fe15e87e24c8

Former-commit-id: 821d34fc1d67a5a07060ed7f5e8ea0a5c0ca1a65

Former-commit-id: c77d0a22719605b7690171ecb33cbb2facdc72e9

Goal is to synchronise 20.20 tags with 21.0 for development.

Minor changes: memory leaks fixes, and ATLAS naming conventions
employed.


Former-commit-id: b6b041b98f052d6cf534d4654d51f14ae63e6e2f

Former-commit-id: 0550d6f4a336227c1e3f6c3c15c7df83222117c1

Simulation declareInterface migration Part2 ATLASSIM-3439

See merge request !4816


Former-commit-id: 5c565bdecb29a6dd1e22627557dfe2a6d19c2ef4

Declare interface fixes 21.3

See merge request !4814


Former-commit-id: 53299a6cc812697ab08f8b8d02b7f8c6c42b3a5a

Further fixes for ATLASRECTS-3796

See merge request !6159

Former-commit-id: f86dec45954face70c8862608b9a63288b9f31af

The original fix for missing truthParticleLinks implicitly assumed that the xAOD::TrackParticle always had an attached truthParticleLink.
In turn, the code for adding the truthParticleLink to the xAOD::TrackParticle implicitly assumed that the trackParticle always had an attached trackLink().
However, recent studies on 21.0-mc16d by Jovan seem to indicate that at least one of these assumptions is violated.
This fix should hopefully ensure that a dummy truthParticleLink is always added to the trackParticle and the Muon object no matter what.


Former-commit-id: 45a1b270a93eddf27068b5edb1fbe29ee470049b

`PyG4AtlasAlg` is now obsolete, so all usage should be removed from
job options. Also updated some other obsolete simulation syntax in
the affected job options files.


Former-commit-id: c29bd1c4

The standalone muon track fit uses the GlobalChi2Fitter (unlike the combined track fit which uses the iPatFitter).
In rare cases (and only when the GlobalChi2Fitter is used for muons) the call to obtain the list of downstream scatterers from the extrapolator gives bad results.
The extrapolator returns a list of thousands of scatterers, which is clearly wrong.
This results in the fitter trying to solve a thousands by thousands matrix, which then leads to trigger timeouts.
To avoid this behavior, a configurable setting is added to the GlobalChi2Fitter to check for the return of over 1000 scatterers and simply quit if so.
It is false by default, but set to true in the muon instance of GlobalChi2Fitter, configured in MuonRecTools.py.
The underlying cause of this problem should probably be studied by an extrapolator expert, but for now this will get rid of the timeouts.
Results of the trig tests are available at /afs/cern.ch/work/w/wleight/public/MuonSW/ATR-16605/.


Former-commit-id: ad377d31325665bc46ccce2b73702e4e31e6241a

Former-commit-id: b025d484b6d264370e5027fb19ec5a9a7fcec4ab

Replaced occurrences of `new` keyword with `std::unique_ptr` to fix
memory leaks. Commented out line defining `pitchY` to fix
`-Wunused-variable` warnings.


Former-commit-id: 8f76e46bda9fe86df2818ca498de04a81c4e4661

Made a change in the CMakeLists.txt file to correct the public header fault in CI compilation of TrkDigEvent


Former-commit-id: a3d70278

Former-commit-id: aa31a237

Former-commit-id: a97c5001

Former-commit-id: 65ea0384

updated package TrkDigEvent to latest 20.20.XVAL. Added copyright statements to all relevant source code


Former-commit-id: 5165c434