Holly,
Not having access to your detector model or input particle spectrum I simply generated single muons into the ECal from the target. I have attached a spectrum of deposited energy sorted by particle type. There were contributions from a few other oddball pdg IDs, but I have plotted only the energy loss from the primary muon and the secondary electrons and photons. I believe it qualitatively reproduces your original plot.
To store information from each Geant4 step and investigate further using your detector and your events, please
create a Geant4 macro (e.g. settings.mac) with the following line:
/lcio/PDGFlag true
Then run slic with your usual arguments but appending " -m settings.mac " .
The additional information should now be available in your lcio file.
This is a very verbose setting, so I suggest you use this only for your muon sample. Electrons will very quickly
produce enormous output files.
Norman
________________________________
From: Holly Vance <[log in to unmask]>
Sent: Monday, September 8, 2014 12:32 PM
To: Uemura, Sho
Cc: McCormick, Jeremy I.; Graf, Norman A.
Subject: Re: MC Thresholds
Thanks Sho,
I was able to get the PDG output for all hits-all correspond to muons (no electrons). The plot looks the same as the one I sent earlier.
I am still uncertain about the distance between this low energy peak and the minimum ionizing peak in addition to the peak of low energy tails I observe when I fire single energy electrons. Any other thoughts about from where this low energy peak arises?
On Mon, Sep 8, 2014 at 3:17 PM, Sho Uemura <[log in to unmask]<mailto:[log in to unmask]>> wrote:
The PDG id field in SIOSimCalorimeterHit is not necessarily filled, and is not filled in our SLIC files (maybe there's a SLIC command that turns that on or off). So it makes sense that this doesn't work for you.
I think you should still be able to do hit.getMCParticle(0).getPDGID().
On Mon, 8 Sep 2014, Holly Vance wrote:
Hi all,
Jeremy,
What you wrote makes perfect sense, but I am getting a null pointer
exception as there is nothing in the getPDG(i) call (for any hit). I can
use getContributedEnergy(0). The return for all hit.getMCParticleCount() is
always 1 so I think all I am seeing is that the hit passing through the
crystal is what is giving this energy to the individual hit.
I am still not sure how to go about separating these hits by PDG id. Any
other thoughts on this low energy pile-up/tail?
On Fri, Sep 5, 2014 at 2:03 PM, McCormick, Jeremy I. <
[log in to unmask]<mailto:[log in to unmask]>> wrote:
Even without the detailed output enabled, hit contributions should still
be grouped by PDGID in the ECAL hits. You should be able to distinguish
different types of energy depositions using the SimCalorimeterHit interface.
You can use this interface to iterate over the contributions for a hit:
http://www.lcsim.org/sites/lcsim/apidocs/org/lcsim/event/SimCalorimeterHit.html
The (rather poorly named) getMCParticleCount() method will get you the
number of indices so you can do something like?
for (int i=0; i<hit.getMCParticleCount(); i++) {
int pdg = hit.getPDG(i);
double e = hit.getContributedEnergy(i);
// etc.
}
Then you can see which types of particles are contributing energy to the
hit.
Does it make sense?
The detailed output is available if you set in a slic macro
?/lcio/PDGFlag true? but that is probably overkill as it results in one
contribution for each simulation step. I don?t think you should need to do
that but it is helpful for debugging sometimes.
On Sep 5, 2014, at 8:22 AM, Graf, Norman A. <[log in to unmask]<mailto:[log in to unmask]>>
wrote:
Good Morning Holly,
Will do.
Norman
------------------------------
*From:* Holly Vance <[log in to unmask]<mailto:[log in to unmask]>>
*Sent:* Friday, September 5, 2014 8:13 AM
*To:* Graf, Norman A.
*Cc:* McCormick, Jeremy I.; Uemura, Sho
*Subject:* Re: MC Thresholds
Hi Norman,
I'm a little uncertain how to do this since what I am generally working
with are in the contents of the ECalHits collection. I see when I look
under MCParticle the PDG ID, but these results in this plot are all from
the hit readout in the ECal. Please let me know if you find any use in
saving a little more GEANT history. I am still hoping this might explain
the gap between these two peaks.
On Fri, Sep 5, 2014 at 12:22 AM, Graf, Norman A. <[log in to unmask]<mailto:[log in to unmask]>>
wrote:
Hi Holly,
This looks reasonable to me. The low energy peak and tail under the MIP
peak
are explicit delta rays produced in the energy loss process.
Please segregate the
entries in this plot by PDG ID. My prediction is that you will have muons
contributing to the MIP peak and electrons producing the continuum which
peaks towards zero.
I'll try to find some time to double-check this hypothesis. We may have
to enable
some switches in slic to save more of the Geant4 history.
Norman
------------------------------
*From:* Holly Vance <[log in to unmask]<mailto:[log in to unmask]>>
*Sent:* Thursday, September 4, 2014 5:28 PM
*To:* Graf, Norman A.; McCormick, Jeremy I.
*Cc:* Uemura, Sho
*Subject:* MC Thresholds
Hi Norman, Jeremy,
I am having a strange issue with my readout using cosmics and
scintillators. By directly reading out the output energies of cosmic rays
passing through the calorimeter (no thresholds or noise), I receive the
following attached plot. Some of this makes sense to me because of course
we have our minimum ionizing peak. What concerns me is the peak at 0. This
peak goes away when I require that there is only one hit in a given row (as
expected).
However, my problem is that I don't understand why there is a very
separated peak at low energy. Is there some inherent threshold in the monte
carlo that could be causing this? I would expect this to be more continuous
as energy is shared amongst crystals in a given row.
I also see a similar pile-up just above 0 energy for my studies where I
fired single energy electrons at the face of the ecal, but these were all
removed with a 7.5 MeV threshold.
A sample file is on jlab at: /work/hallb/hps/holly/B_p45_0.slcio
Any advice or ideas you have on this would be greatly appreciated. I've
CC'd Sho on this e-mail as we were discussing this issue earlier.
--
Respectfully,
Holly
------------------------------
NOTE: This message was trained as non-spam. If this is wrong, please
correct the training as soon as possible.
Spam
Not spam
Forget previous vote
--
Respectfully,
Holly
------------------------------
NOTE: This message was trained as non-spam. If this is wrong, please
correct the training as soon as possible.
Spam
Not spam
Forget previous vote
--
Respectfully,
Holly
--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------
NOTE: This message was trained as non-spam. If this is wrong,
please correct the training as soon as possible.
Teach CanIt if this mail (ID 03MMHiBth) is spam:
Spam: https://www.spamtrap.odu.edu/canit/b.php?i=03MMHiBth&m=8e65a341207e&t=20140908&c=s
Not spam: https://www.spamtrap.odu.edu/canit/b.php?i=03MMHiBth&m=8e65a341207e&t=20140908&c=n
Forget vote: https://www.spamtrap.odu.edu/canit/b.php?i=03MMHiBth&m=8e65a341207e&t=20140908&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS
--
Respectfully,
Holly
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
