goord / camgen Goto Github PK

The new LHAPDF-6 distribution is fully C++ and therefore much less memory-consuming and more portable than the old ones. Add a macro to detect this version and create a separate interface for it.

parni_test.cpp does not compile because it includes parni_sub.h, which, in the most recent change has been renamed to parni.h

Camgen currently fails to compile the examples; complaining about unimplemented LHAPDF functions. This can be fixed by adding the -lLHAPDF flag in /examples/Makefile.am, but this requires rebuilding the Makefiles (which for some reason fails on my computer, so I'll just hack the Makefile in the mean time).

After many events, the parni grids tend to cause segmentation faults, most likely due to rounding errors after many iterations; create a program reproducing this issue (in a tractable amount of time) and fix the bug.

The easiest way is to adopt a new 'matrix element evaluation' member function in the configurator class to be implemented, and control it with a flag.

Perhaps we can create a base class for SM,SM_base,EWSM and EWSM_base controlling the EW parameter evaluation scheme...

This should be implemented at construction of the recursive tree.

Adopt QCD- and SM-process counting test program.

Adopt a test that validates our serialization functionality: generating a new event from the same RNG key should result in exactly the same phase space point with save/load.

Adopt a test program that verifies our implementation of rapidities, transverse momenta, etc.

When calculating this process (partonic) at 14 TeV (using the SM model) without any cuts on gets the result of ~0.54e-4 pb. However calculating this cross section by hand (assuming massless particles, as does Camgen) we get ~0.60e-4 pb, which agrees with the result obtained using MadGraph 5 (also ~0.60e-4 pb) without any cuts.

MadGraph 5 however does not neglect the masses, so my first instinct to explain the difference between Camgen and MadGraph (after ensuring that alpha and other scales were equal) was that Camgen does neglect the masses, whilst MadGraph 5 does not.

Assigning a mass to the electron (and calling refresh_fermion_masses()) does not affect the cross section very much (as expected). However, assigning the muon a mass we immediately get ~0.36 pb as a result. And this result persists even if the muon mass is taken to be extremely tiny (like 1e-8 GeV, even less than the electron mass). It seems strange that the cross section with a massive muon stays at ~0.36 pb even as the muon mass is taken towards zero.

However, settings the correct masses in SM_base.h (in the default settings (now part of Chyugh) fixes everything and makes Camgen match up with MG5 and theory (~0.60 pb). But printing model_type::M_mu does still say it is zero for some reason :S Why is this?

Setting it to SM_params::M_mu (which it should be already) and calling refresh_fermion_masses(), again messes up the whole calculation (leading to ~0.40 pb). What is going on here?

So that we can use Camgen functionality inside scripts. Very nice to have...

When I set my incoming state to e+,e- (or some other incoming states, like 'gamma,gamma' or 'W+,W-') my pre-initialised estimated xsec is 0. It does work when i set my initial state to f.i. 'u,ubar'.
I'm working with the SM model with all masses turned on.
I've tried:
-Several different outgoing states (f.i. 'u,u,ubar,ubar', 't,tbar' and '4xgamma')
-With and without electron mass
-The initial_state set to partonic and eplus_eminus
-With and without minimal invariant masses
-With and without ps-cuts
-Different colour/helicity/phase_space-generators

Should we reviewed after N_in and N_out are removed and const static caculation data is removed from models...

Implement the full numerical formula, compare to the numeric approximation and optimize performance.

Rewrite code using C++-11 new syntactic sugar (auto, templated typedefs,...), replace MC-generators with new STL generators, replace our vector<T,N> with STL array<T,N>.

...and use it in the s-branching and t-branching generators.

In the implementation of the d_R function of ps_gen_base.h the difference in dphi is calculated using:

phi(1) - phi(2)

However this is not entirely correct. Consider for example phi(1) ~= pi and phi(2) ~= -pi. In that case the dphi according the the current implementation would be ~2pi, instead of the more correct ~0. It might be a good idea to add a dedicated d_phi function because there is already a d_eta one.

The cross section for non-trivial processes changes with the number of events. One gets different results for the cross section for 1e5, 1e6 and 1e7 events. Even without any cuts or adaptive grids.

For example for C C > A A A A where C and A are two new scalars with trivial couplings AAh0 and CCh0h0 and where h0 is the normal Higgs boson with a mass of 125 GeV. A and C are stable with a small mass.

(The reason for the new particles was to isolate any strange couplings causing the effect.)

I have sent an example code for this some times ago, I only list the bug so we don't forget about it ;)

Needs to be investigated first.

Both partonic and hadronic initial states, where possible testing with forward and backward s-generation and including and excluding adaptive grids.

ps channel adapt crashes with a floating point exception if throw_pos_weight_event() consistently returns false and adapt_channels() is entered.

Camgen should end operations (after printing an error or something), after all, there is nothing to adapt.

The SM_test test fails gauge invariance at W+W- > W+W- if continuous colors are switched off. If they are on; the test also seems to fail,l but only later, for W+W- > Z,Z,Z.

The dependence on colors is a bit strange since neither process involves particles with a color charge.

I checked this with Daan; and it exists both for the current version and the previous one.

Using set_first_beam_energy and set_second_beam_energy in a configuration file seems to work very strangely. If having a partonic initial state the beams get set correctly, even if asymmetric.

However asymmetric beams in combination with the proton_proton initial state leads to odd behaviour. For example, setting beam 1 to 700 GeV and the second one to 70000 GeV, leads to Camgen reporting the following during a run:

initial state: pp_y
beam energy -1: 1400
hadron -1: 2212
beam energy -2: 1400
hadron -2: 2212
Ecm: 28000
PDF set: cteq6l.LHpdf
PDF nr: 1
mu_F: 91.1876
alpha_s: 0.117981

The beam energies are not correct; and they are symmetric (which they shouldn't). Also the Ecm is not correct. (This is for g,g > b,bbar,b,bbar by the way).

Implement the full numerical formula, compare to the numeric approximation and optimize performance.

In evt_gen.h
line 447

up_to_date never gets set to 'false' when calling generate()
,which gives an issue when calling cross_section_sum() (line 744) more than once

These phase space variables seem to be missing.

Would like to move const static data coloured, Dirac_algebra_type, colour_treatment, continuous_helicities, continuous_colours, spin_vector_type, beam_direction from model to separate class. Details must still be specified...

Causes long compile times whereas the gain in performance is likely to be marginal: this is a very big refactoring and will require a new dynamic bitset and replacement of all bitset algorithms.

'Engine generators' have no need for cross sections, errors etc. so we can save memory there.

Adapt the examples to compile under the new Camgen version and create new useful examples.

Create separate factories for uniform and tree phase space generators, so that we do not need to instantiate all classes in each test.

when looking at a mixed coloured/colourless process, like for instance the process "u,ubar -> e-,e+,g",
uni_cols.h line 214 will divide by the colourtensor rank of e-, which is 0, which in turn leaves the colour weight to be infinite.

This error can be reproduced by changing the following in the "example1.cpp" file:
-- Change all 'QCD' to 'SM'
-- Change "colour(int)" to "colour_entry(int)"
-- Change "colour_generators::flow_sampling" to "colour_generators::uniform"
-- Change process from "g,g > g,g,g,g,g,g,g,g,g,g" to "u,ubar > g,g,g,g,g,g,g,g,e+,e-"
-- Add a line at the end of main that prints the total wight of the generated event: "std::cerr << "ERROR -- the weight now is: " << gen.w() << std::endl;"

This issue seems to appear for more functions in uni_cols.h

After migrating to C++-11.