MATRIX：全差分NNLO计算框架与强子对撞机过程分析

20 浏览量更新于2024-07-16 收藏 1.52MB PDF 举报

"《使用MATRIX的全差分NNLO计算》是Massimiliano Grazzini、Stefan Kallweit和Marius Wiesemann等人发表于Eur.Phys.J.C (2018) 78:537的一篇开放访问文章，详细介绍了MATRIX计算框架，该框架用于在量子色动力学（QCD）的下一阶至下一阶（NNLO）精度下计算高能粒子对撞机上的各种过程的全差分截面。文章涵盖了涉及希格斯粒子和矢量玻色子的2→1和2→2强子反应，首次全面考虑了矢量玻色子的所有轻子衰变通道，包括共振和非共振图、脱壳效应和自旋相关性。此外，还讨论了MATRIX的自动外推程序，它使得NNLO减法程序的系统不确定性控制在极低水平。" 这篇学术论文详细阐述了MATRIX计算框架，这是一个用于高能物理研究的强大工具，特别是在精确预测粒子对撞机实验中的物理过程方面。作者们专注于NNLO QCD计算，这是理论物理中的一种高级精度计算，它能更准确地模拟粒子碰撞事件并减少理论误差。文中提到的2→1和2→2过程代表了两个初始粒子生成一个或两个最终状态粒子的反应，这些反应可能涉及希格斯粒子和矢量玻色子，如W和Z玻色子。 MATRIX的独特之处在于它全面考虑了矢量玻色子的轻子衰变，这在以前的计算中通常被简化或忽略。通过包括所有相关的共振和非共振图，计算不仅限于简单的基本过程，而是考虑了复杂的真实物理环境。同时，矩阵处理了离壳效应，即粒子在非标准模型预测的静质量处的行为，以及自旋相关性，这在理解粒子性质和相互作用时至关重要。文章还介绍了MATRIX的软件架构和主要特性，强调了其用户友好性和可扩展性，使得研究人员能够轻松获取NNLO准确结果。矩阵还包括一个自动外推程序，这一特性极大地减少了由于NNLO减法技术固有的系统不确定性，使得结果的可靠性达到了前所未有的精确度。最后，作者们提供了他们在研究中考虑的物理过程的参考预测，分析了相应的理论不确定性，这为实验数据的解释和对比提供了坚实的基础。通过MATRIX，粒子物理学的研究人员能够进行更深入、更细致的分析，进一步理解基本粒子和相互作用的本质。

Eur. Phys. J. C (2018) 78:537 Page 9 of 51 537

impact of the various parameters, which can be accessed

through the input ﬁles, are described in Sect. 5.

After adjusting the input cards to obtain the desired results,

we can start the run by typing

|===>> run

This will start a complete run, no human intervention

is needed from now on. Once the run is ﬁnished the

results from the run are collected in the respective folder

result/${run_name} as printed on screen (see Sect. 4.3

for details on the result-folder structure), the most relevant

results, which are the total rates, are also printed on screen

at the very end of the run.

We emphasize that for every run

a CITATION.bib ﬁle is created and provided inside the

folder result/${run_name}. Please cite these papers

if you use the results of Matrix to acknowledge the efforts

that have been made to obtain these results with Matrix.

When performing a time-extensive (NNLO) run, we rec-

ommend to start Matrix from a window manager (e.g.

screen or tmux) in order to be able to logout from the

present machine during the run. An alternative is to start

Matrix with nohup as explained in the second example of

Sect. 4.4.2.

Running phases of a complete run

A complete run is divided into various stages (running

phases), each of which may be started directly from the

run shell by typing the name of the respective run mode

(${run_mode}). One must bear in mind, however, that

every run stage depends on all previous run stages and will

fail in case one of the previous ones has not ﬁnished success-

fully. The order of the run stages is as follows:

• grid-run: First, the integration grids are created in the

warm-up phase (run_grid).

• pre-run: Next, the expected runtimes for the main-run

are extrapolated from a quick pre-run phase (run_pre);

some preliminary results are already printed on screen.

• main-run: Then, the main run is started, computing all

results to the desired precision (run_main).

• result-collection: Finally, the results are collected, and

all distributions are automatically plotted if gnuplot is

installed (run_results).

By default the inputs are already set to use reasonable cuts and param-

eters for each process; the default run (without changing the cards)

computes a simple LO cross section with 1% precision, which we rec-

ommend to use when running for the ﬁrst time in order to test whether

everything is working properly. As this run should be very quick (a

few minutes), this test can be done in local mode (see Sect. 4.5 for the

settings in the ﬁle input/MATRIX_configuration).

Note that Matrix provides the extrapolated cross section for r

cut

→

0 as a ﬁnal result at NNLO (and at NLO if the q

-subtraction procedure

is used also at NLO) including an extrapolation uncertainty, see Sect. 7,

which is printed on screen after the cross section with a ﬁxed r

cut

value.

Note that the result-collection will always be started auto-

matically after a successful main-run. Furthermore, if the

run mode run_pre_and_main is used, the code will start

