- Jun 27, 2024
-
-
Karol Krizka authored
-
- Jun 26, 2024
-
-
Karol Krizka authored
-
- Sep 23, 2021
-
-
Karol Krizka authored
-
- Sep 21, 2021
-
-
Paul Gessinger authored
-
Paul Gessinger authored
-
- Sep 20, 2021
-
-
Xiaocong Ai authored
The reason for #961 is that the reset of navigation state with a target surface (i.e. a perigee surface at the beam line) in CKF will confuse the navigator. For example, when the navigation state is reset to vol=13|lay=8|sen=1028, the Target volume estimated : might be exactly the same as the start volume if a target surface is set. This will result in Re-initialzing cancelled as it is the first step and the navigator will not proceed to find the boundary surfaces. Therefore, a nullptr targetSurface is passed to the navigator during reset. The detailed logs with and without the fix can be found below.
-
Xiaocong Ai authored
The reason for #984 is that after #956, a track might have non-zero processedStates, but zero measurementStates. So we return a failure explicity in KF if measurementStates is zero.
-
- Sep 18, 2021
-
-
Andreas Salzburger authored
-
- Sep 16, 2021
-
-
niermann999 authored
* Basic json config for tgeodetector and cylinder/disk splitter (#884) The options handling of the TGeoDetector is moved from boost to json based configuration. It builds upon the recent reordering of the detector options in #923. New functionality is introduces in Examples/Io/Json. Since it needs information from the TGeo plugin, the latter is only linked in the example io when the plugin is required.
-
- Sep 14, 2021
-
-
Stephen Nicholas Swatman authored
This pull request is part three of four in my attempt to implement an orthogonal range search seed finder. k-d trees are datastructures which allow certain operations to be performed efficiently on point cloud data. Most commonly, these operations are (orthogonal) range search and nearest neighbour search. For my implementation, I need only the first, and as such nearest neighbour search is omitted in name of the YAGNI principle. I have implemented this class with performance and GPU-compatibility in mind, and therefore the memory is efficiently laid out wherever possible (although some improvements can still be made later). The implementation supports a more classical C++ interface where vectors of items are returned, as well as a more functional approach which employs higher-order functions to effect the required computation. This functional approach is the backbone to the classical approach as well. I believe that a k-d tree implementation is a good thing to have in Acts, since they are very versatile and I can see them being used in several other parts of the code. Again, I have added tests for the k-d tree as well, to ensure that the implementation works as intended.
-
- Sep 13, 2021
-
-
Stephen Nicholas Swatman authored
This pull request is number two in a series of four in my attempt to implement an orthogonal range search seed finder. The new class represents an axis-aligned (thereby orthogonal) hyperrectangle in a space of arbitrary dimension. This can be achieved quite elegantly by simply taking the product of a number of one-dimensional intervals. I've also included some helper methods which will be useful in the implementation of the k-d tree. As before, this commit also adds tests for this new class.
-
Stephen Nicholas Swatman authored
This merge request is part one of four in my implementation of an orthogonal range search seed finder. That implementation relies on a k-d tree, which rely on k-dimensional orthogonal intervals. A k-dimensional orthogonal interval is simply the product of k one-dimensional intervals, and as such the one-dimensional interval is the first part in the series. This new class represents the inclusive range [min, max], and has several methods for shrinking, expanding, and comparing ranges. I have attempted to make the class quite general, and the scalar type is templated.
-
- Sep 06, 2021
-
-
Andreas Salzburger authored
This PR is the second pull request for the Geant4 simulation and introduces the full simulation for single particles. It uses the same Geant4Simulation algorithm and establishes a symmetric setup between Fatras and Geant4 simulation. e.g. Fatras: ./ActsExamplesFatrasDD4hep <args> and Geant4: ./ActsExamplesGeant4DD4hep <args> Can now be run with the same argument list.
-
- Sep 03, 2021
-
-
Andreas Salzburger authored
This PR fixes an issue that the vertex and momentum direction have not been appropriately set in the reworked MaterialRecording example.
-
- Sep 02, 2021
-
-
Andreas Salzburger authored
@asalzburger Member asalzburger commented 6 days ago • edited This PR is the first of a series of PRs that will: harmonise the Geant4 examples (and running setup) enable Geant4 simulation with sensitive elements harmonise Fatras/Geant4 simulation to run with same commands streamline the single particle generation (currently done in ParticleGun, PropagationAlgorithm, Geant4 gun) This PR addresses at first the former GeantintoRecording: GeantinoRecording application is renamed to MaterialRecording the material recording is now done by the Geant4Simulation algorithm: it reads in generated particles from the ParticleGun and feeds into the new PrimaryGeneratorAction, as a consequence the specific g4-gen-* options are removed, as this is covered by the generator options now the singleton instance framework for user actions is removed in favour of the new event-wise thread-safe EventStoreRegistry the simulation dependent internal collection names are moved into Simulation/Common the common code base of MaterialMappingBase is renamed (alongside all other Examples) to CommonMaterialRecording with the MaterialInteraction and its derivatives are removed from the Propgator/MaterialInteractor.hpp into a separate file Material/MaterialInteraction.hpp to wich the former file and the other clients point to BREAKING CHANGE: Core: the MaterialInteraction and its derivatives are removed from the Propgator/MaterialInteractor.hpp into a separate file Material/MaterialInteraction.hpp to wich the former file and the other clients point to
-
Xiaocong Ai authored
This PR adds a new directory for the alignment. Currently, it includes the KF-based alignment algorithm which allows the alignment of the detector at the detector module level only. - It includes an `AlignmentEngine` which calculates the relevant derivatives for one track - The `Alignment` algorithm runs the fitting for all provided tracks and collect the derivative of the sum of chi2 w.r.t. alignment parameters. Then the alignment parameters could be updated iteratively by solving an linear equation. In addition, an example to run the detector with misalignment, i.e. the Contextual detector, is implemented with the `Examples/Run/Reconstruction/Common/RecInput.cpp(hpp)` moved to the `Examples/Run/Common`, which could allow the usage of those files by the alignment example in `Examples/Run/Alignment/` as well. Alignment for detector layers/volumes will be handled in a separate PR.
-
- Sep 01, 2021
-
-
Carlo Varni authored
Computation of shared measurements in CKF. After track reconstruction, the code runs on all reconstructed tracks and takes into account the measurements used in each track by accessing the measurement index contained in the source link. If the same measurement is used by more than one track, it is flagged as a SharedHit. The measurement will have both the Measurement and the Shared flag, so no change in measurement-related variables is expected.
-
andriish authored
Fix related to #877
-
Hadrien Benjamin Grasland authored
-
Paul Gessinger authored
-
- Aug 31, 2021
-
-
Paul Gessinger authored
With this PR, there's one action that runs on any PR that **targets** branches `releases` or `release/*`, and will make a trial run of the changelog generation and version bumping. This only works on PRs on the main repo, for permission reasons. A second action will automatically run on branches `releases` or `release/*`, generate the changelog, execute the version bump, and finally create a GitHub release with the generated changelog and version number. This release can be manually published, and when that happens, a git tag is created on the bump commit. I've tested all this over on https://github.com/paulgessinger/release-test but I don't think it's bulletproof. I'd like to run this for a bit and see if it does the job. There is the possibility for manual intervention before anything (kind of) irreversible happens, so that should be fine.
-
Andreas Salzburger authored
This PR updates the ODD to a consistent set including a git ifs governed material maps.
-
- Aug 30, 2021
-
-
Paul Gessinger authored
-
Paul Gessinger authored
-
Corentin-Allaire authored
The bin adjustment for surface used the default constructor of the geometry context to get the surface transform. This doesn't work for all context so it now uses the geometry context as an input. This also add bin adjustment for trapezoid bound (and the relevant test).
-
Corentin-Allaire authored
This PR slightly change the howto for the material mapping to take into account the fact that the ODD is now a submodule. It also fix layout issue in the howto.
-
Stephen Nicholas Swatman authored
In #941, the collision region bounds in the z axis were mistakenly defined to be in MeV where they should be in millimeters. This change doesn't negatively impact physics performance per se because it makes the collision region one thousand times larger than it should be, but it can have significant influence on the compute performance. This commit changes the unit back to millimeters, as it should be.
-
Paul Gessinger authored
This is in preparation for the python bindings
-
- Aug 27, 2021
-
-
Paul Gessinger authored
This is driven by the python binding implementation. std::function has the downside of making pybind11 do a round trip through python. This interface is equivalent, but slightly more complex. I think it's still acceptable.
-
Paul Gessinger authored
remove ODD submodule warning
-
- Aug 26, 2021
-
-
Paul Gessinger authored
-
Paul Gessinger authored
-
Paul Gessinger authored
-
Corentin-Allaire authored
Until now the default context was used in the writing to get the transform but this doesn't work for all the geometry. This PR allows the context to be used for the surface writing.
-
Paul Gessinger authored
-
- Aug 25, 2021
-
-
Paul Gessinger authored
This removes Exhale from the build, and directly uses `breathe.apidoc` to generate symbol listings. They are less fancy, but appear to be more robust.
-
Corentin-Allaire authored
This PR allow material situated before the first measurement (eg : beampipe) to be properly accounted for in the KF and CKF.
-
Paul Gessinger authored
Introduces a new `InterpolatedBFieldMap` interface, which the various templated concrete types can implement. Defines a very generic interface that allows the root b field writer to not be templated.
-
- Aug 24, 2021
-
-
Louis-Guillaume Gagnon authored
Previously I carelessly set the smearing widths equal to the pixel or strip dimensions. This is ill-advised as the resulting measurement only falls in the right pixel ~68% of the time. In this PR, smearing widths are changed to dimensions/sqrt(12). closes #946
-
Paul Gessinger authored
In #917 I introduced an output directory to `GeometryView3D`. I set the default to "." as that usually means the current directory. Due to the way we currently look for file extensions, this didn't actually work. I didn't actually test the default, so that broke the output writing. This PR works around this by checking if the default value "." is given, and replaces this with the actual `$PWD`. This is not super robust, and ideally we should revise all of this using `boost::filesystem`, which I'll try to do in a future PR. Aside from this, this PR also make the geometry examples correctly pipe through the `--output-dir` option to the geometry view output.
-