Crash on Sherpa 1.4.5 when generating events

[danilo.ferreiradelima@glasgow.ac.uk]

Dear Sherpa experts,

I have prepared a run card for bbjj (in this case Order_QED = 0) and the integration step runs fine, but I get the following error when generating events at some point.

This also happened previously in Sherpa 2.1.0, so it does not seem to be related to the Sherpa version. Could you let me know why this happens? Is this a serious problem or can I use the events which have already been generated?

The Run.dat file has been attached.

Best regards, Danilo

Decay_Channel::GenerateKinematics(a_{2}+(1320) --> pi+ rho(770) ): Rejected

decay kinematics 10000 times. This indicates a wrong maximum. Will accept

kinematics. Decay_Handler_Base::TreatInitialBlob:("Initial particle f_{2}(1270) not ons hell: p^{2=1.275 vs. m}2=1.275") Polarization_Vector::Polarization_Vector:("Undefined for p.Abs2()=1.626 and

m2=1.626")

Exception_Handler::SignalHandler: Signal (6) caught.

Cannot continue.

Exception_Handler::GenerateStackTrace(..): Generating stack trace {

0x3981e32925 in 'gsignal' 0x3981e34105 in 'abort' 0x7f48f6ba51f8 in 'METOOLS::Polarization_Vector::Polarization_Vector(ATO

OLS::Vec4<double>, double, bool, bool)' (Polarization_Tools.C:31)

0x7f48f6ba532f in 'METOOLS::Polarization_Tensor::Polarization_Tensor(ATO

OLS::Vec4<double>, double, bool, bool)' (Polarization_Tools.C:98)

0x7f48f6bc2084 in 'METOOLS::TSS::Calculate(std::vector<ATOOLS::Vec4<doub

le>, std::allocator<ATOOLS::Vec4<double> > > const&, bool)' (Flavour.H:234)

0x7f48f650da71 in 'HADRONS::Generic::Calculate(std::vector<ATOOLS::Vec4<

double>, std::allocator<ATOOLS::Vec4<double> > > const&, bool)' (stl_vector .h:533)

0x7f48f7ac311b in 'PHASIC::Decay_Channel::ME2(std::vector<ATOOLS::Vec4<d

ouble>, std::allocator<ATOOLS::Vec4<double> > > const&, bool, METOOLS::Spin _Density*, std::deque<ATOOLS::Particle*, std::allocator<ATOOLS::Particle*>

const&)' (stl_vector.h:533)

0x7f48f7ac3e69 in 'PHASIC::Decay_Channel::Differential(std::vector<ATOOL

S::Vec4<double>, std::allocator<ATOOLS::Vec4<double> > >&, bool, METOOLS::S pin_Density*, std::deque<ATOOLS::Particle*, std::allocator<ATOOLS::Particle *> > const&)' (Decay_Channel.C:245)

0x7f48f7ac44d5 in 'PHASIC::Decay_Channel::GenerateKinematics(std::vector

<ATOOLS::Vec4<double>, std::allocator<ATOOLS::Vec4<double> > >&, bool, METO OLS::Spin_Density*, std::deque<ATOOLS::Particle*, std::allocator<ATOOLS::Pa rticle*> > const&)' (Decay_Channel.C:329)