from the pre-run (assuming a successful grid-run) and auto-

matically continue with the main-run and result-collection.

Starting from one of these intermediate stages can be use-

ful in many respects. One example is the continuation of a run

after some unwanted behaviour, if some stages have already

passed successfully and one would like to restart from one

of the later stages. Note that all jobs in the requested run

stage are removed and started from scratch. To continue a

run while keeping already successfully ﬁnished jobs of the

requested run stage, or to run with increased precision, the

--continue command can be used, see example seven of

Sect. 4.4.2. Another example is running again with a mod-

iﬁed set of inputs. In the latter case it is sufﬁcient to only

restart the main-run as follows:

$ ./bin/run_process

to start the script,

|===>> ${run_name}

to pick up the old run with name ${run_name}, and

|===>> parameter

to change, e.g., the PDF set in the ﬁle parameter.dat

(if not done by hand before). It is essential to also uncom-

ment include_pre_in_results = 0 in the same ﬁle

in order to avoid mixing of the different settings in pre-run

and main-run in the result combination. After that, the main-

run is started by

|===>> run_main

Other run modes to be selected involve different behaviour

of the code, such as only setting up the folder ${run_name}

and the corresponding subfolders inside input, log and

result (setup_run) without starting the run (this is help-

ful if one wants to change the inputs by hand, but not through

the interface, e.g. by copying the input ﬁles from somewhere

else); deleting a given run including its respective subfolders

inside input, log and result (delete_run); etc.

4.4.2 Running with arguments

The run script allows some of the various settings, which are

typically controlled interactively, to be controlled directly

by arguments in its shell command. This enables, e.g., the

possibility to directly start a certain run without having to

interact with the interface. Type

$ ./bin/run_process --help

in order to see all available options.

123

537 Page 10 of 51 Eur. Phys. J. C (2018) 78:537

We summarize a few useful examples in the following:

1. The command

$ ./bin/run_process ${run_name}

--run_mode run

will create (pick up, if ${run_name} exists) the run

with name ${run_name}, and directly start a com-

plete run (due to --run_mode run), with the default

inputs (or the ones already set in ${run_name}).

The

${run_mode} may be chosen as any of the various

commands outlined at the end of the previous section,

e.g. --run_mode run_pre_and_main to start the

run directly from the pre-run (assuming a successful grid-

run has already been done).

2. The same command can be used in combination with

nohup

$ nohup ./bin/run_process ${run_name}

--run_mode run > run.out &

to run Matrix in the background while one is still able to

logout from the present machine. The on-screen output of

Matrix in this example is written to the ﬁle run.out.

3. The command

$ ./bin/run_process ${run_name}

--delete_run

will delete the run with name ${run_name}, includ-

ing its respective subfolders inside input, log and

result.

4. The command

$ ./bin/run_process ${run_name} --setup_run

will create a run with name ${run_name} including its

respective subfolders inside input, log and result

without starting the run. One may then modify the input

ﬁles directly by hand (without using the Matrix shell)

and continue with starting the run as described under 1.).

5. One may want to copy, e.g. as a backup, some existing

(possibly ﬁnished) run. The command

$ ./bin/run_process ${run_name}

--copy_run_from ${run_another_name}

allows to make a complete copy of an existing run with

name ${run_another_name} to a new run with

name ${run_name}. This may take quite a while in

case a ﬁnished run is copied, as the run folder could have

a rather large size.

6. In certain situations it may be helpful to use inputs other

than the default inputs when creating a new run. The

command

$ ./bin/run_process ${run_name}

--input_dir ${any_folder_inside_input}

Note that in the default inputs only a simple LO run is enabled.

will create a run with name ${run_name}, and

the three input ﬁles will be copied from the folder

${any_folder_inside_input} inside the folder

input. This may, of course, also be the name of another

run whose inputs should be used. The only requirement

is that a folder with the given name exists inside the

folder input and contains the ﬁles parameter.dat,

model.dat and distribution.dat.

7. Matrix provides the possibility to continue a run, while

deleting only the content of later run stages, but not of the

current run stage. This is very useful in two situations:

First, a run has crashed in the middle or at the end of a run

stage, but several jobs have already ﬁnished successfully.

Second, the precision of a run should be improved by

adding more statistics to a previous run. In both cases the

command

$ ./bin/run_process ${run_name}

--run_mode run_main --continue

will continue the run with name ${run_name} and

not delete any job that has already ﬁnished successfully.

Note that it is absolutely required not to change any of

the inputs, except for a possibly increased precision, with

respect to the previous run if the ﬂag --continue is

used. Any other ${run_mode} may be chosen to be

continued in this way.

4.5 Conﬁguration ﬁle

Before turning to physics-related and technical settings rel-

evant for a speciﬁc Matrix run in Sect. 5, we discuss the

global parameters that steer the general behaviour of the

code. The ﬁle MATRIX_configuration controls vari-

ous global settings for both the compilation and the running

of the code. The general idea is that these conﬁgurations

can be made once and for all, depending on the respec-

tive environment one is working on: one can, e.g., set the

