[Halla12_software] another point about geometry API.

[Ole Hansen]

On 04/07/2015 02:46 PM, Richard S. Holmes wrote:
> 
> On Tue, Apr 7, 2015 at 1:28 PM, Thomas K Hemmick
> <hemmick at skipper.physics.sunysb.edu
> <mailto: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.
> 
> 
> I don't think there are any advocates of not using GEANT4 for
> simulation, are there?
> 
> Am I correct in understanding major portions of the Hall B framework
> (but not all their software) are written in Java?
> 
> I have never learned Java, and have in the past decade or so used only
> C++, Perl, and Python, so personally have a very strong preference for a
> C++ based framework. 
> 
> As for ROOT, I certainly think we can write a simulation package that
> doesn't use it. Digitization as well, I think, and probably
> reconstruction. For analysis, on the other hand, I see it as essential.
> But as long as the ROOT toolkit is available in the analyzer, I guess I
> can see that the entire framework does not need to be built around ROOT. 
> 
> But if ROOT gives us tools that will make it easier to attain our
> requirements, that certainly argues strongly in its favor.
> 
> 
> I think it's premature to advocate for any one or another framework.
> First we need to get a clear picture of our requirements, and of the
> available alternatives.
> 

I agree with all of Rich's points completely.

Ole


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ole.vcf
Type: text/x-vcard
Size: 321 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/halla12_software/attachments/20150407/808d3022/attachment.vcf