[Solid_tracking] things Weizhi needed and tracking workflow

[Zhiwen Zhao]

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.
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.
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.
Taking parameters out of code can be a start.

Zhiwen


On 12/4/2015 1:11 PM, Ole Hansen wrote:
> Hi Zhiwen,
>
> Evaristo's code seemed to have a couple of bugs and performance problems
> which I have fixed in libsolgem. The bugs were related to the way random
> numbers were generated and the hit time offset was handled. I'm not sure
> if these bugs are present in the SBS code as well, they might have crept
> in when porting things over to SoLID/libsolgem.
>
> There are still problems with the GEM digitization: the width of the
> charge distribution at the readout plane is too small overall and
> asymmetric between the two readout strip directions. I asked Evaristo
> about this in 2014 and didn't get a convincing answer; it seems like
> they are just tweaking parameters to fit the experimentally observed
> charge distribution. That may be good enough for the moment, even if the
> relevant parameter (the diffusion constant) ends up being
> unrealistically large.
>
> There is a pulse deconvolution and a hit clustering algorithm in
> JeffersonLab/TreeSearch (use the "solid" branch!) which work reasonably
> well. These algorithms may also be present in the SBS code, but the
> deconvolution algorithm there may have a serious bug. Whatever is on
> GitHub in JeffersonLab/TreeSearch is the best available code to my
> knowledge.
>
> BTW, I already gave all this information to Weizhi in 2014. He managed
> to compile and run libsolgem and TreeSearch, but then decided to ditch
> everything from TreeSearch and use his own standalone code instead. The
> TreeSearch code is useful as a skeleton within which one can fairly
> easily implement a different tracking algorithm without having to redo
> the whole decoding and hit processing steps.
>
> Ole
>
> On 12/04/2015 11:29 AM, Zhiwen Zhao wrote:
>> Evaristo's old code is not available any more.
>> Could you let me know where the latest SBS code is?
>>
>> So libsolgem does the same things for SBS GEM digitization?
>>
>> My understanding is Ole has decoding and Hit Clustering done in
>> treesearch code after digitization by libsolgem
>> Does SBS do the same thing or even use the same code?
>>
>> Zhiwen
>>
>> On 12/4/2015 11:22 AM, Seamus Riordan wrote:
>>> Hi Zhiwen,
>>>
>>> The way it's been implemented for SoLID is the way it's been implemented
>>> for SBS.  There's been no further development in SBS on the
>>> digitization, so if you have built the INFN digitization, you're at the
>>> state of the art.
>>>
>>> Best,
>>> Seamus
>>>
>>> On 12/04/2015 11:16 AM, Zhiwen Zhao wrote:
>>>> Dear All
>>>>
>>>> To give input for Weizhi's tracking study, I am checking the SoLID GEM
>>>> simulation
>>>> and hopefully do it right this time
>>>>
>>>> Kondo
>>>> Could you help check if the geometry,material and response are correct?
>>>> here is some description
>>>> https://hallaweb.jlab.org/wiki/index.php/Solid_Tracking#GEM_module.27s_geometry_and_material
>>>>
>>>>
>>>> here is implementation in GEMC perl script
>>>> https://jlabsvn.jlab.org/svnroot/solid/solid_gemc2/geometry/gem/solid_SIDIS_gem_geometry.pl
>>>>
>>>>
>>>>
>>>> Seamus
>>>> Suppose SBS uses the exactly same hardware, would it possible to do
>>>> simulation and digitization
>>>> the same way for SoLID?
>>>> Could you let me know how it's implemented in SBS? Code would be nice.
>>>> By the way, I built SoLID GEM from Evaristo's old code. things must
>>>> have evolve now.
>>>>
>>>> Nilanga
>>>> Currently GEM in SoLID is simple donut like planes
>>>> It would be really nice if we can have the actual physical design
>>>> implemented.
>>>> It could have impact especially for SIDIS because the segmentation and
>>>> overlaps.
>>>> We don't have a person assigned with GEM simulation task.
>>>> I think we definitely need somebody to do careful study for the large
>>>> background rate and optimize the design.
>>>> Do you know a good person for it?
>>>>
>>>> Thanks
>>>>
>>>> Zhiwen
>>>
>