Follow-up from "Documenting the objects"
The following discussions from !350 (merged) should be addressed:
-
@pschutze started a discussion: (+3 comments) I'd argue that this is not only for imaging, but could be used for any DUT measurement as well :-)
Both tracks are extrapolated to a user defined `z`-position in between and both, the transverse distance of the tracks at the matching position as well as the change in direction (scattering kink) are calculated.
-
@pschutze started a discussion: (+1 comment) Shouldn't these be
\subsubsection
s? Or make it an itemization? Having it at the same hierarchy level looks odd. -
@simonspa started a discussion: Technically what
TObject
provides is the streamers, we still need to manually create the trees and branches. I would rephrase this and simply say that this opens the possibility of storing the in ROOT trees. -
@simonspa started a discussion: (+1 comment) This reference points to a rather random section of the developers guide, telling the reader which files are required for a module. I thin you wanted to link to the FileReader/Writer modules?
-
@simonspa started a discussion: What I am missing here is a section describing (in general) that there is a hierarchy/history with links between these objects and that it is for example possible to retrieve the original pixel hits from a track.
-
@simonspa started a discussion: "In addition" sounds like this is optional. For the SPIDR signals this is correct, but the
Track
class is abstract, so we definitely need the different models filling this class with life. I would therefore not throw them into the same pot as SPIDR-signals. -
@simonspa started a discussion: "The latter can hold supplementary information fromt he SPIDR readout system" or something like this, it's not required and barely used anywhere.
-
@simonspa started a discussion: - "raw information" isn't very specific, could you rephrase this?
- "if no timestamp is provided"
- Charge is assumed to be in electrons, not electron volts afaik. Correct me if I'm wrong
-
@simonspa started a discussion: I think this is still missing some features of the
Cluster
class:- split clusters
- errors in x and y
- ability to return width and height in columns and rows (projected sizes)
- possibility of providing seed pixel
-
@simonspa started a discussion: you also could have used the
\command{}
defined bellow to typeset these.