Thank you for your email and interest in the off-line software.
I basically agree with your statement that the tagger could be
incorporated into the simulation software package as a seperate entity,
similar to the gsim input generator celeg.
I don't know how your current software works, so I don't know what kind of
output it generates, also I am not up to speed on exactly what is needed
for the tagger simulation. It would be good to have some email discussion
on this subject with the other interested people.
One thing that seems important in the context of a tagger package is who
will be responsible for "simulating" the interaction of the photon with
the target. This is obviously not a full simulation, since this is where
the physics we try to measure occurs. However, gsim needs particles that
come out of the target region as it's input, so we can't stop at just
providing it with a beamline photon.
About who is going to write/implement this code:
Perhaps Eric (anciant@phnx7.saclay.cea.fr) and Carlos (salgado@cebaf.gov)
can work out who is going to do what part of the writing, implementing and
maintaining of this part of gsim. It seems to me a good idea to use as
much of the already existing code as possible, but to avoid having two
completely seperate implementations.
Please let us know about what you decide to do, and who is going to be
doing what, and I will make sure that the web pages are updated
accordingly. It would be great to create a seperate page on the tagger
simulation explaning it's use in detail.
Best regards,
Maurik Holtrop
On Wed, 11 Jun 1997, E Anciant wrote:
> Hello,
>
> I've seen on the webb, you applied for been responsible
> of adding the tagger in gsim,
>
> I've been thinking of this problem too,
>
> the problem is that a tagger simulation would be used by too different
> type of person:
>
> 1 - people needing a simulation of hits in the tagger, together
> with the caracteristics of the photon reaching the target to feed the
> CLAS software package.
>
> 2 - People working on the photon line, and the problem of normalisation.
> (beam line comprehension , AND, tagger in interaction with the
> Down Stream Devices)
>
> These are two different problems since a photon interacting in the
> target
> doesn't interact with the Down Stream Devices, and vice-versa.
>
> -for the CLAS simulation, in a first step, a mere lookup table should be
> enough:
> input : photon energy.
> output: E and T counters hits.
>
> then it would be CLAS simulation task to figure out, given the angular
> distribution of the brehmstrahlung where the photon hits the target.
>
> Dan already possesses this table, or I can simulate it with my geant
> package.
>
>
> -For the beam line study, AND more accurate studies of the tagger
> (with multiple scatering, edge effects..) we can think of developping
> a more complete package.
>
> It seems to me the best way to do this is to create a stand-alone
> package (independent from gsim) which would follow the same
> architecture than recsis: different modules for the different
> detectors (tagger, PC, PS ,TAC, Line elements, ..)
> using CVS for checking in and out those modules and developp
> them,
> this package should be abble to produce an appropriate bank
> (with photon properties, and hits in the tagger) used to
> feed the gsim software.
> Every user would also be abble to develop its own simulation for
> various elements of the beam line.
>
> the work would be then in a first step to reorganise the beam-line
> simulation package I wrote which already contains
> the geometry of the tagger, the pair counter, the TAC, some beam line
> elements (collimators, sweeping magnets, support ring, saclay target,
> start counters, tunnel, shielding walls), in a form similar to the
> one of recsis, with different subdirectories, for different elements
> (Tagger, PC, PS, TAC, Line, ..) containing the differents makefiles,
> and also, cms, include, etc.., directories, and rewrite the makefile so
> that it properly creates the libraries and the executables
> in some /bin/{platform}/ and /lib/{platform} directories.
>
> I'm looking right now at the CLAS offline Code Management,
> because I will have to include the real-photon normalisation analysis
> in RECSIS, so I will at the same time think of a way to reorganise my
> code,
>
> I'm waiting for your remarks, and suggestions
>
> eric
>
> ----- Eric Anciant ------------
> DAPNIA/SPhN - Bat 703 - Orme des merisiers
> CE-SACLAY - 91191 GIF-SUR-YVETTE Cedex - FRANCE
> Office: (33 - 1) 69 08 22 47 - fax: (33-1) 69 08 75 84
> http://www.rez-gif.supelec.fr/home_pages/anciant/
>