[Halla12_software] another point about geometry API.

Tue Apr 7 14:42:55 EDT 2015

Hi Lorenzo

I don't see how this addresses the issues we have raised about uniformity
of geometry and calibrations between simulations and offline code.  Running
GEMC...sure do it or not.  I don't think that is the question addressed
here.  I think that the thread is about the computing scheme for the
experiment as a whole.  GEMC is a wrapper around geant4 and is one corner
of the project.  For the broad computing scheme, we must manage how we fit
that corner of the project seamlessly into the full scheme.  Adopt or don't
is not the issue yet...we must design the scheme first and then
specify&fill the simulations corner of the scheme.

Tom

On Tue, Apr 7, 2015 at 2:15 PM, Lorenzo Zana <zana at jlab.org> wrote:

> Hi,
> my small intake based on y experience on this software.
> One thing still to take in mind is that the same Geometry will need to be
> imported to FLUKA for radiation and activation issues. This was suggested
> also by the committee at the last director review for double checking
> everything.
>
> I had already looked in the past to the approach used in FAIR and other
> with virtual montecarlo generated through root. This theoretically worked
> with FLUKA, GEANT3, GEANT4 and whatever simulation software you will bring
> in the future. The same input will be used by other simulation software.
> After looking into this, I THEN RULE THAT OUT, since the release of FLUKA
> is NOT DIRECTLY SUPPORTED (and one needs some kind of ‘blessing’ from the
> FLUKA collaboration to just have it to work). With also this, the FLUKA
> collaboration strongly suggested in not using this virtual machine results,
> because they didn’t trusted the result that was coming from it (and also
> the running version was pretty old).
>
> One thing that has been working for me is that there is currently and in
> development a GDML translator to FLUKA geometry. Does not work perfectly
> and needs a lot of after corrections, but still saves me a lot of time (~3
> days each time of full work on this) when I need to import a new geometry.
> GEMC with its translator into GDML of small section of the geometry worked
> great for me (the translator does not work with too complex geometries
> neither).
>
> My suggestion on this is using and developing the current version of GEMC
> for multiple reasons. In understand the disadvantages, but this in my
> opinion are the advantage. My suggestion is develop the current version of
> GEMC so that we could tune it to what we need. The advantages of this point
> in my opinion will be:
>
>    - Not reinventing the wheel . The system works already in Jlab
>    environment and is already supported. Works already on other systems and is
>    pretty easily installed.
>    - Our collaboration has already experience in running this
>    - I think from Jlab management will be good for them to show a single
>    software development in GEANT4 for showing a good use of people and
>    resources (Not sure, but I had this impression)
>    - Works already for me the import into FLUKA and at now seems the
>    better option for this
>    - We have still a detector fully in development. A central
>    installation of the detectors  (the solid mysql database) is important for
>    not having multi versions (one theoretically could put this in a check at
>    the start of the simulation, but the central mysql database is enforcing
>    the use of a common detectors)
>
>
> (Sorry, kids running wild…. I’ll write more about tonight)
>
>
>
> Dr. Lorenzo Zana
>
> Research Associate
> The University of Edinburgh
> zana at jlab.org
>
> Address:
> School of Physics & Astronomy
> Room 8211a   JCMB
> The King's Buildings
> Mayfield road
> Edinburgh EH9 3JZ
> Tel  +44 0131 650 5256
> Fax +44 0131 650 5902
>
> On Apr 7, 2015, at 1:28 PM, Thomas K Hemmick <
> hemmick at skipper.physics.sunysb.edu> wrote:
>
> Thanks Ole, that explains A LOT of what people have not yet said.  Two
> questions:
>
> A:  Without root, what would we use?  PAW...home grown...?
> B:  Without C++ what would we use?  FORTRAN...perl...python...?
>
> As you might have guessed, I have operated under the presumption of a
> root/geant4 code base.  It seems to me that any other choice is more work
> for the core team than I care to think about in my worst nightmare!
>
> 1)  Does anyone among us believe that we have the capability to write our
> own root or geant4?
> 2)  Among those who believe item 1, do you think that we are wise to do
> this?
>
> Perhaps this is first thing we should discuss.  My opinion is simple:
> root/geant4 should be the basis of SoLID software.  I'm curious to hear if
> any of us has a different opinion on this.
>
> All the best,
> Tom
>
> On Tue, Apr 7, 2015 at 12:28 PM, Ole Hansen <ole at jlab.org> wrote:
>
>> On 04/06/2015 10:56 PM, Richard S. Holmes wrote:
>> > On Mon, Apr 6, 2015 at 4:51 PM, Thomas K Hemmick
>> > <hemmick at skipper.physics.sunysb.edu
>> > <mailto:hemmick at skipper.physics.sunysb.edu>> wrote:
>> >
>> >     I)  Root streamers mean that with ZERO WORK, we can store/retrieve
>> >     the detector definition objects to/from a file.
>> >
>> >
>> > It seems to me, unless I'm mistaken, there's a few words missing from
>> > the end of this sentence, which are: "in a C++ program linked against
>> > ROOT".
>>
>> Rich's point is similar to one I wanted to bring up: The idea of using
>> ROOT streamers implies major design decisions that haven't been made
>> yet: That (at least parts of) the framework will require C++ and ROOT,
>> and that we wish to standardize on ROOT files.
>>
>> This point is significant because, among other things, neither the Hall
>> B nor the Hall D framework are built on ROOT, and Hall B's framework (as
>> well as much other JLab software) is not primarily written in C++. In
>> other words, if we want to build on ROOT, we're effectively ruling out
>> building on either of those frameworks. Similarly, neither framework
>> relies primarily on the ROOT file format; for instance, Hall D's
>> framework makes heavy use of XML and its own schema definitions.
>> (ROOT/C++/streamers are being used in the Hall A analyzer, however.)
>> This just for reference.
>>
>> I still thinking about the wisdom of using streamers in general for
>> things like geometry parameters. There are pros and cons. More on that
>> later.
>>
>> Ole
>>
>>
>> _______________________________________________
>> Halla12_software mailing list
>> Halla12_software at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halla12_software
>>
>>
> _______________________________________________
> Halla12_software mailing list
> Halla12_software at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halla12_software
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halla12_software/attachments/20150407/28017560/attachment-0001.html 