[Solid_tracking] SIDIS & PVDIS simulation output

[Ole Hansen]

Quick question: Did someone move the files from those directories or did they get auto-cleaned (or lost)?

Ole

Ole Hansen <ole at jlab.org> wrote:

>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
>_______________________________________________
>Solid_tracking mailing list
>Solid_tracking at jlab.org
>https://mailman.jlab.org/mailman/listinfo/solid_tracking