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

[Rakitha Sanjeewa Beminiwattha]

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

On Tue, Mar 31, 2015 at 10:58 AM, rsholmes at syr.edu <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 <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> 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
>>>
>>>
>>
>>
>> --
>> - Richard S. Holmes
>>   Physics Department
>>   Syracuse University
>>   Syracuse, NY 13244
>>   315-443-5977
>>
>
>
>
> --
> - Richard S. Holmes
>   Physics Department
>   Syracuse University
>   Syracuse, NY 13244
>   315-443-5977
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halla12_software/attachments/20150331/13654d75/attachment-0001.html