0x7f48fef1340e in 'SHERPA::Decay_Handler_Base::FillOnshellDecay(ATOOLS::Blob*, METOOLS::Spin_Density*)' (stl_deque.h:790) 0x7f48fea8b556 in 'SHERPA::Hadron_Decay_Handler::FillOnshellDecay(ATOOLS::Blob*, METOOLS::Spin_Density*)' (Hadron_Decay_Handler.C:107) 0x7f48fef14fb5 in 'SHERPA::Decay_Handler_Base::FillDecayTree(ATOOLS::Blob*, METOOLS::Spin_Density*)' (Decay_Handler_Base.C:235) 0x7f48fea88e8e in 'SHERPA::Hadron_Decay_Handler::FillDecayTree(ATOOLS::Blob*, METOOLS::Spin_Density*)' (Hadron_Decay_Handler.C:100) 0x7f48fef178c1 in 'SHERPA::Decay_Handler_Base::TreatInitialBlob(ATOOLS::Blob*, METOOLS::Amplitude2_Tensor*, std::vector<ATOOLS::Particle*, std::allocator<ATOOLS::Particle*> > const&)' (Decay_Handler_Base.C:178) 0x7f48fef0e92a in 'SHERPA::Hadron_Decays::Treat(ATOOLS::Blob_List*, double&)' (stl_vector.h:132) 0x7f48feef3a64 in 'SHERPA::Event_Handler::IterateEventPhases(double&)' (Event_Handler.C:179) 0x7f48feef52ef in 'SHERPA::Event_Handler::GenerateStandardPerturbativeEvent(SHERPA::eventtype::code&)' (Event_Handler.C:234) 0x7f48feef6d9d in 'SHERPA::Event_Handler::GenerateEvent(SHERPA::eventtype::code)' (Event_Handler.C:124) 0x7f48ffaf6891 in 'SHERPA::Sherpa::GenerateOneEvent(bool)' (Sherpa.C:254) 0x4022ad in 'main'

} Exception_Handler::Terminate(): Pre-crash status saved to '/afs/phas.gla.ac.uk/user/d/dferreira/atlas_data/hh02/bbaa/bkg145/bbjj/bbjj_QCD/StatusWed_Jun_25_18-20-16_2014'. n Event_Handler::Finish : Summarizing the run may take some time. +--------------------------------------------------------+ | | | Total XS is 1.38887e+06 pb +- ( 135030 pb = 9.72 % ) | | | +--------------------------------------------------------+

---

Please cite the publications listed in 'Sherpa_References.tex'.

Extract the bibtex list by running 'get_bibtex Sherpa_References.tex' or email the file to ​'slaclib2@slac.stanford.edu', subject 'generate'.

---

Exception_Handler::Exit: Exiting Sherpa with code (2)

[danilo.ferreiradelima@glasgow.ac.uk]

Run card for bbjj generation.

[danilo.ferreiradelima@glasgow.ac.uk]

Hello,

I can add some more information to this: this seems to happen occasionally (it depends on the random seed, I assume) in all set of events I'm generating and showering. It seems to happen regardless of the process (bbjj, bbja, jbaa, etc) and on the hadron decays step. I can still use the output files, but I wonder if this creates a bias on the samples, since it seems that some configurations of hadron decays cause this crash.

Please, let me know if you have any suggestions.

Best regards, Danilo

[Frank Siegert]

Dear Danilo,

I can reproduce this, and it's related to a naive absolute numerical comparison which breaks when using high energies like in your 100 TeV example. I am attaching a patch which fixes this and at the same time removes an abort() to avoid unnecessary crashes due to this. You can apply it with

  cd SHERPA-MC-2.1.1
  patch -p0 < polvector.patch
  make install

Can you try with that and let me know if it fixes your problem?

Cheers, Frank

[danilo.ferreiradelima@glasgow.ac.uk]

Hello Frank,

thanks a lot for investigating this. I am unfortunately using Sherpa 1.4.5, simply because this version was lying around and I have already generated other samples with it and I prefer to use a single Sherpa version for all my samples for consistency. I do not expect that there will be a problem to apply this patch by changing manually these two lines in Polarization_Tools.C, but let me know if you think the behaviour of the two versions will be different.

Also, the integration step of many processes take a very long time and I'm worried if this is related with this issue or not (many events could be rejected for failing this requirement or another one which is not well suited for sqrt(s) = 100 TeV). For example, p p > b b j j +0/1 jet using Comix (ie: 93 93 -> 5 -5 93 93 93{1}; Order_EW = 4; with CKKW. See the full Run.dat in the end of this comment) takes 10 days do integrate and I have been running it for 4 days now and still waiting, but there are 5 days left according to the Sherpa printout. Other processes, like bbjj with different orders in the number of QED vertices, jbaa (using the HEFT and Amegic for the latter one, though) and bbja (also using HEFT and Amegic for this one). This seems very unreasonable and probably means that the event generation will be slow.

If you think these two problems are unrelated, I can open a new ticket, but just in case you have a brilliant guess in the mean time.

