Re: updated geometry

[David Lawrence <davidl@jlab.org>]

Hi All,

    Just to put in my $0.02 here. The reason we keep the hddGeant.F file 
in the repository in addition to the XML is due mainly to my own strong 
voiced aversion to "package creep". A few years ago, it was unclear to 
me that we would be needing Xerces for anything other than to convert 
the XML to fortran or C files. And, more importantly, how often the 
common user would need to do this. As a general rule, I still believe we 
need to set the bar very high for bringing in 3rd party packages.

    That being said, I  agree that Xerces has now met that threshold. 
Actually, I decided this a few months back when I used Xerces as the 
interface to the XML geometry access in the Hall-D reconstruction code. 
It has actually been required for a little while now. In fact Matt S. 
just brought up this very point 2 days ago that maybe we should remove 
the derived files from the repository and force regeneration by everyone 
who checks out the source. Given all of this, I would support the 
proposal that we remove hddsGeant3.F from the repository and keep only 
the XML source.

    Someone (I think I heard Mark volunteer) will need to make the build 
system robust enough so that this is not completely confusing to 
novices. Specifically, if one runs make in the HDGeant directory when no 
hddsGeant3.F file exists, it either automatically generates one by 
running make in the ../hdds directory, or prints a clear message telling 
the user to do this.

    I am not yet at the point of supporting a similar move with the HDDM 
system since that requires yet another package (XALAN) and the HDDM XML 
files are modified even less often than the geometry ones.

    Finally, I will restate that I believe the best way to manage the 
3rd party packages is through the built-in package management systems 
that every semi-modern OS has. The class of users who merely wish to run 
the software will clearly be served well by this and those of us doing 
fresh installs will benefit as well. It will allow us to make as 
complicated of dependency chain as we want without changing the 3 or so 
lines of installation instructions for newbies.

    I would be interested if others have opinions on this.

Regards,
-David

Mark M. Ito wrote:
> Beni,
>
> Thanks for getting that done. Sounds like real progress.
>
> This brings up a code management issue that I have been wondering 
> about for some time. It seems like we have a two step process: 
> check-in new xml-based geometry information, then, by hand, generate 
> the corresponding Fortran GEANT code, then check in the fortran code. 
> This procedure violates the usual philosophy of only checking in 
> "source" materials and allowing a make system to generate "derived" 
> materials. It seems to have lead to some confusion about what we have 
> in the Monte Carlo vs. what we have in the geometry. And I suspect 
> some of the build problems I have had recently have to do with trying 
> to maintain both "source" and "derived" in the Subversion repository.
>
> My naive proposal is that we remove the Fortran GEANT code from the 
> repository and regenerate it as part of the make system. Then one is 
> guaranteed consistency between geometry specification and code. Also 
> (if this can be done) a user can modify the geometry and use it 
> immediately in the Monte Carlo without having to know the details of 
> how to generate the Fortran code, i. e., play with a private version 
> of the geometry without becoming an expert. Is there some fundamental 
> problem with this? Too computationally expensive? Too many "helper" 
> applications to install? Also, I have no idea how complicated it is to 
> generate the Fortran code given you have everything you need installed.
>
> On the subject of helper applications, I think we should be able to 
> put together enough documentation and scripts to install them on most 
> systems, especially if the applications are coming to us from 
> experienced/professional programmers.
>
> What do you and others think?
>
>  -- Mark
>
> Beni Zihlmann wrote:
>> Dear colleagues,
>> I updated the geometry in the repository. The geometry now reflects
>> all the changes and design decisions that have been made lately.
>> 1) remove outer most CDC layer thereby reducing the CDC radius by 1.6 cm
>>    including the cable runs.
>> 2) re-route the FDC cables to run upstream
>> 3) add an 8mm aluminum plate on the inside of the BCAL
>> 4) the BCAL readout segmentation is 4x6 (sector x layer)
>>
>> all these changes are now available the in geometry file hddsGeant3.F 
>> located in
>> src/programs/Simulation/HDGeant/
>>
>> cheers,
>> Beni
>>

-- 

------------------------------------------------------------------------
  David Lawrence Ph.D.
  Staff Scientist                 Office: (757)269-5567   [[[  [   [ [       
  Jefferson Lab                   Pager:  (757)584-5567   [  [ [ [ [ [   
  http://www.jlab.org/~davidl     davidl@jlab.org         [[[  [[ [[ [[[
------------------------------------------------------------------------