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

[Zhiwen Zhao]

On 12/15/2010 9:27 PM, Seamus Riordan wrote:
> 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.
I agree the text file based input is reasonable choice now. Didn't gemc start 
with text file as input? If so, can it still have the option and how hard is it 
to adopt some format Seamus will create? I will leave if we want to put close to 
final geometry in database format as an open question.
>
> 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.
I think some study of the LCDD from SLAC and HDDS from hallD code may be helpful.
>
> 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.
I am working on the POISSON program.
>
> 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
>
>