July 18, 2008 Software
- Review minutes from July 3, 2008 Software meeting
- Updates on Geometry specified in XML (Beni Z.)
- Coding Conventions (all)
- Action Items
The meeting will be at 1:00pm in Cebaf Center F326.
To connect by telephone: 1.) dial:
800-377-8846 : US 888-276-7715 : Canada 302-709-8424 : International
2.) enter participant code: 39527048# (remember the "#")
We will attempt an EVO connection for this meeting. We have a reasonable expectation that this will work.
Attendees: David L. (chair), Mark I., Alke A., Elton S., Simon T., Beni Z., Jim S., Alex S.
EVO: Curtis M.
Updates on Geometry specified in XML
Beni gave a summary of some recent changes he's made to the XML-based simulation geometry for GlueX (see his figures above). These included:
- Re-routing the FDC cables upstream instead of downstream
- Adding an inner aluminum plate to the BCAL
- Reconfiguring the BCAL for the alternate readout scheme (3x3 for the inner section instead of 6x4)
- Rotation of CDC layers wrt one another to break up alignments
- Close packing CDC layers to improve LR resolution and fit more layers into the over CDC volume
The BCAL and CDC changes are not all committed to the repository just yet. They have been distributed to the Regina/IU folks and CMU/JLab folks respectively to run M.C. tests on first.
Beni has also made a lot of use of the ROOT tools based on the output of the hdds-root program. One "gotcha" encountered though is that ROOT will plot all volumes even if they exist in such a way that particles tracked by GEANT could never enter them. This is due to overlapping volumes or daughter values extending outside their parent.
There was also an issue with polygons used to define the FDC cables needing to be defined in ascending-z order.
It was noted that some simulations have already been performed by Regina/IU with the 4x6 readout geometry and that new ones were being planned with the 3x3 geometry. There was a question however as to whether the FDC cabling was "visible" to geant in the initial MC study of the BCAL so this should be verified before comparisons are made to the alternate readout geometry results.
Mark Ito brought up the topic of coding conventions. He suggested re-activating the list we began 2 years ago, but have not worked on since. Starter suggestions were:
- All headers should have macros defined to protected from double inclusion
- Standard output should be directed to something we define (dout?) rather than cout to allow us to develop filters/handlers later
- Exceptions should be thrown using a standard exception class
There was general agreement on these suggestions being good ones. Some follow-up is needed on the output streams and exception issues.
No one was assigned to add these to the wiki.