relevant paths for the compilation (if not found automati-

cally), choose local running or specify the cluster sched-

uler available on the present machine, etc. The global set-

tings that affect the running of a process may still be altered

at a later stage (before starting the respective run) and can

be chosen different for different process folders. The main

ﬁle MATRIX_configuration can be found in the folder

config inside the Matrix main folder. This ﬁle is linked

during each setup of a process (see Sect. 4.1) into the folder

input of the respective process folder. This soft link may

be replaced by the actual ﬁle such that each process can have

its own conﬁguration ﬁle. This allows for process-speciﬁc

run settings, and one can, e.g., change from cluster to local

123

Eur. Phys. J. C (2018) 78:537 Page 11 of 51 537

Tabl e 2 Parameters to be set in the ﬁle MATRIX_configuration

Variable Description

default_editor Sets the editor to be used for interactive access to input ﬁles. Alternatively, the default editor may

be conﬁgured directly by exporting the EDITOR environment variable on the system

mode Switch to choose local (multicore) run mode or cluster mode

cluster_name Name of the cluster; currently supported: Slurm, LSF (e.g. lxplus), Condor, HTCondor (e.g.

lxplus), PBS, Torque, SGE.

cluster_queue Queue/Partition of the cluster to be used for cluster submit; not required in most cases

cluster_runtime Runtime of jobs in cluster submit; not required in most cases

cluster_submit_line[1-99] Lines in cluster submit ﬁle to add cluster-speciﬁc options

max_nr_parallel_jobs Number of cores to be used in multicore mode; maximal number of available cores on cluster

parallel_job_limit Upper threshold for number of parallel jobs; if exceeded, user intervention required to continue.

max_jobs_in_cluster_queue If cluster queue contains more jobs than this value, Matrix will wait until jobs ﬁnish before

submitting further jobs

path_to_executable This path can be set to the folder that contains the executables of the processes (usually bin in the

Matrix main folder), and provides the possibility to use an executable from a different Matrix

installation; not required in most cases

max_restarts If there are still jobs left that failed after all jobs ﬁnished, Matrix will restart all failed jobs n times

when this parameter is set to n

nr_cores Number of cores to be used for the compilation; determined automatically by the number of

available cores on the machine if not set

path_to_lhapdf Path to lhapdf-config; not required in most cases

path_to_openloops Path to the openloops executable; not required in most cases

path_to_ginac Path to the ginac installation; not required in most cases

path_to_cln Path to the cln installation; not required in most cases

path_to_libgfortran Path to the libgfortran library; not required in most cases. This path can also be used if the

libquadmath library is not found, to be set to the respective lib folder

path_to_gsl Path to gsl-config; not required in most cases

run mode for a speciﬁc process (or even only for a dedicated

run and change it back after having started the run).

The options controlled by the ﬁle MATRIX_configu

ration are listed in Table 2.

5 Settings of a M

ATR I X run

In this section all relevant input settings are discussed. Most

of them are directly physics-related, but there are also a few

more technical parameters.

5.1 Process-independent settings

Every run of a process contains three input ﬁles in its respec-

tive subfolder inside input , which can be modiﬁed by

the user. The generic inputs in the ﬁles parameter.dat,

model.dat and distribution.dat of each Matrix

run are described in the following.

Since the ﬁle MATRIX_configuration is read only at the begin-

ning of a run, any change done after that has no effect.

5.1.1 Settings in

parameter.dat

All main parameters, related to the run itself or the behaviour

of the code, are speciﬁed in the ﬁle parameter.dat.Most

of them should be completely self-explanatory, and we will

focus our discussion on the essential ones. The settings can be

organized into certain groups and are discussed in the order

they appear in the ﬁle parameter.dat for the sample case

of Zγ production (where applicable).

5.1.1.1 General run settings

process_class = pp-emepa+X # process id

E = 6500. # energy per beam

coll_choice = 1 # (1) PP collider;

(2) PPbar collider

process_class A unique identiﬁer for the process

under consideration; it should never be touched by the user;

in particular, no other process can be chosen at this stage.

Its sole purpose is to identify which process the respective

parameter ﬁle belongs to.

E Value of the energy per beam; assumed to be identi-

cal for both initial hadrons, i.e. equal to half of the collider

energy. Here and in what follows, all input parameters with

energy dimension are understood in units of GeV.

123

剩余50页未读，继续阅读

weixin_38748718

粉丝: 6
资源: 912

MATRIX：全差分NNLO计算框架与强子对撞机过程分析

网络工具IPOP最新版本 4.1

SEO最好的整站系统

MATLAB神经网络43个案例分析.pdf+源码

具有Matrix + OpenLoops的NNLO QCD + NLO EW：矢量-玻色子对产生的精确预测

matrix:矩阵运算和计算库

大型强子对撞机的顶级夸克对生产：NNLO的完全差分QCD预测

Fast Matrix for Java:并行计算中 Java 的通用矩阵实用程序-开源

矩阵计算 matrix computation

C#的Matrix简单计算类

LHC上的顶夸克对生产：NNLO QCD辐射校正的完整差分计算

最新资源