[Solid_tracking] help with SoLID GEM simulation

[Zhiwen Zhao]

I am bringing this discussion into the solid_tracking emaillist, as a 
way to record it.
If you are reading this, it means I took the liberty to register your 
email in the list.

Yes, The current parameter file is for simulation only.
I totally agree with you that we should add more parameters and maybe 
even group them in a way as
something like "general,simulation only, reconstruction only,analysis only"
Maybe Rich can compile a list for digitization and Ole can compile list 
for reconstruction, Weizhi can do a list for tracking?
I think it would be invaluable no matter what framework we will use/create.
It's like an exercise toward the "detector definition" we have been 
talking about.
The parameter file format could still be used for now, but it can be 
change or evolved easily.

For Weizhi's study, I think we should have limited goal though.
Mainly finish the digitization using existing tool.
That maybe best way to use his time before he is getting busy with PRad 
in spring.

Zhiwen

On 12/4/2015 2:10 PM, Richard S. Holmes wrote:
> Those parameter files just describe the simple donut models of the GEMs.
> Realistic descriptions would parameterize each GEM segment's geometry
> by, for instance, the cylindrical coordinates of the nominal segment
> center; the z coordinate of each layer relative to the center; the
> cartesian or polar coordinates of the four corners relative to the
> center (for each layer, or assumed the same for all layers); and the
> width and pitch of the readout strips. In addition, as Ole says, there
> would be gas parameters, time window widths, etc.
>
> Then code would have to be written or modified to inflate these
> parameters into objects the simulation, digitization, and reconstruction
> codes understand. In the case of digitization, the present code assumes
> annular segment geometry and would need to be revised to handle
> quadrilateral geometry.
>
>
> On Fri, Dec 4, 2015 at 1:18 PM, Ole Hansen <ole at jlab.org
> <mailto:ole at jlab.org>> wrote:
>
>     Well, that's what we spent the better part of the summer discussing in
>     the SoLID software meetings: how best to parameterize and "inflate" the
>     geometry. I'm not sure the parameter sets that you link to are enough,
>     but they are certainly a start. Details about the readout plane (strip
>     angles, position shifts) need to be added for sure, as well as the gas
>     parameters and the time window width for the digitization, etc.
>
>     It would be a useful contribution if someone could compile a list of all
>     the geometry-related database input parameters needed by GEMC, libsolgem
>     and TreeSearch-SoLID.
>
>     Ole
>
>     On 12/04/2015 01:06 PM, Zhiwen Zhao wrote:
>     > hi, Ole
>     >
>     > The current simulation in GEMC 2.x has the external parameter file
>     >https://jlabsvn.jlab.org/svnroot/solid/solid_gemc2/geometry/gem/solid_PVDIS_gem__parameters_Original.txt
>     >
>     >https://jlabsvn.jlab.org/svnroot/solid/solid_gemc2/geometry/gem/solid_SIDIS_gem__parameters_Original.txt
>     >
>     > We can add more entries if needed.
>     > I think it can be the only input for simulation, digitization and
>     > reconstruction?
>     >
>     > Zhiwen
>     >
>     > On 12/4/2015 12:53 PM, Ole Hansen wrote:
>     >> Indeed, "may be messy" is a good description of the possible
>     >> generalization of the GEM geometries. For added fun, the geometry has to
>     >> be kept in sync between simulation, digitization and reconstruction;
>     >> each of these components uses a different geometry description right now.
>     >>
>     >> Ole
>     >>
>     >> On 12/04/2015 11:52 AM, Richard S. Holmes wrote:
>     >>> Really the digitization code (which started off with rectangular GEMs,
>     >>> and was converted by me to annular segments) should have been / should
>     >>> be written to work with arbitrary quadrilaterals. And of course the
>     >>> simulation should make the GEM segments quadrilaterals too.
>     >>>
>     >>> On Fri, Dec 4, 2015 at 11:47 AM, Richard S. Holmes <rsholmes at syr.edu <mailto:rsholmes at syr.edu>
>     >>> <mailto:rsholmes at syr.edu <mailto:rsholmes at syr.edu>>> wrote:
>     >>>
>     >>>      The digitization code (at least when I last worked with it, which
>     >>>      was a long time ago) assumes the GEMs are annular segments: that
>     >>> is,
>     >>>      bounded on the inside and outside by arcs centered on the x/y
>     >>>      origin, and on the sides by radial line segments. The strips are
>     >>>      then parallel to one side or the other. Of course the real GEMs
>     >>> will
>     >>>      presumably be trapezoids instead, i.e. bounded on the inside and
>     >>>      outside by line segments perpendicular to the center line, but this
>     >>>      is maybe too small a correction to be concerned with now.
>     >>>
>     >>>      For SIDIS the geometry is more complicated, because the GEMs are
>     >>> the
>     >>>      same as for PVDIS but displaced toward the x/y origin, meaning the
>     >>>      sides (and hence the edge strips) no longer are radial.
>     >>>
>     >>>      This again may or may not be important at this stage, but it'll
>     >>> have
>     >>>      to be addressed sometime, and may be messy.
>     >>>
>     >>
>
>
>
>
> --
> - Richard S. Holmes
>    Physics Department
>    Syracuse University
>    Syracuse, NY 13244
>    315-443-5977