[Solid_tracking] SIDIS & PVDIS simulation output

[Ole Hansen]

Hi folks,

I have restored Rich's simulation production runs for the SoLID PVDIS
and SIDIS tracking studies. The files are in

/volatile/halla/solid/ole/PVDIS
/volatile/halla/solid/ole/SIDIS

A brief explanation of the files follows.
--------------------------
PVDIS:

pvdis_e_field_20150124_*.ev:
 10 signal runs, each with 1e5 e- DIS events, all materials (baffles),
 field on

pvdis_muon_nofield_nomats_20150218_115447.ev:
 Signal run with 1e6 muon DIS events, no baffle materials (to prevent
 multiple scattering from punch-through), NO field (straight tracks)

pvdis_20141112_*.ev:
 500 background runs, each with 1e6 e- on target, field on

The muon signal run and all the background runs were used for the
tracking study I presented at the director's review. The script used to
digitize the events is

Digitize_pvdis_5gem_qgsp.C

You'll have to modify the script slightly for the new file locations and
your preferred naming scheme. The code should be straightforward to
understand.

Also important are the databases for libsolgem and the analyzer:

Needed for digitization:
db_ratedig.dat           Digitization parameters
db_gemc.dat              GEM geometry description

Needed for analyzer:
db_solsim_cratemap.dat   Cratemap (may not be completely up to date,
                         slots 27-29 meed to be defined)
db_solid.tracker.dat     Analyzer database

Important: db_solid.tracker.dat should be auto-generated from
db_gemc.dat using the dbconvert program found in the TreeSearch
repository (solid branch).

--------------
SIDIS:
sidis_epip_20150106_163721.ev:
 Signal run with 1e6 SIDIS e- + pi+ events, field on

sidis_20141223_*.ev:
 500 background runs (unsure about conditions, ask Rich for details if
 needed)

I haven't attempted to digitize these, so there is no script. To do the
SIDIS digitization, libsolgem needs to be modified to account for the
geometry. The geometry is defined in the gcard used:

/home/rsholmes/batch/solid_sidis_gem_121814.gcard

which specifies "user_geometry_4" on the soliduser at soliddb.jlab.org
database account/server. Again, ask a simulation expert for details, if
needed.

It's a student exercise in programming as to how to modify libsolgem.
One takes the existing example for PVDIS and starts modifying it as
needed. Either keep the existing library and switch between PVDIS and
SIDIS configurations with a flag (my preference), or create a new
library, for example, libsolgem-sidis. The latter can reuse existing
code for the GEM digitization, of course.

To process these data, I recommend to use the latest code from GitHib:
analyzer 1.6 (master branch), TreeSearch (solid branch) and libsolgem
(master branch). All of these have recently been updated.

More comments inline below.

Ole

On 12/04/2015 04:57 PM, Zhiwen Zhao wrote:
> hi, Ole
> 
> I think Weizhi has the information about treesearch code as you mentioned.
> Here are other things Weizhi need for the study
> 1. Both signal and background file for SIDIS and PVDIS made by Rich and
> used by you as input to libsolgem for digitization
> 2. some instruction and scripts about how to use libsolgem to do the
> actual digitization, your files when you did PVDIS digitization would be
> nice
> 3. some suggestion where to modify libsolgem to do SIDIS digitization
> 
> About tracking work flow
> Is it good to output the result of "decoding and Hit Clustering" in
> treesearch into a file
> so that any tracking code can just take the file and do tracking?
> This way it saves a lot time when the tracking code get tuned or changed.

Sure. I think Weizhi has already implemented this.

> I think Weizhi's tracking code, at least the Kalman Filter part, is
> based on KalTest package.
> Maybe it's not possible or not easy to do it within treesearch code.
> Weizhi can correct me if I am wrong.

No, it's quite easy. There is a well-defined place in the code (at the
end of Tracker::Decode) where the hits and clusters can be written.

> Overall I think we should think about how to make tracking code
> independent,
> so that's it's easy to be implemented into whatever reconstruction
> framework we use.

This will be much easier once we switch to one of the more advanced
software frameworks that allow arbitrary data objects to be written to
intermediate files. This is a good example of where the "data object"
feature would be very useful. As you can see, the Hall A analyzer does
not support it, and one has to resort to a hack.

> Taking parameters out of code can be a start.

Many parameters are already configurable in the database
(db_solid.tracker.dat)

Ole