1) CalcHEP/bin/par_scan in updated. One can can add keyword "Widths" to the list of contrtains which should be printed. Then for earch parameter set CalcHEP will calculate widths of all particles and store them in decaySLHA_#.txt file. File number # is presented in "Widths" column ot output file.
1) We used mouse click outside of menu to exit menu. Now double click is used for it. It is done to avoid unwanted exit of menu at first click on CalcHEP window.
The Esc key and mouse click in top-left corner of menu also lead to exit of menu as in previous versions.
2) We have improved diagnostic of exceeding of maximum number of models in one working directory.
3) We have improved 2 bugs in kinematics.
The first one appeared in calculation 2->1 processes with masseve partons. It was caused by using structure function with x parameter defined in CMS system : x=p_parton/p_hadron in CMS. Now x is subsequenntly defined in the infinite momentum system.
The second bug appeared in calculation of collision of ISR electron with a fixed momentum particle. Calculation of cross section of two ISR elections was done correctly.
4) We had a bug in sum_dist routines which leaded to segmentation fault.
We have solved problem of compatibility with Pythia for events generated by electron beam.
(10.03.2020) Release 3.8.2
1) High precision calculation. Now CalcHEP supports calculation of matrix elements with quadruple precision for gcc compiler.
In the previous version of CalcHEP quadruple precision was supported only by icc compiles. In the new version double, long double and quadruple precision
are supported with the 'long double' type as a default.
Calculations with 'long double' precision are as fast as calculations with
double precision but 10-byte numbers are used for 'long double' (versus 8-bytes ones for 'double precision'), providing up to four decimals gain in precision. So, it is reason
long double as default for numerical calculations. Quadruple precision uses 16-byte real numbers providing
up to 32 precision decimals.
Precision of calculation in CalcHEP is specified in the file
include/nType.h which contains the following lines
#define _LONG_ to use long double type in numerical calculations
//#define _QUADICC_ quadruple precision for icc compiler.
//#define _QUADGCC_ quadruple precision for gcc
When all three lines are commented out, CalcHEP will use double precision. Please note, that default gcc on MAC does not support quadruple precision. To specify compiler which will used by CalcHEP one has to define environment variable CC. If CC variable is not defined, CalcHEP will use 'clang' for MAC and 'gcc' for other operating systems. Details on quadruple precision for icc and gcc can be found at
respectively. Please note that in case of quadruple precision, it will be used only for numerical evaluation of matrix elements (because there one expects potential cancellations), while numerical integration (the choice of the phase space points) is done at the double precision level.
2) We have updated calculations with incoming massive polarized fermion particles which cleaned small bugs detected in previous versions:
a) the sign of polarization was defined differently in massive and massless cases;
b) we had a bug which becomes noticeable in case of large fermion mass. Improved code was tested and compared with WHIZARD by MCSANC groupe (Dubna)
3) We have significantly improved procedure of the compilation of executable n_calchep for numerical calculation which saves significant
amount of time for big jobs involving many diagrams
and many particles in the final state:
a) we use now parallel compilation;
b) now we do not update libraries during the compilation;
c) we use dynamic libraries instead of static ones which allows to compile multi-GB code if necessary. The modification above allows evaluated complicated process with five and six particles in the final state either on PCs or clusters.
4) We have updated CalcHEP batch script to accommodate the repective changes above and have included the following new features:
a) now CalcHEP supports "SLHA Widths on/off" option which is relevant for the case when user uses external SLHA file for the input of the model parameters and would like to cross check results by using widths form the SLHA file or the widths from CalcHEP evaluation. To use such an option in the batch regime, one should use the key phase:
"SLHA widths: On"
"SLHA widths: On"
b) Now one cause use an option
"Reuse Session: True"
"Reuse Session: Flase"
key phase to improve accuracy in the next run of the batch. This option is very relevant in case of large jobs at PC clusters which has a limited time quota. In case the job is killed by the system one would not lose results if uses an option above in the next run which with "Reuse Session: True" key work would simply use the grid of the MC calculation created in the previous run and would further improve the accuracy of the calculation and/or generate events (if requested)
c) in the new version of batch, CalcHEP creates separate sub-folder for each job in "batch_results" folder, which is more convenient for user's access and result analysis.
(28.02.2019) Release 3.7.5
1) run_batch is slightly improved
(08.12.2018) Release 3.7.4
1) Form output. Bugs fixed : symb/out/form_out.c
2) Detection of duplicate names in var#.mdl and func#.mdl. Bug is fixed : symb/read_mdl.c
3) Decay branching is sorted now.
4) aPrintF works correctly even if "long double" or "_Quad" is chosen for real numbers. aPrintF routine is intended to write input file for spectrum calculator from within func#.mld. It is similar to fprintf function and its first arguments defines format of reading of other arguments. For real argument one of flags E,e,G,g,f,F has to be used, which corresponds to double numerical type. Now when CalCHEP performs numerical calculations with other types, earch real argument of aPrintF is automatically converted to type double: X => (double)(X). : symb/out/reader_c.c
5) Polarization of incoming photon in case when second incoming particle is massive. Bug is fixed: symb/symbolic.c
6) External matrix element. We have realized a possibility to use CalcHEP numerical integrator with external matrix element. We assume that the uses has compiled some processes in CalCHEP but would like to replace CalcHEP squared matrix element on his own one. See instructions in c_source/num/usrSQME_dummy.c