--------------935AB0FC866C866FD4C6640E
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <35101AD0.9C2032E4@cebaf.gov>
Date: Wed, 18 Mar 1998 19:04:48 +0000
From: Will Brooks <brooksw@cebaf.gov>
Organization: Thomas Jefferson National Accelerator Facility
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i686)
MIME-Version: 1.0
To: David Rowntree <TREE@mitlns.mit.edu>
Subject: Re: breakup by material
References: <980313145938.34a000e3@mitlns.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
I have some comments which I include below:
David Rowntree wrote:
> Hello,
> There is a useful Geant option for code optimization: setting STAT 1 in the
> ffread.in file will give a breakup of the number of times important routines
> are called by the volume type.
How did you find out about this key? I found it in my manual, but there's not
adescription. Sounds very useful.
> I did that for 100 events (with AUTO 1) of the
> 2.4gev_p_q0.evt data file, and looked at the gtnext calls. A brief description
> of the results:
>
> The main geometry sections:
> Foil: 28%
> EC1: 1%
> Mini: 11%
> LAS2: 60%
>
> For foil, 70% of the time is spent in the SHD1 piece, which appears to be a 25
> cm long cone about the beamline.
>
I assume this is 'wrong.' There should be no such cone as far as I know. There was
acone a long time ago which was put in for testing purposes (like a decade ago).
More
recently the UVA people improved the beamline description, but I'm sure they
didn't
add a thick cone. It sounds like an ancient geometry element which nobody ever
bothered
to remove.
Does anybody know what cone this is ????? <<<===
> For the LAS2, 65% is spent in one of the DC volumes (roughly equal except DC1B
> which is small). About 18% in the EC, 8% in the CC, 4% in the SC, and about 6%
> in the MG+MGSR pieces (ie, the magnet).
>
I cannot understand this result, unless there is something totally inefficient in
how themagnetic field is used. If this is the case, we could try to optimize it
(as Maurik suggested
in the last meeting).
This whole picture flies in the face of the historical statement that "95% of the
GSIM time
is spent generating showers." That was the motivation for focusing on the shower
library/
parameterization.
It would be very interesting if this is all true. I will not necessarily believe
it, though, until we
run the test of electrons going only in the coil vs. electrons going into the
fiducial area. I'm generating
the input file for this.
> This appears to imply that cutting off particles in the magnet won't have a
> major effect. A little might be gained by playing with SHD1 or the DC's, but
> we mainly need a volume independent solution.
>
> -David
This looks very promising, thanks for your work.
Is anybody out there? I have gotten very few messages on the clas_gsim mailing
list. Let's hear your comments,
naive or not...
- Will
--------------935AB0FC866C866FD4C6640E--