|Event Class Brainstorming [message #10717]
||Thu, 20 May 2010 18:11
Registered: March 2006
... and sorry for starting this topic so late...
Here are some of the ideas and concepts that we at COMPASS came up with for the design of an event class for PWA:
* Prime responsibility is kinematics
* event-data SEPARATED from amplitude calculator
* Event weight
* Meta event information is useful
In more detail:
Prime responsibility of the event class is to contain/provide all the kinematical information that is necessary to calculate amplitudes (in a given formalism). This obviously includes the 4-vectors of all involved particles and some meta-information which further defines the particles (species, quantum numbers, pid-info etc).
It also makes sense to put kinematical manipulations of subsystems of the particles here. Including the necessary lorentz-transforms (possibly with a caching mechanism).
At compass so far we use simple ascii files to store the info. This is read into a custom class. We will switch (rootpwa) to root-persistence in the near future.
What should be SEPARATED from the event is the actual computation of an amplitude, because this might depend on the formalism.
One issue that complicates the story a bit is the fact that for different formalisms but especially for different production mechanisms one needs different information (especially on the initial state.) This means that the amplitude calculator in principle decides which information it needs from the event. So the event class (if you do not want to write a special one for each case) needs some flexibility. There are obviously different technical solutions to this.
The event class must be able to carry a weight needed for several statistical tricks...
The event may contain meta-information such as trigger-flags, event selection cut settings etc which might be useful to still have available on the level of PWA.
So far so good...
Technische Universität München
Department Physik E18