[Halla12_software] SoLID Software Meeting on Thursday at 2pm 03/26 Room-B101

[Zhiwen Zhao]

hi, Rich and All

For the output tree format, I think we definitely need a tree or a bank contain the event info.
But the critical thing is that each sub-detector should be able to define it easily and freely.
They can have very different truth info and digitization and the requirement can be different at 
different stage of study.

For background mixing, the challenge is that different background have very different rates.
For example, we can have photon from pion0 more than an order larger than pion+.
Producing a file with enough photons from pion0 may have too little pion+ to do study with 
meaningful statistics,
If we increase number of events by an order, we have enough pion+, but wasting a lot computing time 
on pion0.
The things goes to extreme when combine low energy Em background with hadron background.
Therefore, running geant4 with all physics turned on only gives huge amount of low energy EM 
background, but little hadron background.
So far, what we did is to run all background separately, then record background rate at entrance of 
detectors.
Then do a separate simulation again for the detector with background thrown onto it accordingly.
This maybe ok for single detector study, but is not good for combined detector and DAQ study.
We need to think of a solution from the top.

Thanks

Zhiwen

On 3/31/2015 11:58 AM, rsholmes at syr.edu wrote:
>     We need to think more about what data we want in the output and how to organize it.
>
>
> I've put some initial ideas in a document linked at the software ideas wiki page.
> https://hallaweb.jlab.org/wiki/index.php/SoLID_Software_idea
>
> On Tue, Mar 31, 2015 at 11:32 AM, Rakitha Sanjeewa Beminiwattha <rakithab at jlab.org
> <mailto:rakithab at jlab.org>> wrote:
>
>     Except for DIS we do have uniform (number weighted) generators for all the backgrounds that
>     could built into the code or to get into lund/sollund format input files. In Remoll the option
>     is already there to choose either uniform or rate weighted options.
>     Also rate weighted scheme waste so much computing time by simulating rate = 0 events.
>     So far I used post simulation script to merge backgrounds simulations from different individual
>     simulations. But Rich is right we don't have a proper mechanism to merge all the backgrounds
>     with the DIS signal due to lack of good uniform DIS generator.
>
>     I will update the document to include your suggestions/comments
>
>     Thanks!
>
>     Rakitha Beminiwattha
>     (Research Associate)
>     office F386
>     12000 Jefferson ave
>     Suite # 5
>     Newport News, Va 23606
>     Tel No. 757 269 6453 <tel:757%20269%206453>
>
>     On Tue, Mar 31, 2015 at 10:58 AM, rsholmes at syr.edu <mailto:rsholmes at syr.edu> <rsholmes at syr.edu
>     <mailto:rsholmes at syr.edu>> wrote:
>
>         Also: Needs discussion about merging signal and background hits.
>
>         On Tue, Mar 31, 2015 at 10:15 AM, rsholmes at syr.edu <mailto:rsholmes at syr.edu>
>         <rsholmes at syr.edu <mailto:rsholmes at syr.edu>> wrote:
>
>             A few reactions:
>
>             - Weighted generators are problematic for some studies. They distort distributions of
>             secondaries. Uniform generators should be available.
>
>             - Information needed to replicate a run could be either in the output file or in an
>             unambiguous, immutable other location — or a combination of both. As was pointed out in
>             the meeting, we might not want to write e.g. field maps to every output file. But
>             neither do we want to have the field map in a database table that any user can later
>             delete or modify. Some kind of database to which users can add information, but not
>             delete or modify it, would be preferred, I think, for "standard" configurations, and
>             then deviations from standard configurations, as well as run options etc. (command line
>             and gcard, in GEMC terms), ought to be in the output file itself.
>
>             - We should consider carefully, if there is a centralized database, how to make and use
>             local mirrors. At times the JLab connection is interrupted and offsite work comes to a
>             halt if the complete, up to date database information is not available locally.
>
>             (Our database needs remind me of a version control system. Add new information, but old
>             information is preserved; central repository and local copies; etc.)
>
>             - We should talk about installation. My experience has been that installing GEMC
>             offsite, with its long list of dependencies, has almost every time been plagued with
>             difficulties. Remoll was easy. What design decisions can be made to minimize
>             installation headaches?
>
>             - We need to think more about what data we want in the output and how to organize it.
>
>
>
>             On Tue, Mar 31, 2015 at 9:29 AM, Rakitha Sanjeewa Beminiwattha <rakithab at jlab.org
>             <mailto:rakithab at jlab.org>> wrote:
>
>                 Hello,
>                 I have added a document listing SoLID simulation requirements based on discussions
>                 we had so far during our software meetings.
>
>                 The document is linked at https://hallaweb.jlab.org/wiki/index.php/SoLID_Software_idea
>
>                 Rakitha Beminiwattha
>                 (Research Associate)
>                 office F386
>                 12000 Jefferson ave
>                 Suite # 5
>                 Newport News, Va 23606
>                 Tel No. 757 269 6453 <tel:757%20269%206453>
>
>
>
>
>             --
>             - Richard S. Holmes
>                Physics Department
>                Syracuse University
>                Syracuse, NY 13244
>             315-443-5977 <tel:315-443-5977>
>
>
>
>
>         --
>         - Richard S. Holmes
>            Physics Department
>            Syracuse University
>            Syracuse, NY 13244
>         315-443-5977 <tel:315-443-5977>
>
>
>
>
>
> --
> - Richard S. Holmes
>    Physics Department
>    Syracuse University
>    Syracuse, NY 13244
>    315-443-5977