GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Analysis » Lambda Lambdabar simulations
Lambda Lambdabar simulations [message #16309] Tue, 15 April 2014 12:10 Go to next message
Karin Schönning
Messages: 65
Registered: August 2012
Location: Uppsala University
continuous participant
From: *physics.uu.se
Yesterday's meeting (which I regret I could not follow to the end) triggered some discussion on the Lambda Lambdabar channel and in particular the acceptance in the forward direction. Donghee has suggested it may be improved if the requirement of all four final state particles being reconstructed in the final state. This is probably true but I don't think this is the reason for the discrepancy with the physics book results (or the thesis of Sohie Grape where the details are given). Sophie required all final state particles (but no paricle ID), vertex fit of both Lambda and Lambdabar, mass cuts of the same and also a tree fit for pbar p -> Lambdabar Lambda. On the other hand, pandaroot was not used for these results but only the old, BABAR based framework. It is of course much less realistic but I would be surprised if it causes something as significant as the forward acceptance. I am also looking into the Lambdabar Lambda channel now and will check if I reproduce Donghee's findings.
Re: Lambda Lambdabar simulations [message #16312 is a reply to message #16309] Tue, 15 April 2014 13:03 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Again,
in the fast sim there is a cut of p>500MeV/c in the forward tracker. This is most probably the reason of the loss in efficiency at such forward angles.
Re: Lambda Lambdabar simulations [message #16316 is a reply to message #16312] Tue, 15 April 2014 14:21 Go to previous messageGo to next message
donghee is currently offline  donghee
Messages: 385
Registered: January 2009
Location: Germnay
first-grade participant
From: *dip0.t-ipconnect.de
Hi Stefano,

pmin=0.5 exchanged by pmin=0.1 (100MeV/c)
The result, at least, the shape looks pretty much same for both min values.

index.php?t=getfile&id=7809&private=0
Re: Lambda Lambdabar simulations [message #16317 is a reply to message #16316] Tue, 15 April 2014 14:23 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
I would suggest to verify the phase space for each particle in the lab frame, before CM.
Re: Lambda Lambdabar simulations [message #16318 is a reply to message #16316] Tue, 15 April 2014 14:51 Go to previous messageGo to next message
Klaus Götzen is currently offline  Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI
first-grade participant
From: *adsl.alicedsl.de
Hi Donghee,


do you have the folders rho, fsim, PndTools/AnalysisTools, and macro/scrut exactly as they are in the latest version of scrut14? Just to make sure that this effect really comes from the current version and is no strange artifact from several updates and modifications ...

You could also replace the trackers in fast sim by a single one with almost perfect momentum reco and 100% efficiency like

fastSim->AddDetector("ScSttAlone", "thtMin=0. thtMax=160. ptmin=0.0 pmin=0.0 pRes=0.01 thtRes=0.001 phiRes=0.001 efficiency=1.0");


and check whether the acceptance then is as expected.


Best,
Klaus
Re: Lambda Lambdabar simulations [message #16319 is a reply to message #16316] Tue, 15 April 2014 15:19 Go to previous messageGo to next message
Bertram Kopf is currently offline  Bertram Kopf
Messages: 110
Registered: March 2006
continuous participant
From: *ep1.ruhr-uni-bochum.de
Hi Donghee,

one specific issue of the analysis of this channel is the long lifetime of the lambda particle. For the Physics Book studies we therefore defined the lambda as a stable particle in the event generator. The decay has been considered afterwards in the GEANT simulation. Therefore my question:
How are such long living particles treated in the fast simulation?
Are the displaced vertices properly reconstructed? The path length of the lambda is in the order of several cm up to appr. 1 meter! BTW: By applying a cut on this path length of more than a few cm it should be possible to get rid of most of the background events. As Karin already mentioned, cuts on PID information seem to be not necessary for this channel.

Best regards,
Bertram.

Re: Lambda Lambdabar simulations [message #16320 is a reply to message #16319] Tue, 15 April 2014 15:27 Go to previous messageGo to next message
Karin Schönning
Messages: 65
Registered: August 2012
Location: Uppsala University
continuous participant
From: *physics.uu.se
The distance between production and decay vertex for Lambda look about the same in the fast and the full simulations, so I think it is properly treated also in the former.
Re: Lambda Lambdabar simulations [message #16331 is a reply to message #16318] Wed, 16 April 2014 10:30 Go to previous messageGo to next message
donghee is currently offline  donghee
Messages: 385
Registered: January 2009
Location: Germnay
first-grade participant
From: *kph.uni-mainz.de
Hi,

The lambda-lambdabar data has been tested with phase space mode and in addition a special detector has been introduced to see acceptance behaviour of anti-lambda as you suggested.
Quote:

fastSim->AddDetector("ScSttAlone", "thtMin=0. thtMax=160. ptmin=0.0 pmin=0.0 pRes=0.01 thtRes=0.001 phiRes=0.001 efficiency=1.0");

Efficieny increase clearly, since the reconstructed distribution is not scaled any more.
But still acceptance is going down at cos(theta) = -1 and 1.

I think that the pure acceptance can be understood with a V0 decay. If the lambda or lambdabar decay far from the target region, daughter tracks could not be reconstructed. It leads to drop down of acceptance because forward boosted lambdabar(or lambda) flight a long distance.
As far as I understand, all track candidates defined in the fast simulation are coming closely from target region.

index.php?t=getfile&id=7812&private=0

Best wishes,
Donghee
Re: Lambda Lambdabar simulations [message #16332 is a reply to message #16331] Wed, 16 April 2014 10:47 Go to previous messageGo to next message
Karin Schönning
Messages: 65
Registered: August 2012
Location: Uppsala University
continuous participant
From: *physics.uu.se
A drop in the acceptance was observed also in the old simulations with the BABAR framework, see the attached figures from Sophie's thesis. So, there is a drop nera -1 and 1, but the acceptance is not zero. In fact, it does not look very different from the plot you just posted.
  • Attachment: sophie.eps
    (Size: 21.67KB, Downloaded 371 times)
Re: Lambda Lambdabar simulations [message #16334 is a reply to message #16319] Wed, 16 April 2014 11:00 Go to previous messageGo to next message
donghee is currently offline  donghee
Messages: 385
Registered: January 2009
Location: Germnay
first-grade participant
From: *kph.uni-mainz.de
Hi Bertram,

Quote:

How are such long living particles treated in the fast simulation?

In full simulation, we could not handle correctly V0 decay, because of no V0 track reconstruction at this moment as it is well known.
Therefore acceptance for lambda and lambdabar is quite poor and roughly below 20% without any PID application.
In the fast simulation, the situation seems to be same. If lambda and lambdabar has a long distance life time, then we do not chance to reconstruct those track in the fast simulation, too.

Quote:

For the Physics Book studies we therefore defined the lambda as a stable particle in the event generator. The decay has been considered afterwards in the GEANT simulation.

Your comment about stable mode in EvtGen is very interesting for me, You mean that we can also use stable mode in EvtGen generator.
I know the stable mode for lambda or K_s in DPM, but I have never heard such handling in EvtGen.

Presently in my EvtGen generator frame, lambda-lambdabar has been produced and allow directly charged decay mode(to proton and pion).
Then all final state particles are transfered to the GEANT.

Could you tell me about difference between you and my approach?

Best wishes,
Donghee








Re: Lambda Lambdabar simulations [message #16336 is a reply to message #16334] Wed, 16 April 2014 12:19 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
The difference is that if in EvtGen you set the lambda/lambdabar as stable particles, you let them decay in GEANT, so that you can have also the interaction with materials, pipe, MVD and so on. In the latter case protons and pions become secondary particles and are not primaries.

So far I have never seen somebody showing full (and correct) lambda analysis in panda, in this sense this "acceptance below 20%" should be checked better.
Re: Lambda Lambdabar simulations [message #16338 is a reply to message #16331] Wed, 16 April 2014 12:28 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
I have not understood what this plot should tell you.
If you keep a hole in the backward angle for sure you will have holes at 1 and -1, since with phase space the distribution is simmetric.
Again, I suggest to verify the phase space for each particle in the lab frame, before CM. And with the correct model.
Re: Lambda Lambdabar simulations [message #16339 is a reply to message #16336] Wed, 16 April 2014 12:29 Go to previous messageGo to next message
donghee is currently offline  donghee
Messages: 385
Registered: January 2009
Location: Germnay
first-grade participant
From: *kph.uni-mainz.de
Dear Stefano,

I agree, if we don't have a V0 track finder during this campaign, the correctness will never be achieved.
However, I believe that acceptance and efficiency will be improved after getting or handling V0 tracks in the future.

Best wishes,
Donghee
Re: Lambda Lambdabar simulations [message #16352 is a reply to message #16338] Thu, 17 April 2014 14:56 Go to previous messageGo to next message
donghee is currently offline  donghee
Messages: 385
Registered: January 2009
Location: Germnay
first-grade participant
From: *kph.uni-mainz.de
Dear Stefano,

I want to show you theta distribution for anti-proton and pi+ from the antilambda decay in the lab frame.
Each 2D plots show that thata_antiproton vs theta_pion in the lab frame for the case of generated and reconstructed.

I used LambdabarLambdaPol 1.64GeV model and a perfect detector, which covers from 0 to 160 degree with perfect resolution and efficiency.
In each panel, you can find the dependence of theta_{lab} distribution on the different cos(theta)_{CM} region.
I think that Panel2(Right up) is quite important clue for the acceptance lost.
In lab frame, theta between 0 and 7 degree we could not reconstruct at all, due to V0 decay topology.

index.php?t=getfile&id=7814&private=0
index.php?t=getfile&id=7815&private=0

Best wishes,
Donghee
Re: Lambda Lambdabar simulations [message #16353 is a reply to message #16352] Thu, 17 April 2014 15:03 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 93.48.236*
Why do you cut below 7°?
Re: Lambda Lambdabar simulations [message #16357 is a reply to message #16353] Thu, 17 April 2014 16:09 Go to previous messageGo to next message
donghee is currently offline  donghee
Messages: 385
Registered: January 2009
Location: Germnay
first-grade participant
From: *kph.uni-mainz.de
Hi Stefano,

I do not apply any cuts for this distribution.
I want to understand also what is going on between 0 to 7 degree.
Whether is it lambda specific due to V0 decay or some bug in the code.

Idea behind this plot is that we can use stt alone mode, which has a best acceptance in the fast simulation.
Quote:

fastSim->AddDetector("ScSttAlone", "thtMin=0. thtMax=160. ptmin=0.0 pmin=0.0 pRes=0.001 thtRes=0.001 phiRes=0.001 efficiency=1.0");

With option "EmcBar Drc Dsc", only above STT alone will be used and can see what will happen in the acceptance.

If I use standard mode with stt+mvd+gem in addition FwSpec, the spectrum looks same, cannot find any lambdabar between 0 and 7 region.

Best wishes,
Donghee







  • Attachment: simfast_opt.C
    (Size: 12.93KB, Downloaded 243 times)
Re: Lambda Lambdabar simulations [message #16359 is a reply to message #16357] Thu, 17 April 2014 17:10 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 93.48.236*
Could you please check if these angles are covered in MCTrack?
Have you tried with the standard simfast.C macro? Maybe some bug in the _opt.C?
Re: Lambda Lambdabar simulations [message #16361 is a reply to message #16359] Thu, 17 April 2014 17:34 Go to previous messageGo to next message
Klaus Götzen is currently offline  Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI
first-grade participant
From: *dip0.t-ipconnect.de
Hi,


I'd like to add some point to the current discussion: Since the tracking detectors in Fast Sim only check for a certain theta region computed from the IP, the acceptance might be wrong for particles coming from displaced vertices. This is due to the fact, that a quite far displaced vertex in radial direction in reality could still be detected with a much smaller theta then that one calculated by connecting the detector edge with the IP. The other way around is also possible: a particle coming from a displaced vertex with large z position could miss the detector even with a theta value being in the acceptance range.

To overcome this limitation, one would need many more geometry parameters for each detector, therefore it was not taken into the initial design of the Fast Sim.


Best,
Klaus
Re: Lambda Lambdabar simulations [message #16368 is a reply to message #16359] Fri, 18 April 2014 10:52 Go to previous messageGo to next message
donghee is currently offline  donghee
Messages: 385
Registered: January 2009
Location: Germnay
first-grade participant
From: *dip0.t-ipconnect.de
Dear all,

I want to inform you that the lost acceptance in very forward direction (0-7 deg) in lambdabar analysis has been fixed by Stefano and Klaus.
It turns out that Fts part was not correcly put into the task. Now it was fixed and the spectrum looks fine.
Thanks to Stefano, you corrected my wrong guess/interpretation during the discussion, finally we direct now a corret way.

To make sure, again I used ideal detector and suggested lambdabar model for generator. A distribution for cos(theta)_{CM} of lambdabar has been plotted. No serious acceptance lost at all.
I would like to close this topic if you agree.
Thanks for all great help

index.php?t=getfile&id=7822&private=0

Re: Lambda Lambdabar simulations [message #16369 is a reply to message #16368] Fri, 18 April 2014 11:01 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
One problem less...
Re: Lambda Lambdabar simulations [message #16437 is a reply to message #16368] Thu, 24 April 2014 11:39 Go to previous messageGo to next message
Karin Schönning
Messages: 65
Registered: August 2012
Location: Uppsala University
continuous participant
From: *physics.uu.se
By ideal detector, do you mean this:
fastSim->AddDetector("ScSttAlone", "thtMin=0. thtMax=160. ptmin=0.0 pmin=0.0 pRes=0.001 thtRes=0.001 phiRes=0.001 efficiency=1.0");
?
If I use that, I get no acceptance loss, but if I use the default (or what was given in the simfast.C file obtained from the checkout, i.e.
fastSim->AddDetector("ScSttAlone", "thtMin=145. thtMax=159.5 ptmin=0.1 pmin=0.0 pRes=0.04 thtRes=0.001 phiRes=0.001 efficiency=0.25")Wink
I do get severe losses in the forward and backward region.

Or rather, what option did you use to produce this picture?
Re: Lambda Lambdabar simulations [message #16441 is a reply to message #16309] Fri, 25 April 2014 02:00 Go to previous messageGo to next message
donghee is currently offline  donghee
Messages: 385
Registered: January 2009
Location: Germnay
first-grade participant
From: *dip0.t-ipconnect.de
Hi Karin,

I used option below one(ideal or super detector mode) to produce angular distribution plot, which I posted.
fastSim->AddDetector("ScSttAlone", "thtMin=0. thtMax=160. ptmin=0.0 pmin=0.0 pRes=0.001 thtRes=0.001 phiRes=0.001 efficiency=1.0");

If I use standard detector mode, I have also loss of acceptance.
I am sorry if you are confused due to my posting.
The problem was that the forward spectrometer was not involved and make too much drop down in cos(theta) ~ 1 region.
Now the forward spectrometer is set correctly and the cosine distribution drop down steadily as I expected.

Is it correct answer to you?
Best regard,
Donghee
Re: Lambda Lambdabar simulations [message #16444 is a reply to message #16441] Fri, 25 April 2014 12:41 Go to previous messageGo to next message
asanchez is currently offline  asanchez
Messages: 350
Registered: March 2006
first-grade participant
From: *kph.uni-mainz.de
Dear All,

I'm simulating the production of Lambda Lambda_bar from p_bar + Nucleus interacction.
For that I use GiBUU files as input for the generator.

My question is the following, is the decay of primary particles active within the fast simulation?
BTW, I'm using the scrut14 and the macro/scrut macros and classes.


thank you in advance
and best regards
Alicia S.
Re: Lambda Lambdabar simulations [message #16445 is a reply to message #16444] Fri, 25 April 2014 12:56 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *ip70.fastwebnet.it
In fast simulation there is no decay inside, you should let your generator decay your particles.
Re: Lambda Lambdabar simulations [message #16446 is a reply to message #16445] Fri, 25 April 2014 13:04 Go to previous messageGo to next message
asanchez is currently offline  asanchez
Messages: 350
Registered: March 2006
first-grade participant
From: *kph.uni-mainz.de
Do you mean, by doing this

// ------------- switch off the transport of particles
primGen->DoTracking(kTRUE);

??

Re: Lambda Lambdabar simulations [message #16447 is a reply to message #16446] Fri, 25 April 2014 13:06 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *ip70.fastwebnet.it
No, I mean in your generator. No idea if GiBUU let lambdas decay.
Re: Lambda Lambdabar simulations [message #16448 is a reply to message #16447] Fri, 25 April 2014 13:57 Go to previous message
asanchez is currently offline  asanchez
Messages: 350
Registered: March 2006
first-grade participant
From: *kph.uni-mainz.de
Well, it is a pity
that at least the decay does not work
for primaries.

thank you for the info

regards
Alicia.
Previous Topic: Vertex Fitter in Fast simulation
Next Topic: [FIXED] Problems with analysis: PidAlgoMvd not found in Tree
Goto Forum:
  


Current Time: Wed Nov 27 21:01:47 CET 2024

Total time taken to generate the page: 0.01224 seconds