Linear Collider Forum



Today's Messages (off)  | Unanswered Messages (on)

Forum: Reconstruction
 Topic: 250 GeV DBD samples
question.gif  250 GeV DBD samples [message #2349] Sat, 20 December 2014 02:51
poeschl
Messages: 22
Registered: June 2004
Location: LAL Orsay
Dear Colleagues,

we would like to look at b quark production in the 250 GeV samples as produced for the DBD, e.g.

lfc-ls /grid/ilc/prod/ilc/mc-dbd/ild/rec/250-TDR_ws/2f_Z_hadronic/I LD_o1_v05/v01-16-p10_250

We are wondering whether these files were produced with or without gamma gamma background. I assume that they are with the background as there is nowhere a corresponding label. Does there exist also files w/o gamma gamma background? From a quick scan through the grid directories, I could not figure out corresponding files but maybe I have missed something.

We (or better said Sviatoslav) are capable of running the reconstruction ourselves but would of course prefer centrally produced files.

Thanks in advance for advice and help and Merry Christmas,

Roman
 Topic: RecoMCTruthLinker
RecoMCTruthLinker [message #2222] Fri, 09 March 2012 07:42
grenier
Messages: 13
Registered: June 2008
Location: LYON
Hi,

I don't know what the RecoMCTruthLinker processor is doing in details.
In the standard config (ILDConfig v02-00), it is used and it requires a collection of LCRelation between the SimCalorimeterHit and the Calorimeterhit.

In my setup, I'm producing one LCRelation for HCAL and one for ECAL. So to feed the RecoMCTruthLinker properly, I need to merge these 2 collections in one.

Is there a processor that can do such a merge ?
 Topic: Matching
Matching [message #1814] Wed, 22 July 2009 06:54
bweinert
Messages: 16
Registered: September 2008
Location: University of Rochester
Hi, I tried to create a matching program between virtual hits and real hits in order to get the tracks. I did this by trying to match the cartesian coordinates, but it doesn't seem to produce the right results. It only matches a few hits every few events. Is there anything wrong with the code?

-Ben

double [] VirtPos = new double [3];
.
.
.

VirtPos[0] = rpVect[0];

VirtPos[1] = rpVect[1];


VirtPos[2] = rpVect[2];

VirtPosList.add(VirtPos);
.
.
.

if(subdetName.equals(hcalSubdetName))
{
List<CalorimeterHit> hits = null;
try {
hits = event.get( CalorimeterHit.class, hcalHitmapName);
}
catch (Exception e) {}
if(hits==null) return;

for( int i = 0; i<hits.size(); ++i ) {
CalorimeterHit ihit = hits.get(i);
matchHitsXYZ(ihit.getPosition());}
}
.
.
.

else if(subdetName.equals(ecalSubdetName))
{
List<CalorimeterHit> hitsE1 = null;
try {
hitsE1 = event.get( CalorimeterHit.class, ecalHitmapName);
}
catch (Exception e) {}
if(hitsE1==null) return;

for( int i = 0; i<hitsE1.size(); ++i ) {
CalorimeterHit ihit = hitsE1.get(i);
matchHitsXYZ(ihit.getPosition());}
}
.
.
.

protected void matchHitsXYZ(double [] realPos)
{

AIDA aida = AIDA.defaultInstance();
int nhitsTotal = 0;

// loop through virtual hits
for (double [] virtPos : VirtPosList) {

if (((realPos[0])-1)<=virtPos[0] && virtPos[0]<=((realPos[0])+1))
{
if(((realPos[1])-1)<=virtPos[1] && virtPos[1]<=((realPos[1])+1))
{
if( ((realPos[2])-1)<=virtPos[2] && virtPos[2]<=((realPos[2])+1))
{
System.out.println("Matched Hit at: (" + realPos[0] +","+ realPos[1] +"," +realPos[2] +")");

aida.cloud2D("Y vs. X Matched").fill(realPos[1], realPos[0]);
MatchedPosList.add(realPos);
foundHits.add(new BasicHep3Vector(realPos[0], realPos[1], realPos[2]));

nhitsTotal++;
MatchedPosList.add(realPos);
System.out.println("Number of virtual hits : " + VirtPosList.size() + " Number of real hits : " +nhitsTotal);
}
} }
}
}

 Topic: A naive question about the output of marlin.
A naive question about the output of marlin. [message #1666] Wed, 17 December 2008 23:35
fengy
Messages: 15
Registered: September 2008
Location: IU
Hi all,

Sorry for bothering you with such a naive question, but which part of the output of marlin are the reconstructed particles?

I saw a several reconstructed particles classified by jets, but couldn't see an overall list.

I am using the ilcsoft-1.5.02 release, with stdreco.xml and a mumuh event file.

The output is dumpped with dumpevent. (Are there any better way to examine the outputs?)


Yu
 Topic: reconstruction particles
reconstruction particles [message #1502] Thu, 12 June 2008 04:37
rwaliczek
Messages: 6
Registered: April 2008
Location: Institute of Nuclear Phys...
Hello everybody,
I am a student at Institute of Nuclear Physics in Cracow and I am trying to get some information from my collections. I simulated e+e-->ttbar beam at 500GeV in CMS (pythia generator + mokka).Now I`m studying Marlin and I need some help about this software. I used a "example_steering_file_LDC01_05Sc.xml" from $ILCSoft/PandoraPFA folder. I obtain "output_file.slcio" which has a lot of collections.
My questions are the following:

1. I need information about momentum reconstructed particles. I know that this info include "MCParticle" collection(getMomentum()), but there is info about simulated particles, which caused hit. Where can I obtain info about momentum reconstructed particles in order to histogramming and compare with simulated?

2. I understand that all "Sim.." collections are simulated from Mokka and using to other processors as primary input collections to further reconstruction. There is info about position (getPostion())- Does this function return "x,y,z" or "r,phi,z" in polar coordinate system?

3. Can I get info about momentum particles from "TrackerHit" and "Track" collections? Do exist any method to compute it from this collection?

4. In "ReconstructedParticle" collection I find a getMomentum() function, but there is only few low energy particles(pi+,pi-,neutrons,photons) - Is it correct?? Does collection "ReconstructedParticle" is the only, which contain reconstructed particles from name? i.e. Does Pandora is such intelligent that can reconstructed W+W- bosons from ttbar and tell me: there are W bosons Smile??

5. How can I obtain total energy distribution reconstructed particles? Which collections include such information?

The last most lamers question: What kind of information I can get from reconstructed collection (what is the most ineteresting in this type of simulations: e+e- -> ttbar)?

Thanks in advance

[Updated on: Thu, 12 June 2008 04:42]

 Topic: org.lcsim Tracking Examples
org.lcsim Tracking Examples [message #1170] Wed, 03 October 2007 12:35
benjeffery
Messages: 5
Registered: June 2006
Location: Oxford

Hi,
Can anyone point me to examples of how to use the various tracking options in org.lcsim? For example which ones work well together and are relatively mature and how to swap in cheating etc?
Thanks,
Ben
 Topic: How to get calorimeter cell indices from a segmentation class?
How to get calorimeter cell indices from a segmentation class? [message #396] Mon, 05 December 2005 12:37
lima
Messages: 47
Registered: May 2004
Location: DeKalb, IL, USA
Hi,

I am trying to develop the neighbour finding code in the non-projective endcaps (GridXYZ segmentation class). For testing, I am using sidaug05_tcmt geometry with some muons in the endcaps, and using the NearestNeighborClusterDriver. As expected, the GridXYZ.getNeighbourIDs() method gets called. So far so good.

Inside this method, I need to know what are the cell IDs, ilay,ix,iy, so I have this piece of code:

--------------------------
public long[] getNeighbourIDs(int layerRange, int xRange, int yRange)
{
System.out.println("Nonproj neighbs: "+ layerRange+" "+xRange+" "+yRange);

int klay = this.getValue("layer"); // <== NullPointerException
System.out.println("klay="+klay);
int kx = this.getValue("x");
int ky = this.getValue("y");
int kz = this.getValue("z");
System.out.println("NeighborID: ref="+klay+" "+kx+" "+ky+" "+kz
+" (hex "+Long.toHexString(saveID)+")");
----------------------------------

The line indicated produces a NullPointerException.
What's the right way of retrieving the cell indices from inside GridXYZ.getNeighbourIDs() method?

Thanks,
Guilherme
 Topic: DigiSim announcement
DigiSim announcement [message #323] Fri, 05 August 2005 13:15
lima
Messages: 47
Registered: May 2004
Location: DeKalb, IL, USA
Dear colleagues,

We would like to announce the "release" of DigiSim for wider use within the org.lcsim framework. Please find the updated documentation posted at http://nicadd.niu.edu/digisim . There are usage instructions in the documentation.

We are currently trying to adapt the NearestNeighborCluster algorithm to do clustering using the digitized CalorimeterHits instead of using the SimCalorimeterHits. I will post another announcement when this example is ready.

Please note that an update of the C++ version will be made available later, hopefully in few weeks.

Cheers,
Guilherme
 Topic: Calorimeter Optimization for LC Detector Concepts
Calorimeter Optimization for LC Detector Concepts [message #274] Fri, 27 May 2005 14:57
SMagill
Messages: 1
Registered: May 2005
I have looked at several HCAL options, comparing both absorber and active media types.

I first compared HCAL versions with identical scintillator readout, one version had 0.7 cm W absorber per layer and one had 2 cm SS as the absorber. In both versions, the HCAL was 4 nuclear interaction lengths thick, 55 layers of W/Scin compared to 34 layers SS/Scin. My specific finding was that the W/Scin HCAL performed better than the SS/Scin HCAL both for single particle energy resolution and for PFA results - both perfect PFA and the actual algorithm. Showers in W were more compact than showers in SS - confirming results I had seen from H. Videau earlier. My main motivation for this study was to see if a more compact HCAL could be built using a dense absorber, thus saving R**2 which presumably contributes to the cost of the magnet. My general conclusion was that not only was this goal achieved, but that the W/Scin HCAL even performed better (PFA and single particles) than the SS version.

Next I looked at 2 version of HCAL with W absorber, one with scintillator and one with RPC as active media. Both of these were analyzed as digital calorimeters. My specific findings here were that the W/Scin digital HCAL and the W/RPC digital HCAL had similar performance as determined by calculating perfect PFA. The scintillator version had slightly better PFA resolution, presumably because of the higher number of hits per GeV for neutrals which, in digital mode, translates directly into better resolution.

Despite this, the SiD detector concept chose as its HCAL 2 cm SS absorber with RPC readout. I then looked at the perfect PFA performance of this detector and found that it performed worse than both the W/Scintillator and the W/RPC HCALs. In fact, the SiD combines the absorber with worse properties with the active media with fewer hits, so it was no surprise that the perfect PFA performance was so poor. In fact, it is impossible to obtain 30%/sqrt(E) resolution for the SiD detector with this option.

I then made suggestions as to how the performance of the SS/RPC HCAL could be improved based on all of my observations and found that these improvements led to a larger volume for the HCAL. I then suggested that maybe the optimal use of RPCs (generally gas HCAL) would be found in a larger volume, lower B-field detector concept than the compact, higher B-field SiD. It seems to me, supported by the simulated detectors that I analyzed, that the optimal HCAL configuration for a compact, high B-field detector should have a dense absorber combined with a solid (or maybe liquid) active media. This optimizes (means minimizes) the outer radius of the HCAL which directly saves magnet costs as mentioned above while maintaining good resolution for the neutral component of jets. Of course, things like transverse segmentation and the minimum calorimeter radius affect the final PFA performance of the detector and are used to ultimately determine if a particular concept is viable - but, as I showed, the best perfect PFA performance I got for a compact, high B-field detector was with a W/Scin HCAL. It also seems to me that there might be a different optimal HCAL for the compact detector than for a large, low B-field detector. I wouldn't be surprised if it turned out that a W or SS/RPC HCAL would be a good choice for the LDC detector and that a W/Scintillator HCAL would be better for the SiD. I would recommend that the LDC consider a 0.5 cm W or 1 cm SS absorber/1.2 mm RPC per layer HCAL. A 4 lambda deep HCAL of this construction would have 77 layers of W/RPC or 67 layers of SS/RPC and would be ~100 cm or ~120 cm from IR to OR respectively. By thinning the absorber, I think the resulting neutral particle resolution obtained in a PFA would allow the 30%/sqrt(E) goal to be obtained.
 Topic: Nonprojective calorimeter support
Nonprojective calorimeter support [message #271] Thu, 26 May 2005 04:24
lima
Messages: 47
Registered: May 2004
Location: DeKalb, IL, USA
Hello,

I got some time to work on the non-projective geometry in org.lcsim + GeomConverter. I was wondering what is the current status and what needs to be done at this point. My goal is to be able to do PFA studies on org.lcsim framework. Your suggestions and comments are welcome.

Thanks,
Guilherme
 Topic: Condtions Data framework
Condtions Data framework [message #185] Mon, 31 January 2005 02:01
gaede
Messages: 232
Registered: January 2004
Location: DESY, Hamburg
Hi,

I just posted a proposal for a condtions data framework to the Prototypes/Calorimetry forum. As this software might be interesting for a wider audience, e.g. TPC groups, I am posting a reference here as well:
http://forum.linearcollider.org/index.php?t=msg&goto=184 &rid=6#msg_184

Frank.


Current Time: Mon Jun 18 00:47:41 Pacific Daylight Time 2018
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software