View source for Thought on solid gemc developing

by Zhiwen

* As in the last meeting, we had some discussion about how we should develop solid simulation using gemc. here are some thoughts I had since then.

* Ideally, it would be nice to use gemc as toolkit like geant4. Then we can follow its production version and mind our own simulation only. Unfortunately, from my experience, gemc is not written as a toolkit like geant4, but it does have modularized ways to be used for different projects.

* The main concern I see that we don't want to develop in gemc's own svn tree is that we are afraid that someone we don't know may break the code and render it unusable. One way out of this is certainly compiling a production version of gemc as a library as Seamus has setup the nice example. Another way I think would be simplily have tagged production release of gemc. Suppose we have a working copy of gemc lib, but then when we want to use latest gemc with new feature (many of them could be crucial to us as we are requesting changes and improvement in gemc), we find out it's somehow broken. Then what we can do is either retreat to the working lib, but it's not a long term solution. or We need to figure out a way to debug gemc or ask others to debug it. Then the reference we have is a lib which don't have version control, or we have a local checkout of the source code we used to built the lib which doesn't have a tag and hard to ask others to compare and debug. So as you can see, a tag production version of source code is essential in this case, and we don't really need a lib for this purpose because it can be built out from the tagged version anytime.

* Another reason to use a gemc lib I see is if we need additional things for solid which has to replace some of gemc main code. Some of them could be
** 1. database io. now they are just scripts and txt files, not any part of actual gemc source code. solid scripts reside in a separated directory and use some base scripts provideed by gemc. Take them out doesn't really give us any advantage. And the disadvantage is whenever gemc improves the base scripts (Mauri is thinking about some major improvement), we need to update. This is extra work to keep this mirror copy sync to the master and then we sync to the mirror.
** 2. hit processing. solid hit processing is in a separated directory. Although it needs to be compiled with gemc code, it has no conflict with other hit process like clas12. And it can take existing hit process from clas12 or modify it or write a totally new ones. It's by design of gemc. I think taking them into our own svn tree only doing the same thing with additional work.
** 3. physics list. as I mentioned in last meeting minutes (copied below), I tend to use gemc physics list for solid and keep improve on it. Unless there's something so particular to solid and Mauri doesn't want the change in the main code, we will have to do one of two things, either try to modularized the physics list and put a solid list, or fork gemc as source/library. but for now, I can't think how that will happen. "from last meeting note --- gemc can use many GEANT4 physics list directly, refer to https://gemc.jlab.org/gemc/Documentation/Entries/2011/2/14_GEMC_Physics_Options.html . Mauri has also built the gemc physics list by following GEANT4 physics definition with jlab physics in mind. there's no special treatment for just clas12, meant to be general. Any improvement would be welcome."

* Overall, I think develop solid simulation in gemc tree is not only an easier way, but also a better way as far as we make production release often. Adopting gemc greatly speeds up our solid simulation development, but we can't or shouldn't just use it as a toolkit. We have to give up the ideas of not involving and be responsible for gemc main code because there are changes and features Mauri can't spend a lot time to provide in the years to come. And no matter Mauri leaves the collaboration (God forbids) or not, we can't just reply on others for support. (Of course, for the early stage, we want to go through Mauri for any change.)