"README.md" did not exist on "8a772986ae1f2b99578f28f4b674c19e2ea4baa2"
Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
# v01-00
* 2017-06-22 Marko Petric ([PR#192](https://github.com/AIDASoft/DD4hep/pull/192))
- Move `AlignDet_Telescope_readback_xml` to later in the pipeline since it depends on the output of `AlignDet_Telescope_write_xml`
* 2017-06-22 Andre Sailer ([PR#191](https://github.com/AIDASoft/DD4hep/pull/191))
- Surface: fix memory leak of transformation matrix
- XML::Layering: fix memory leak of contained layers in the object
* 2017-06-23 Andre Sailer ([PR#197](https://github.com/AIDASoft/DD4hep/pull/197))
- Fix memory leaks for Tube, EllipticalTube and Polyhedron
* 2017-06-23 Andre Sailer ([PR#196](https://github.com/AIDASoft/DD4hep/pull/196))
- CMake: add `Project( DD4hep )`, needed to get the correct CMAKE_CXX_COMPILER_ID on macs due to CMP0025 (cmake policy)
- CMake: fix treatment of linker flags, they are now properly set for Linux and Macs to error when undefined functions are encountered at link time
- CMake: fix elif --> elseif when checking threading libraries
* 2017-06-23 Frank Gaede ([PR#195](https://github.com/AIDASoft/DD4hep/pull/195))
- fix crash in `dd4hep::rec::Surface` after changes in Handle assignment (PR #193)
- fix use of deprecated `dd4hep::rec::MaterialManager` c'tor in Surface
* 2017-06-20 Frank Gaede ([PR#185](https://github.com/AIDASoft/DD4hep/pull/185))
- bug fix in material utilities
- call `MaterialManager( Volume v)` with `Detector.world().volume()`
* 2017-06-20 Marko Petric ([PR#184](https://github.com/AIDASoft/DD4hep/pull/184))
- Reinstate the full test-suite on Travis
* 2017-06-20 Markus Frank ([PR#183](https://github.com/AIDASoft/DD4hep/pull/183))
- Unify header guards in DDCore
- Add header to steer ignoring warnings of rootcling generated dictionaries.
* 2017-06-20 Frank Gaede ([PR#182](https://github.com/AIDASoft/DD4hep/pull/182))
- cleanup of namespace `dd4hep::rec`
- remove obsolete bwd compatibility for `DD4hep::DDRec`
- re-introduce `[deprecated]` warnings for unmaintained classes in DDRec/API
- re-fix deprecated c'tor for `MaterialManager` in material utilities
* 2017-06-20 Markus Frank ([PR#181](https://github.com/AIDASoft/DD4hep/pull/181))
- Attack many warnings from:
- `-Wshadow`
- `-Winclude-hygiene`
- `-Woverlength-strings` (int cling dictionaries)
* 2017-06-20 Markus Frank ([PR#179](https://github.com/AIDASoft/DD4hep/pull/179))
- Remove a bunch of shadow warnings and include-hygiene warnings.
* 2017-06-21 Marko Petric ([PR#169](https://github.com/AIDASoft/DD4hep/pull/169))
- Make boost explicit requirement for DD4hep and drop DD4HEP_USE_BOOST
* 2017-06-21 David Blyth ([PR#168](https://github.com/AIDASoft/DD4hep/pull/168))
- Added environment helper scripts `thisdd4hep_only.(c)sh` that only set up variables for DD4hep and not for dependencies.
* 2017-06-19 Markus Frank ([PR#178](https://github.com/AIDASoft/DD4hep/pull/178))
- Update documentation after reorganization of namespaces (put back previous docs).
* 2017-06-19 Markus Frank ([PR#175](https://github.com/AIDASoft/DD4hep/pull/175))
## DD4hep namespace reorganization
Re-organize namespaces according to the decisions of the DD4hep developers meeting from 16th June we have decided:
1. all namespaces will be lower case and shorter
* rename namespace `DD4hep` -> `dd4hep`
* rename namespace `DD4hep::DDRec` -> `dd4hep::rec`
* rename namespace `DD4hep::Simulation` -> `dd4hep::sim`
* rename namespace `XML` -> `xml` and `JSON` -> `json`
* rename all other namespaces according to this pattern
2. The namespace `DD4hep::Geometry::` will be incorporated into `dd4hep::`
3. All utilities will be moved `dd4hep::detail`
4. `LCDD` will be renamed to `Detector` and current `Detector.h` will be renamed to `DetElement.h`
8. Examine if `DDSegmentation` can be incorporated into `DDCore` and make it volume aware
* If this this cannot be achieved in whole place `DDSegmentation` into the right namespace
## DDParsers
DDParsers are now a separate package. This does not make it yet standalone,
but it is at the same level as e.g. DDSeqmentation. Any librarian is
encouraged to externialize it fully.
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
# v00-24
* 2017-06-08 Markus Frank ([PR#160](https://github.com/AIDASoft/DD4hep/pull/160))
* Add a new class `AlignmentsNominalMap`, which behaves like a `ConditionsMap` and handles alignment entries.
* The `AlignmentsNominalMap` is not a conditions cache per-se. This implementation behaves like a `conditionsmap`, but it shall not return real conditions to the user, but rather return the default alignment objects (which at the basis are conditions as well) to the user. These alignments are taken from the `DetElement` in question `Alignment DetElement::nominal()`.
* The basic idea is to enable users to write code "as if" there would be conditions present. This is important to ease in the lifetime of the experiment the step from the design phase (where obviously no conditions are taken into account) to a more mature phase, where alignment studies etc. actually are part of the "bread and butter work".
* Added a corresponding example in examples/AlignDet:
```
$> geoPluginRun -volmgr -destroy -plugin DD4hep_AlignmentExample_nominal \
-input file:${DD4hep_DIR}/examples/AlignDet/compact/Telescope.xml
```
* Access the DetElement nominal conditions using the `AlignmentNominalMap`.
Any use of DDCond is inhibited.
1) We use the generic printer, which during the detector element scan accesses the conditions map.
2) We use a delta scanner to extract the nominal deltas from the `DetElement`'s nominal alignments
3) We use a `ConditionsTreeMap` to perform the alignments re-computation.
* 2017-06-08 Markus Frank ([PR#159](https://github.com/AIDASoft/DD4hep/pull/159))
# Implementation of the decisions made at the Conditions mini-workshop
## Access mechanisms of DD4hep conditions for utilities
Access to conditions is solely supported using the interface class DDCore/ConditionsMap.
* All utilities must use this interface.
* Any concrete implementation using conditions/alignment utilities must implement this interface
* Basic implementation using STL `map`, `multimap` and `unordered_map` are provided.
* A special no-op implementation of this interface shall be provided to access "default" alignment conditions. This implementation shall fall-back internally to the `DetElement::nominal()` alignment.
Known clients: `VolumeManager` (hence: DDG4, DDRec, etc.)
Though this sounds like a trivial change, the consequences concern the entire conditions
and alignment handling. This interface decouples entirely the core part of DD4hep
from the conditions cache handling and the alignment handling.
Based on this interface most utilities used to handle conditions, detectors scans
to visit `DetElement` related condition sets, alignment and conditions printers etc.
For details, please see:
```
DDCore/include/DD4hep/AlignmentsPrinter.h
DDCore/include/DD4hep/AlignmentsProcessor.h
DDCore/include/DD4hep/ConditionsPrinter.h
DDCore/include/DD4hep/ConditionsProcessor.h
DDCore/include/DD4hep/DetectorProcessor.h
```
## Naming conventions for detector conditions
* Condition are logically attached to DetElements
* Condition names are: `DetElement.path()+"#"+condition-name`
Example: `/world/LHCb/DownstreamRegion/Muon/M5/M5ASide/R3ASide/Cham046#alignment`
* Condition keys are a `int64` compound of two `int32`:
```cpp
union {
int64 key;
struct {
int32 item_key;
int32 det_key; // Needs to be the high word to have a properly ordered map
} values;
};
det_key = hash32(DetElement.path())
item_key = hash32(condition-name)
```
**Condition keys must be unique throughout the detector description.**
* Alignment conditions naming conventions:
* Alignment-delta conditions are called `alignment_delta`.
* Fully qualified alignment conditions are called `alignment`.
DD4hep provided alignment utilities rely on this convention.
* Other conditions can be named freely.
## Important Notice
The **Alignment conditions naming conventions** are already used by several utilities involving alignments. If you plan to use these, do not freely ignore these recommendations. When the naming conventions are ignored, these utilities shall not work.
## Updates to DDCond
DDCond implements a working conditions cache following the design criteria sketched above. The `conditionsSlice` object implements (though by forwarding to the `ConditionsUserPool`) a `ConditionsMap` interface.
The `DD4hep_ConditionsMapUserPool` plugin implements in a very efficient way this interface using an ordered map. Using the above described key definition, this implementation allows very efficient scans of conditions/alignments etc. of individual detector elements, since conditions which belong to the same detector element are contiguous.
## Alignment handling/computations
Using the conditions maps, the computation of (mis-)alignment data from deltas
is no longer bound to the conditions mechanisms.
A special utility called `AlignmentsCalculator` is put in place (see `DDCore/include/DD4hep/AlignmentsCalculator.h`) to facilitate the computation of a coherent set of alignments given a set of delta-parameters. This mechanism is much simpler, easier to understand and far less code intensive than the previously designed callback mechanism where alignments are obtained using conditions derivation.
## Update of the existing examples
The example sets in DDDB, `examples/Conditions, examples/AlignDet`, `examples/DDDB` were updated according to the changed mechanism of accessing conditions. Here we can see the real benefits of the new approach: keeping same functionality, the examples became way off simpler. Simply count the number of lines of code.
* 2017-06-17 Marko Petric ([PR#170](https://github.com/AIDASoft/DD4hep/pull/170))
- Add clang flag to warn about using namespace directive in global context in header
* 2017-06-17 Frank Gaede ([PR#167](https://github.com/AIDASoft/DD4hep/pull/167))
- renamed the namespace DD4hep::DDRec to dd4hep::rec (see #166)
- provide backward compatibility to outside world for now
- moved the interfaces in namespace DDSurfaces to dd4hep::rec
- provide backward compatibility to outside world for now
* 2017-06-15 Frank Gaede ([PR#165](https://github.com/AIDASoft/DD4hep/pull/165))
- started to cleanup DDRec
- don't use LCDD::getInstance() in SurfaceManager and SurfaceHelper
- deprecate unused(?) classes in DDRec/API and DDRec/Extensions
- deprecate MaterialManager() using LCDD::getInstance()
* 2017-05-12 Marko Petric ([PR#152](https://github.com/aidasoft/DD4hep/pull/152))
- Update CI to GCC 7.1 and LLVM 4.0 and include Geant4 10.3
* 2017-05-22 Frank Gaede ([PR#154](https://github.com/aidasoft/DD4hep/pull/154))
- protect against NANs in Guineapig pairs files in Geant4EventReaderGuineaPig
- make INFO printout more consistent with dd4hep style
* 2017-06-07 Frank Gaede ([PR#157](https://github.com/aidasoft/DD4hep/pull/157))
- bug fix in test_cellid_position_converter
- with this no tests for position from cellID lookup should fail
- re-implement ```CellIDPositionConverter::cellID(pos)```
Loading
Loading full blame...