<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Hi All,<br>
<br>
I think the main point here is that whatever you choose to call the
objects, the string "HDDM" should not be part of the name. For example,
when we get a raw data hit from the DAQ system, we're not going to call
it DEVIOBCALHit. When you make a reconstructed photon you won't call it
DROOTBCALPhoton (or whatever your output file format happens to be
named). I don't really care what you call the object currently called
"DHDDMBCALHit", but I think the "HDDM" string provides very little
information as to the nature of its content to a new user.<br>
<br>
-David<br>
<br>
Mark M. Ito wrote:
<blockquote cite="mid:4B75633A.1000803@jlab.org" type="cite">
<pre wrap="">Folks,
A general comment: I think we should have as many classes as are needed
to conveniently express/model the physical processes in energy
deposition, detection and reconstruction. As Beni and others have
pointed out, there won't always be a one-to-one correspondence as one
goes through the processes. If you add accidentals, then the
correspondences get even more complicated. The right structure for the
classes is then highly detector dependent. Some of these classes would
be intermediate ones, not generally used, but could be useful for
detailed studies.
There might be some overhead in creating more classes; that would be a
unpleasant side effect. One could certainly go too far by
microscopically representing every subprocess (atoms with excited states
emitting photons...whoops, need more memory). But all of the steps need
to be represented somehow or another anyway. Distinct classes for
different stages (as is reasonable) would make the code easier to
understand/maintain as well.
Whether a particular object is called the "truth" or not is not really
the important issue, IMHO, as the truth has many levels.
-- Mark
On 02/12/2010 07:53 AM, Beni Zihlmann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All,
there is one more point to consider. Since we decided to go for SiPM we
also want to sum up signals from the SiPMs before
digitization. As a consequence there will be no direct relation between
the "True Hit" in a cell (single SiPM) from geant and
the digitization which has to be done after summing several SiPM first.
I am not sure if the exact number of SiPM that need
to be summed is already fixed or not.
cheers,
Beni
Hi David,
</pre>
<blockquote type="cite">
<pre wrap="">Sure there are "two levels" of truth information, I don't much see the point in having cell-level truth information though other than its one time use for doing digitization. Practically, if I want to know anything about resolution then I need the DBCALTruthShower, which *is* well named to correspond with DBCALShower. Comparing these two objects will tell me interesting things like my shower resolution and efficiency (this is why we have truth information for the user).
I'm not sure what your suggestion is... if you want to get rid of HDDM in the name then simply renaming the class DHDDMBCALHit to DBCALTruthHit can be done. I think don't see any problem with the name and organization of the other classes though, with the exception that eventually the source of DBCALHit should come from mcsmear and not the DBCALMCResponse_factory.
-Matt
On Feb 11, 2010, at 5:10 PM, David Lawrence wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Matt,
I'm invoking the 3-e-mail exchange rule and cc-ing this to the halld-cal list....
Perhaps it's just semantics. I see 2 levels of "truth" information. The first is the energy of the photon incident on the calorimeter and the second is the energies deposited in the individual detectors. The pre-smeared energy in the individual detector represents the "true energy deposited", but does not represent the "measured energy". Since it is unrealistically good, we should tag it as such. The string "HDDM" is really unrelated to whether the data is "truth" or "digitized" so doesn't serve that purpose very well.
We currently have the incident photon energy in DBCALTruthShower (which is not particularly well named either since it contains only information that exists prior to the shower occurring). Nonetheless, DBCALTruthHit doesn't overlap with that name and would seem, at least to me to be fairly descriptive of the information it contains.
The FCAL actually ends up having 3 objects:
DFCALTruthShower
DFCALHit:TRUTH
DFCALHit
The DFCALHit object is used for both "truth" hits (DFCALHit:TRUTH) and "digitized" hits (DFCALHit). This is possible since there is a 1-to-1 correspondence between the information coming from hdgeant and the digitzed values used in the reconstruction. The BCAL, as you say, has a single hit coming from hdgeant that must be turned into 2 hits before starting the reconstruction. This means you can't really recycle classes in the same way. The point being, however, that there are effectively 3 objects in the FCAL as well. The DBCALTruthHit would then just correspond to DFCALHit:TRUTH.
Regards,
-David
Matthew Shepherd wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi David,
I"m not sure 1 is possible. The truth hit and hddm hit are fundamentally different things. Truth hit is the location of a true photon that struck the BCAL, more like a truth _shower_, while HDDM hit is the energy deposition from GEANT in a single cell. This then energy deposition then has to be turned into two hits, one for upstream and one for downstream sensors. I agree this would be better done in 1.
I don't think the FCAL code behaves as you say. Note there are two classes in FCAL also: DFCALTruthShower and DFCALHit. This again, is the fundamental difference between energy deposition in a cell and clustered hits, which represent actual photons (which can then be compared to truth information).
Moving code to mcsmear is a good idea. I think I volunteered to do that, once we had an agreement on how MC smear would handle the fact that the class it read in DBCALHDDMHit (1 instance per cell) has a different structure than the class it writes out DBCALHit (2 instances per cell).
-Matt
On Feb 11, 2010, at 1:54 PM, David Lawrence wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All,
IMHO the "HDDM" was intended to indicate some type of low-level information that is contained directly in the HDDM file. I would suggest that to be more consistent with our current naming conventions that we do one of the following:
1. Rename "DHDDMBCALHit" to "DBCALTruthHit". This follows our agreed upon (and often not followed) convention to include the word "truth" in the names of objects that carry information that will not be available in the real data.
2. Re-tool things to follow the scheme used for the FCAL where there is only one class, DFCALHit, but the un-smeared objects have the tag "TRUTH" and the smeared ones have no tag. This may not be as easy (or even desirable) for the BCAL due to the double ended readout.
I would volunteer to implement 1. if there was general agreement. Implementing 2 would be better done while moving the smearing code from the reconstruction into mcsmear since it involves a little more manipulation so I'm not quite volunteering for that yet.
Again, just my opinion.
Regards,
-David
Zisis Papandreou wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Matt: thanks for clarifying this. Cheers, Zisis...
On 2010-02-10, at 8:11 PM, Matthew Shepherd wrote:
</pre>
<blockquote type="cite">
<pre wrap="">DBCALHit is the thing that most clearly resembles raw data. as this is effectively the signal coming out of a photosensor. However, DHDDMBCALHit cannot be dropped since it is needed to deliver the energy deposition in a cell (what Geant actually tracks) to the framework. In the framework, the "digitization" process is completed and the DBCALHit objects are produced.
-Matt
On Feb 10, 2010, at 6:21 PM, Zisis Papandreou wrote:
</pre>
<blockquote type="cite">
<pre wrap="">David, Matt: Any idea?
Thanks, Zisis...
Begin forwarded message:
</pre>
<blockquote type="cite">
<pre wrap="">From: Blake Leverington<a class="moz-txt-link-rfc2396E" href="mailto:leverinb@uregina.ca"><leverinb@uregina.ca></a>
Date: February 10, 2010 5:15:54 PM GMT-06:00
To: Zisis Papandreou
<a class="moz-txt-link-rfc2396E" href="mailto:zisis@uregina.ca"><zisis@uregina.ca></a>
Cc: Matt Shepherd
<a class="moz-txt-link-rfc2396E" href="mailto:mashephe@indiana.edu"><mashephe@indiana.edu></a>
Subject: Re: Fwd: BCAL objects in DANA
I'm not the one to answer this. I've never looked at that file before.
-Blake
On 10/02/10 04:57 PM, Zisis Papandreou wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi guys:
can one of you answer Elliott and cc: me?
Thanks, Zisis...
Begin forwarded message:
</pre>
<blockquote type="cite">
<pre wrap="">From: Elliott Wolin<a class="moz-txt-link-rfc2396E" href="mailto:wolin@jlab.org"><wolin@jlab.org></a>
Date: February 10, 2010 2:51:18 PM GMT-06:00
To: Zisis Papandreou
<a class="moz-txt-link-rfc2396E" href="mailto:Zisis.Papandreou@uregina.ca"><Zisis.Papandreou@uregina.ca></a>
Cc: Mark Ito
<a class="moz-txt-link-rfc2396E" href="mailto:marki@jlab.org"><marki@jlab.org></a>, David Lawrence<a class="moz-txt-link-rfc2396E" href="mailto:davidl@jlab.org"><davidl@jlab.org></a>
Subject: BCAL objects in DANA
Hi Zisis,
I see DBCALHit.h and DHDDMBCALHit.h in the repository. They are very similar. Which one represents the HDDM data the best, i.e. the one I should dump to EVIO files?
Also, can one be eliminated since they are so similar? And whatever remains should be called DBCALHit.h (drop HDDM in the name).
Thanks,
--
Sincerely,
Elliott
================================================================================
Those raised in a morally relative or neutral environment will hold
no truths to be self-evident.
Elliott Wolin
Staff Physicist, Jefferson Lab
12000 Jefferson Ave
Suite 8 MS 12A1
Newport News, VA 23606
757-269-7365
================================================================================
</pre>
</blockquote>
<pre wrap="">---
Dr. Zisis Papandreou | email:
<a class="moz-txt-link-abbreviated" href="mailto:zisis@uregina.ca">zisis@uregina.ca</a>
Department of Physics | tel. : (306) 585-5379
University of Regina | tel. : (306) 585-4149
Regina, SK S4S 0A2 | fax. : (306) 585-5659
World Wide Web:
<a class="moz-txt-link-freetext" href="http://www.phys.uregina.ca/sparro/zisis/">http://www.phys.uregina.ca/sparro/zisis/</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">---
Dr. Zisis Papandreou | email:
<a class="moz-txt-link-abbreviated" href="mailto:zisis@uregina.ca">zisis@uregina.ca</a>
Department of Physics | tel. : (306) 585-5379
University of Regina | tel. : (306) 585-4149
Regina, SK S4S 0A2 | fax. : (306) 585-5659
World Wide Web:
<a class="moz-txt-link-freetext" href="http://www.phys.uregina.ca/sparro/zisis/">http://www.phys.uregina.ca/sparro/zisis/</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">---
Dr. Zisis Papandreou | email:
<a class="moz-txt-link-abbreviated" href="mailto:zisis@uregina.ca">zisis@uregina.ca</a>
Department of Physics | tel. : (306) 585-5379
University of Regina | tel. : (306) 585-4149
Regina, SK S4S 0A2 | fax. : (306) 585-5659
World Wide Web:
<a class="moz-txt-link-freetext" href="http://www.phys.uregina.ca/sparro/zisis/">http://www.phys.uregina.ca/sparro/zisis/</a>
</pre>
</blockquote>
<pre wrap="">--
------------------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist Office: (757)269-5567 [[[ [ [ [
Jefferson Lab Pager: (757)584-5567 [ [ [ [ [ [
<a class="moz-txt-link-freetext" href="http://www.jlab.org/~davidl">http://www.jlab.org/~davidl</a> <a class="moz-txt-link-abbreviated" href="mailto:davidl@jlab.org">davidl@jlab.org</a>
[[[ [[ [[ [[[
------------------------------------------------------------------------
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">--
------------------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist Office: (757)269-5567 [[[ [ [ [
Jefferson Lab Pager: (757)584-5567 [ [ [ [ [ [
<a class="moz-txt-link-freetext" href="http://www.jlab.org/~davidl">http://www.jlab.org/~davidl</a> <a class="moz-txt-link-abbreviated" href="mailto:davidl@jlab.org">davidl@jlab.org</a>
[[[ [[ [[ [[[
------------------------------------------------------------------------
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Halld-cal mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-cal@jlab.org">Halld-cal@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-cal">https://mailman.jlab.org/mailman/listinfo/halld-cal</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Halld-cal mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-cal@jlab.org">Halld-cal@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-cal">https://mailman.jlab.org/mailman/listinfo/halld-cal</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Halld-cal mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-cal@jlab.org">Halld-cal@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-cal">https://mailman.jlab.org/mailman/listinfo/halld-cal</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist Office: (757)269-5567 [[[ [ [ [
Jefferson Lab Pager: (757)584-5567 [ [ [ [ [ [
<a class="moz-txt-link-freetext" href="http://www.jlab.org/~davidl">http://www.jlab.org/~davidl</a> <a class="moz-txt-link-abbreviated" href="mailto:davidl@jlab.org">davidl@jlab.org</a> [[[ [[ [[ [[[
------------------------------------------------------------------------
</pre>
</body>
</html>