Cheers, Danilo

(run){

EVENTS 1000; FILE_SIZE 50000; PRETTY_PRINT Off; OUTPUT 2; EVENT_GENERATION_MODE Weighted; RESULT_DIRECTORY=Results; GENERATE_RESULT_DIRECTORY 1; #PARTICLE_CONTAINER 98 CEjets 5 -5; MASSIVE[5]=1; MASS[25]=125.; CORE_SCALE QCD; MAX_PROPER_LIFETIME=10.0;

}(run)

(beam){

BEAM_1 = 2212; BEAM_ENERGY_1 = 50000; BEAM_2 = 2212; BEAM_ENERGY_2 = 50000;

}(beam)

(model){

MODEL = SM;

}(model)

(processes){

Process 93 93 -> 93 93 5 -5 93{1}; CKKW sqr(40/E_CMS); Order_EW 4; Selector_File *|(coresel){|}(coresel) {4}; End process;

}(processes)

(integration){

Error = 0.10; Integrator = 2;

}(integration)

(me){

ME_SIGNAL_GENERATOR = Comix; SCALES VAR{(Abs2(p[2]+p[3]+p[4]+p[5]))}; # removing this does not help

}(me)

(mi){

MI_HANDLER = Amisic # None or Amisic

}(mi)

(coresel){

NJetFinder 4 30 0 0.3 -1 3.0 10.0;

}(coresel)

[Frank Siegert]

Hi Danilo,

yes, it should be fine to simply change the corresponding lines also in Sherpa 1.4.5.

The integration time and results will be completely unaffected by this patch, so this would be a separate issue. At a quick glance, I'm not 100% sure whether INTEGRATOR=2 is suitable for all processes that you are using it for. Did you take this from an example?

Please let me know whether the proposed patch fixes the original issue, such that I can close this ticket.

Cheers, Frank

[danilo.ferreiradelima@glasgow.ac.uk]

Hi Frank,

thanks. I'm trying it now.

About the other problem, I mentioned, changing the integrator type is also not helpful. It was an attempt to solve the issue. I'll create another ticket for this and let you know about the result of the tests with this patch.

Cheers, Danilo

[danilo.ferreiradelima@glasgow.ac.uk]

Hello Frank,

the error now does not cause a crash, but it generates the same message as before and much more often. It seems that the new criteria makes this stricter, but removing the abort() line allows it to go on.

I don't mind keeping this as it is, as long as the messages below are not very serious and removing the abort() call will not cause problems later in the showering.

Cheers, Danilo

Polarization_Vector::Polarization_Vector:("Undefined for p.Abs2()=0.5929 and m2=0.5929") Polarization_Vector::Polarization_Vector:("Undefined for p.Abs2()=0.803 and m2=0.803") Polarization_Vector::Polarization_Vector:("Undefined for p.Abs2()=0.5929 and m2=0.5929") Polarization_Vector::Polarization_Vector:("Undefined for p.Abs2()=3.553e-15 and m2=0") Polarization_Vector::Polarization_Vector:("Undefined for p.Abs2()=0.803 and m2=0.803") Polarization_Vector::Polarization_Vector:("Undefined for p.Abs2()=0.5929 and m2=0.5929") Polarization_Vector::Polarization_Vector:("Undefined for p.Abs2()=0.5929 and m2=0.5929") Polarization_Vector::Polarization_Vector:("Undefined for p.Abs2()=0.5929 and m2=0.5929")

[Frank Siegert]

Hi Danilo,

The patch makes it stricter but only in the relative comparison, so I would have hoped that this fixes the 100 TeV issues. But I should have normalised not to the sum of the masses, but include the energy to capture any numerical instabilities from large momenta.

I'm attaching an updated patch, hopefully this gets rid of the warnings now.

Thanks for following up on this! Frank

[danilo.ferreiradelima@glasgow.ac.uk]

Hello Frank,

thank you. The new patch avoids the excessive error messages. I suppose this can be closed.

Best regards, Danilo

[Frank Siegert]

Thanks for the feedback! I have committed this to the rel-2-1-1 SVN branch and also included it for future Sherpa releases.