| FairPrimaryGenerator [message #16480] |
Wed, 30 April 2014 13:28  |
Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI
|
first-grade participant |
From: *gsi.de
|
|
Hi,
when using an EvtGen decay file with a PDG code not in TDatabasePDG, FairPrimaryGenerators prints for every single decay some warning like
-W FairPrimaryGenerator: PDG code 88880 not found in database. This warning can be savely ignored
Is there a (verbose-)switch which allows to suppress this warning? If not, would it be possible to implement something to get rid of this warning?
Best and thanks,
Klaus
|
|
|
|
|
|
| Re: FairPrimaryGenerator [message #16499 is a reply to message #16498] |
Wed, 30 April 2014 18:08  |
Klaus Götzen
Messages: 293
Registered: June 2006
Location: GSI
|
first-grade participant |
From: *gsi.de
|
|
Hi Malte,
a temporary workaround is to add a line like
TDatabasePDG::Instance()->AddParticle("pbarpSystem0","pbarpSystem0",fIni.M(),kFALSE,0.1,0, "",88880);
for each of the unknown PDG codes in the beginning of the fast sim or analysis macro.
Concerning the generator filter, there actually is something in preparation for at least multiplicity cuts, but I don't believe that you will be able to cut on combined invariant masses on that level.
Best,
Klaus
|
|
|
|
|
|
|
|
| Re: FairPrimaryGenerator [message #16506 is a reply to message #16501] |
Fri, 02 May 2014 11:53 |
MartinJGaluska
Messages: 203
Registered: March 2010
Location: Germany
|
first-grade participant |
From: *physik.uni-giessen.de
|
|
As an addition to my last post (which I wrote on my cell phone and therefore wanted to keep short):
For the user-defined event filters which are foreseen for more complex filtering than on single particle multiplicities I had the idea to convert all TParticle which are generated from the event generators and convert them into RhoCandidate which is a PANDA specific solution and will not be adopted by other experiments. The idea is that PANDA users will be able to use all the tools from analysis also for writing user-defined specific event filters.
As this is PANDA specific we have developed the general event filter part first which can be used by all FairRoot based frameworks (I hope). We might add the missing functionality later, but time is an issue, of course. All we actually need is a FillList method that takes the TParticles from the generators and puts them into a TClonesArray of RhoCandidate with some added functionality to take wrong PID assignments into account. We might be able to reuse code which already exists for the "fast simulation", however. I assume the rest (like Combine and so on) will work without modifications for the user-defined event filters as they do for the analysis.
For now, all you can do without writing that FillList method and then your own event filter yourself is to use FairEvtFilterOnCounts. However, in your case you might not gain much if you only can require at least one neg. and one pos. charged particle in your events. If you can only filter on that criteria, you canonly filter out all events which do not have a positively or a negatively charged particle. I assume that there won't be many of those. With more detailed criteria you might be able to reduce the number of events better, however.
If you decide to do that you can put the following code into your sim macro:
FairPrimaryGenerator* primGen = new FairPrimaryGenerator();
fRun->SetGenerator(primGen);
PndDpmDirect *Dpm= new PndDpmDirect(mom,1);
primGen->AddGenerator(Dpm);
// now add the event filters (in our case only non-veto filters)
// only accept events with at least one pos. and one neg. charged particle
FairEvtFilterOnCounts* min1pos1neg= new FairEvtFilterOnCounts("min1pos1neg");
//min1pos1neg->SetVerbose();
min1pos1neg->AndMinCharge(1,FairEvtFilter::kPlus); // events with min. 1 pos. charged particles will match and will be selected
min1pos1neg->AndMinCharge(1,FairEvtFilter::kMinus); // events with min. 1 neg. charged particles will match and will be selected
primGen->AddVetoFilter(min1pos1neg);// regular non-veto filter with higher priority than regular event filter
The same behavior can also be achieved with a veto filter:
FairPrimaryGenerator* primGen = new FairPrimaryGenerator();
fRun->SetGenerator(primGen);
PndDpmDirect *Dpm= new PndDpmDirect(mom,1);
primGen->AddGenerator(Dpm);
// now add the event filters (in our case only a veto filter)
//veto events without pos. charged particles
FairEvtFilterOnCounts* noPlusVeto= new FairEvtFilterOnCounts("noPlusVeto");
//noPlusVeto->SetVerbose();
noPlusVeto->AndMaxCharge(0,FairEvtFilter::kPlus); // Actually it does not matter for the first filter whether it is set with And... or with Or...
noPlusVeto->OrMaxCharge(0,FairEvtFilter::kMinus); // events with max. 0 pos. OR max. 0 neg. charged particles will match and will be vetoed
primGen->AddVetoFilter(noPlusVeto);// veto filter with higher priority than regular event filter
Kind regards,
Martin
PS: I have simplified the example code for the veto filters.
[Updated on: Sat, 03 May 2014 16:11] Report message to a moderator |
|
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
