[Halld-offline] Geant4

Richard Jones richard.t.jones at uconn.edu
Thu Jan 31 17:41:27 EST 2013


David and all,

Yes, good point.  Even back when I was working on the now-defunct version of the hits code, the BCAL hits section was in a confusing state.  There were multiple redundant schemes for representing hits, with some tags in the output hddm schema actually containing the string "deprecated" as I recall.  Getting this straightened out before the transition seems like a must-do.

-Richard J.




On 1/31/2013 3:34 PM, David Lawrence wrote:
> Hi All,
>
>   One thing to keep in mind is that the BCAL simulation had a significant revision done last fall that was disabled soon after implementation. The disabling was to be a temporary measure until someone was able to work on the BCAL reconstruction to make it use the new simulation data format (not a 1 hour task). If we freeze GEANT3 now, both BCAL simulation algorithms will need to be ported to GEANT4. Even the disabled one. I'm not arguing that we shouldn't do it now. Just that Richard should be aware
> that this will be a part of the task.
>
> Regards,
> -David
>
> On 1/30/13 4:25 PM, Curtis A. Meyer wrote:
>> It feels to me that it would be a good time to freeze GEANT3 and force a migration to GEANT4. We have
>> a lot to do with our data challenge right now that will keep us busy without doing things to GEANT, and
>> as Matt said, getting this done now may well be our last chance to do it in a sensible way that minimizes
>> work being done twice when we get data.
>>    Curtis
>> -------
>> Prof. Curtis A. MeyerDepartment of Physics
>> Phone: (412) 268-2745Carnegie Mellon University
>> Fax:      (412) 681-0648  Pittsburgh, PA 15213
>> curtis.meyer at cmu.edu <mailto:curtis.meyer at cmu.edu> http://www.curtismeyer.com/
>>
>>
>>
>>
>>
>> On Jan 30, 2013, at 1:34 PM, Matthew Shepherd wrote:
>>
>>>
>>> Hi software gurus,
>>>
>>> Many years ago we decided that migrating to Geant4 was not a high priority for our software activities, although our software was intentionally designed to facilitate a migration at a later date.  With the generation of the first data challenge now under our belt, I wonder if we want to revisit this decision?
>>>
>>> I think there are two main reasons to consider making a switch:
>>>
>>> Running CERNLIB on modern operating systems is a real headache.  I know there are working solutions that allow us to function, but they work on only some OS'es and involve downloading patched code a private developer.  CERNLIB has no official support and overall this results in a net productivity loss for us since we depend on it and it generates a lot of frustration for people trying to get our software running.
>>>
>>> The second, more significant reason is that, if we are going to switch to Geant4, we want to have fully made the transition to Geant4 by the time we start taking data.  One of the most time consuming and challenging aspects of analyses is understanding the systematic uncertainties in efficiency due to the fact that the Monte Carlo isn't a perfect model of the detector.  We'd like to only go through this once:  we don't want to do it once for Geant3 and then again for Geant4.  Geant3 is fine for the exercises we are doing now, but if we're ever going to make the switch, it would be wise to do it well before we start taking data.
>>>
>>> Of course it is always easy for someone to propose work when that person is not the one actually doing the work!  The burden would fall on the Geant expert (or experts, do we have more than one?)  in our group.  I know that Richard reported last year that significant progress had been made in porting code to Geant4.
>>>
>>> Maybe we can bring this up for discussion at a future software meeting or discuss more through this email thread.  Maybe the right answer is that it is still not a high priority item -- I think it merits a little discussion again though.  (Maybe you already talked about it during one of the many software meetings I missed last fall!)
>>>
>>> Matt
>>>
>>>
>>> _______________________________________________
>>> Halld-offline mailing list
>>> Halld-offline at jlab.org <mailto:Halld-offline at jlab.org>
>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>>>
>>
>>
>>
>> _______________________________________________
>> Halld-offline mailing list
>> Halld-offline at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>
>
>
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20130131/cf492553/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3232 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20130131/cf492553/attachment.p7s>


More information about the Halld-offline mailing list