[Halla12_software] the big question and some hints on running gemc

[Seamus Riordan]

I don't think the mysql interface with gemc is the right approach for 
SoLID.  We need to be able to make changes quickly and easily in a local 
way, and having to load that up on on mysql server for each iteration is 
cumbersome.  This is especially true when we know we're going to have to 
do many versions, they have to be done iteratively, independently, and 
I'd like straightforward reproducibility (with text files!).  That 
approach works well for Hall B because they have a relatively stable and 
large geometry base, few developers, and dozens of users.  We are 
unstable (undefined!), not nearly as big in numbers of volumes, have few 
people working with it, and our developer/user ratio is close to 1.

On the other side, I've taken the idea I had at the end of the meeting 
yesterday and did some serious work on it.  I'm think I'm close to 
writing a perl interface for the geometry specification, so we could 
write all of the geometry as a perl subroutine (with any of perl's 
features), which is then used as the input to the main program.  I've 
already worked out some prototype code where I can create persistent 
class objects on the heap in an embedded perl interpreter, pass them 
back to the main C++ program, and then use them exactly as if they were 
created in the C++ code.  I'm hoping to have at least a subset of the 
necessary geometry construction classes working by the end of the week.

If I can get this approach seriously going I think it will be enormously 
powerful.  However, my fear is I'm creating an unholy and bizarre 
abomination of code since I'm doing some perverse things in regards to 
memory management.  I also fear that Geant4 may have some complicated 
design practices that could be prohibitive of this approach.

Having a working version of the simulation by the end of January is a 
reasonable goal.  On my side I intend to have the geometry, generic 
detectors, and input/output going by then.  The POISSON magnetic fields 
will need to be implemented.  The rest is actually evaluating SoLID 
designs and implementing specific event generators.

Best,
Seamus

Wouter Deconinck wrote:
> On Wed, Dec 15, 2010 at 7:30 PM, Zhiwen Zhao <zwzhao at jlab.org> wrote:
>   
>> Then before I can run it, I trick the gemc to think I have libssl.so.8
>> and libcrypto.so.8 by a link
>> "ln -s /usr/lib64/libssl.so.10 libssl.so.8"
>> "ln -s /lib64/libcrypto.so.10 libcrypto.so.8"
>>     
>
> You are a software developer's nightmare!  While it might work in the
> short run, there is a reason why those libraries are versioned.  I
> strongly denounce that practice!  I have wasted many days on bugs
> introduced that way.  And it's always the physicists who do this.
>
>   
>> Mauri:
>>     
> Sorry I missed the meeting on Tuesday, but in the last slide that you
> sent around you seemed to indicate that magnetic field support has to
> wait until January.  Did I misunderstand that from the slide?  For
> Moller at least this will be very important to have in the short term,
> unless we keep on using the other Geant4 code for the toroid design.
> What is the status of magnetic field support right now?
>
> Cheers,
> Wouter
>   


-- 
Dr. Seamus P. Riordan			riordan at jlab.org
University of Massachusetts, Amherst    Office: (757) 269-5289
Post-doctoral Research Associate	Pager:  (757) 584-0051

CEBAF Center A103, Jefferson Laboratory
12000 Jefferson Ave.
Newport News, VA 23606