We approve the concept that parameters should NOT become the start of a scripting language.
Length, Angle, Number should be replaced by one common "real" element with a "unit" attribute implicitly showing the parameter type.
Parameters should only be defined within parameter blocks. And parameter blocks should be defined in sections only (i.e. volumes may specify an IDREF to a parameter block).
The bug in mposX/Y/(Z) about transverse displacements is acknowledged. For mposZ, the transverse displacement might be either "X_Y" or "R_Phi" (with exclusion and error detection in case of using both).
pos should be replaced by axisPos and mpos by axisMPos (an intermediate proposition was for posAxis and mposAxis)
axisPos provides as attributes: a gap optionally replaced by shift between local coordinate origin and the origin of the stacked volume, the rotation along the axis of the composition and the transverse displacement.
axisMPos provides as attributes a starting gap and an iterative gap, optionally replaced by an starting and iterative shift (both are exclusive). Gaps are considered between edges whereas shifts are considered origins (see longer discussion the second day).
the coordinate origin for stacks is understood in this first step of the discussion to be set to the coordinate origin of the first positioned volume. The second day's meeting shows that this approach needs to be slightly revised and refined.
It should be understood that using gaps in axis positioners implies being able to compute a "thickness" along the stack axis for any volume.
The meaning of the different parameters has been explicited the second day (see drawing):
There is a proposition for a generalised single positioner, using an explicit specification of its geometrical operations:
<matrix_def name="..."> <rotation vector=... angle=... /> <translation x=... y=... z=... /> <rotation vector=... angle=... /> </matrix_def> <pos volume="..." > <translation x=... y=... z=... /> <rotation vector=... angle=... /> <rotation vector=... angle=... /> <translation x=... y=... z=... /> <matrix name="..." /> </pos>
Its primary definition would be:
Then we expect that any multiple positioner can be translated into a vector of single positioners, and that any single positioner can be translated into a generalized positioner. Since this includes to convert relative positioners into absolute positioners, a technical problem must be solved, which implies to be able to iteratively compute the volume dimensions (well dimensions along stack axis - which does not simplify the question).
This can be achieved (for example) in the C++ implementation by providing a virtual method
vector<SinglePosition> give_position_set()
in the MultiplePosition base class, and the virtual
method
Pos convert_to_pos ()
in the SinglePosition base class. We expect that this
mechanism will provide a way for graphical tools (or other
generic tools) to become independent of the future evolutions of
this aspect of the generic model.
There is a proposition to move back to the original stream line based on stacks rather than using the new concept of axis-based compositions. It is agreed that, once the concept of stack is properly extended, as this had been anticipated in a previous e-mail discussion, then the two concepts converge and do not require two implementations. It is decided to stick to the original naming scheme, say : stackX, stackY and stackZ for the stacking volumes, axisPos and axisMPos for the relative positioners.
Attributes for axisPos and axisMPos are revised so as to become more consistent according to the management of coordinates (see above):
Then came a discussion for clarifying mechanisms involved in positioning volumes, considering all possible situations. Positioners can be sorted into 4 categories:
It was proposed that transverse shifts in axis[M]Pos should be specified using the two appropriate attributes among dX, dY, dZ. The parsers should be responsible to detect bad choices (such as (dX dY) for stackX).
It was noted that the need for a support by the generic model of automatic computation of envelopes or center of a volume might occur in some future. We decide to wait for examples and use cases.
We observe that it would be useful to build guide lines or policy for the "preferred way" to assemble complex structures or complex shapes, especially when there are several "compatible" ways.
We express the requirement that a continuous line should be preserved as much as possible with respect to existing applications (example of the Muon processing chain or graphical tools). This should permit progressive integration of the AGDD framework within applications, and progressive use of all the features of the generic model. An example is the temporary use of parameter blocks to emulate most of what was handled by INNERSTRUCTs until the geometrical definitions stored there can be expressed using the plain generic model.
Versioning may be addressed ay many levels:
A proposition is to include in the AGDD element an attribute giving the required major id of the DTD version.
<!ATTLIST AGDD DTD_version ( "v3" ) #REQUIRED />
This implies that any XML file should provide in its AGDD element the follwing value:
<AGDD DTD_version = "v3" ...>
...
</AGDD>
In this scheme, a manual operation (possibly dangerous) is
required when the major id of the DTD is changed. But then XML
parsers are able to perform the syntactic check on XML files.
It is understood that some file organisation scheme is required so as to localise DTD, XML files, header files, etc... The relationship with the configuration management environment needs to be understood.
All sources of the detector description framework (including graphical tools such as Persint) should eventually be managed in the standard Atlas CVS repository.
The very short term evolutions of the DTD induced by this working week will be done in a version v4 so as not to disturb some use of the current v3. This new v4 will be considered as a pre-stable version until the next software week, where common decisions can be taken, and a freeze of this version can occur.
The most recent implementation provides the Identifier, Range and IdentifierMap classes. Some primary documentation is included in the C++ header files. They can be seen in d57/Packages/DetectorDescription/Identifiers/v3/...
It's very likely that interpretation interfaces to primary identifiers will be needed so as to exploit the appropriate semantics of the various id. fields (eg. to extract a given strip for a complete identifier object or vice versa to create an identifier for a given element).
Some of the identifier fields might have to be seen (thru the interfaces at least) only as symbolic values rather then numbers (eg. if we have station types or differenciation between "EndCap" and "Barrel").
Identifier fields might not be limited (at least at the interface level) to ranges starting at zero and to be positive, but may rather take any range of contiguous values (positive or negative).
The question remains open if these features extend to the implementation or not. But performance issues for large collections will likely occur.
The draft document is expected to be tuned and completed according to realistic needs.
The boolean volume mechanism needs to be slightly modified. The current definition includes a ref_volume (a member IDREF available in any boolean volume) which refers to the first volume involved in this kind of operation. This mechanism does not permit to position this first volume, while introducing a meaningless asymetry (only for unions and intersections).
Thus, in order to cure these two problems it is proposed to:
It is understood that this new syntax is simpler than the previous one and that this is an affordable non-backward compatible change.
An example is presented in the next drawing:
