GithubHelp home page GithubHelp logo

docbrown1955 / marty-public Goto Github PK

View Code? Open in Web Editor NEW
17.0 1.0 4.0 13.46 MB

Calculation of tree-level and one-loop Feynman diagrams Beyond the Standard Model

Home Page: https://marty.in2p3.fr

License: GNU General Public License v3.0

Shell 0.09% Makefile 0.08% C++ 88.51% C 1.17% CMake 0.25% TeX 0.93% Fortran 8.62% Tcl 0.34% Python 0.01%
feynman-diagrams particle-physics cpp17 high-performance modern-cpp symbolic-computation

marty-public's Introduction

MARTY Logo MARTY Logo

GitHub release (latest by date) GitHub commits since latest release (by date) GitHub Workflow Status GitHub Repo stars

Summary

MARTY is a C++ program automating perturbative calculations for beyond the Standard Model scenarios. Models can be built using the C++ user interface. For any model, squared amplitudes and Wilson coefficients can be calculated at the tree level or the one-loop level.

MARTY is a code generator. Analytical expressions, squared amplitudes or Wilson coefficients are converted into C++ code in a self-contained library compiled independently of MARTY. This code can therefore be used for numerical evaluation in different scenarios to perform a phenomenological analysis.

More information can be found on the website. In case you use MARTY for a physics study please cite

MARTY - A C++ framework automating symbolic calculations Beyond the Standard Model (Comput. Phys. Commun. 264 (2021) 107928, arXiv: 2011.02478 [hep-ph])

Get Started

In the following some possibilities to get started easily with MARTY, once installed, are presented. For installation instructions, see the following section.

Several sample programs are given in the examples/ directory, each in a different model. Once MARTY has been built, it is possible to run any example from the build/examples/ directory.

  • Complete first example [gettingStarted]: Extended first view at MARTY features, explained in details on the website. This example is simple but rather complete, from model building to code generation.
  • Simple models and calculations [sampleScalar, sampleSQED, sampleQED]: Get a first simple view of model building in MARTY and how to perform simple amplitude calculations.
  • More complexity [sampleQCD]: Group representations and cross-section calculation.
  • First glance at Wilson coefficients [sample2HDM].

Here are example diagrams you can try to find running the sample programs !

Simple 3-vertex Weak diffusion Meson mixing
GRAFED 3 vertex GRAFED weak diffusion GRAFED Meson mixing

For further MARTY magic, checkout the comprehensive manual!

Installation

The following procedure is relevant since MARTY-1.6. To build and install older versions please refer to the website.

Dependencies

Since MARTY-1.6 the dependency installations are longer supported by the automated build procedure, it is the user responsibility to install the required dependencies on his/her particular system.

Library dependencies (needed at compile-time):

  • Qt5 (needed for the GRAFED Graphical User Interface)
  • GSL + GSLCBLAS (C numerical scientific library)

System dependencies (needed at run-time as system commands):

  • cmake
  • latex
  • lualatex
  • dvipng
  • convert (part of ImageMagick)

On Ubuntu for example these dependencies can be installed with

   sudo apt-get install libgsl-dev libgslcblas0 texlive texlive-luatex dvipng coreutils imagemagick -y
   sudo apt-get install qtbase5-dev qtchooser qt5-qmake qtbase5-dev-tools -y
   sudo apt-get install cmake -y

On MacOS

   brew install coreutils gsl octave qt5 cmake imagemagick texlive

Compilers for MARTY

MARTY links C++ code with Fortran code from the LoopTools library. MARTY takes care of compiling and linking LoopTools but the compilers must be chosen carefully to link C++ and fortran codes.

For this reason, the MARTY installation procedure requires to have the GNU compiler collection, version greater than 9. Furthermore, the versions of gcc/g++/gfortran should be the same. The minimal set of compilers required to compile MARTY is therefore

    gcc-9
    g++-9
    gfortran-9

If the default compilers on the system do not meet the above requirements, compilers must be explicitely defined before going further following:

    export CXX=g++-9
    export CC=gcc-9
    export FC=gfortran-9

Any version greater than 9 can be used but all the three compilers must use the same version, compatibility has been validated up to gcc-12/g++-12/gfortran-12.

Build and install MARTY

Once the dependencies have been installed and that the C, C++ and Fortran compilers meet the requirements above (either by default or after having exported the CC, CXX and FC environment variables), clone this repository:

    git clone https://github.com/docbrown1955/marty-public.git

Then, build and install MARTY!

    cd marty-public
    mkdir build
    cd build
    cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=<installation-path-for-marty>
    make
    make install

If the CMAKE_INSTALL_PREFIX is not given, cmake will automatically set this variable to /usr/local. In case the installation path is not in /home (on Unix systems), the installation command requires sudo:

    sudo make install

It is also possible to build MARTY in debug mode (without optimization and including debug symbols) using the option -DCMAKE_BUILD_TYPE=Debug instead.

Run tests

To run the tests simply type:

    ctest

It is possible to get the output of failed tests (e.g. to include in a bug fix request) using

    ctest --output-on-failure

Environment variables

In case MARTY is not installed in a standard location (not in /usr/local/) it is necessary to set properly environment variables. Given that the installation path is <install/path>, Linux users should add this in their ${HOME}/.bashrc file:

    export PATH=$PATH:<install/path>/bin
    export CPATH=$CPATH:<install/path>/include
    export C_INCLUDE_PATH=$C_INCLUDE_PATH:<install/path>/include
    export LIBRARY_PATH=$LIBRARY_PATH:<install/path>/lib
    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<install/path>/lib

Although not recommended, if MacOS users install MARTY in a non-standard location the appropriate environment variables are (also to put in ${HOME}/.bashrc)

    export PATH=$PATH:<install/path>/bin
    export CPATH=$CPATH:<install/path>/include
    export C_INCLUDE_PATH=$C_INCLUDE_PATH:<install/path>/include
    export LIBRARY_PATH=$LIBRARY_PATH:<install/path>/lib
    export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:<install/path>/lib

After the first installation (and adding the environment variables in the .bashrc file) it is necessary to launch a new terminal or reload the bash session:

   source ${HOME}/.bashrc

The specific case of MacOS

On MacOS the System Integrity Protection (SIP) can cause issues if files are not installed in /usr/local. We therefore recommand to install MARTY in this location (default):

    mkdir build
    cd build
    cmake ..
    make
    sudo make install

In case of trouble installing MARTY

In you have issues to install dependencies or build MARTY, please see the open and closed issues. If not one solves your problem, open a new issue describing the bug:

  • Which operating system (including the version)
  • Provide a clear description of the procedure followed before the bug happened
  • Copy the error message if any

marty-public's People

Contributors

docbrown1955 avatar gregoireuhlrich avatar marco-palmiotto avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

marty-public's Issues

Independent MARTY Models

Models in MARTY should be located all in the same place, well documented and extended the SM should be easy:

  • Remove completely the use of .json files for models, in particular for the SM
  • Put all models in the models/ directory
  • Make the SM use generic builder functions to make it easier to reuse them in other models (optional, see #11)
  • Document the different models e.g. on the website, and in the manual

Documentation

  • Document tests (ctest in particular, and unit tests if relevant)
  • Document new model location
  • Document new LHA inclusion
  • Review model documentation
  • Write a detailed release note to explain include changes in particular
  • Document new tryUnitaryCondition option
  • Check documentation of setGccCompiler() / setClangCompiler() that have been removed
  • Document quadruple precision libraries
  • Document new mty::sm_input::all_params variable and the related undefineNumericalValues() and redefineNumericalValues() (see PR #53)
  • Document flavor group functional changes, in particular for ModelData::generateIndex() and ModelData::getVectorSpace() (see PR #56)
  • InitSantiizer ? (use, conversions, operators)
  • See how to (and do) document the planned latex output for expressions, on the MARTY side (not CSL)
  • Document particular Weyl particle names for fermion embedding & birotation (mass).
  • Document features explicitly (list of features)

Decaying particles and gauge invariance

Squared amplitudes with external decaying particles (e.g. W or Z bosons) are not gauge invariant ??

This can be seen from the fact the Goldstone couplings to squarks in the MSSM are proportional to quark masses that have no reason to appear in corresponding W contribution by changing the gauge to unitary.

See ref1 and ref2 [and its refs 22-27, in particular this one]

Process callables and kinematics

The libraries generated should provide callables containing the particle information (name, spin, (anti-)particle, mass, width) and default functions to load kinematics for 1->2 or 2->2 processes.

In this way we could do something like

auto const &func = f_G[i];
if (func.isDecay())
{
    // 1->2 process
   auto res = func(params);
}
else if (func.is2to2())
{
   auto res = func(params, E_CM, theta); // Automated! :)
}
else
{
   // Other type of process, fill s_ij by hand...
   params.s_12 = ...;
   // ...
   auto res = func(params);
}

SaveDiagrams feature

Check the SaveDiagrams() feature and document, maybe add a simple feature to merge different amplitudes.

Alternative to LoopTools

For (g-2) calculations in the SM, the looptools integrals are unstable and depend on the C/C++ implementation. This has been patched (for the C++ version) but it could be nice to propose an alternative (other numerical integrals).

Phase space IR divergences

What are phase space IR divergences ? How to regularize them with MARTY if LoopTools does not already ?

Change h0 -> h

Change the particle name h0 into h in MSSM models to cope with case insensitive files on MacOS (m_h0.h == m_H0.h)

Test suite

For MARTY-2.0 tests should be integrated in the main project and the build system:

  • Integrate the system tests from the test-suite in the project
  • Choose a unit-testing library for MARTY (googletest it is)
  • Write a first set of unit tests to complete the system tests

Document Topologies

Topology selection should be documented in the manual, together with the new excludeExternalLegCorrections option.

Ghost squared amplitudes

Ghost squared amplitudes should be calculated automatically when squaring an amplitude with external gauge bosons.

  • Have to find out the set of ghost contributions for more than 2 external gauge bosons.
  • Have to launch automatically the squared amplitudes (set an option to disable it if necessary) with external ghosts and substract them from the final result.

clooptools.h error

When running make I get

[ 31%] Generating ../../clooptools.h, ../../libooptools.so, ../../libooptools-static.a, ../../../src/clooptools.h looking for gcc... /usr/local/bin/gcc-11 looking for g++... /usr/local/bin/g++-11 looking for fortran... /usr/local/bin/gfortran-11 extracting the Fortran libraries... ok does /usr/local/bin/gfortran-11 append underscores... error linking Fortran and C make[2]: *** [clooptools.h] Error 1 make[1]: *** [dep/LoopTools-2.16/CMakeFiles/lt_lib.dir/all] Error 2 make: *** [all] Error 2

Possibility to view simplified readable output

Hello,

This is regarding the output of MARTY after computing the amplitudes.

In the final result, there are abbreviations (implemented automatically by Marty). While this maybe useful when viewing results on terminal, it would be useful to know if there exists is a way to export the output to a latex with all the abbreviations substituted back into the final result (just the way it is in LanHEP).

Thanks,
Aman

grafed-gui graphs.json >&/dev/null

When, following the tutorial I try to display the Feynman rules, auto rules = toyModel.getFeynmanRules();Show(rules);I get grafed-gui graphs.json >&/dev/null

Get started in the README.md

Add in the README.md file a 'Get Started' section explaining how to test some sample programs after a successful build.

Missing tikz-feynman latex package

If the tikz-feynman package is not installed in the latex distribution, GRAFED simply does not display labels on diagrams but no error or warning is ever displayed.

A check should be implemented or at least this unintended feature should be documented.

Improved safety for param_t structures

Hi, while I am finishing to improve the compare branch (to avoid the warnings), I noticed two important improvements that can be done for the param_t type and its use. In particular

  1. calling par->getName() instead of par->name in the print function. This allows to set name as private in InintSanitizer
  2. making print a const method, to allow for calling it in scopes where the param_t variable is qualified as const

I can do them myself in the compare branch, however I could not find the correct source files to modify them.

Clean-up MARTY

Considering the code coverage feature developed in #37, it should now be possible to spot very clearly unused code.

All this code should be cleaned-up to remove any untested (and most of the time useless) feature.

error.h: No such file or directory

when running make I get ../marty_bis/src/marty/core/wilsonOperator.cpp:17:10: fatal error: error.h: No such file or directory 17 | #include "error.h" | ^~~~~~~~~ compilation terminated. make[2]: *** [src/marty/core/CMakeFiles/marty-core.dir/wilsonOperator.cpp.o] Error 1 make[1]: *** [src/marty/c

note: I am using the setup discussed in [#22 ] and [#25 ]

C Code generation

Generating C functions using double complex and no csl::InitSanitizer would speed up compilation time and allow much larger functions to compile.

To implement:

  • Convert functions to pure C code
  • Create a cparam_t struct removing csl::InitSanitizer and std::complex
  • Write c++ wrapper functions in a unique cpp file (should be ok) taking as a parameter the c++ param_t struct and returning std::complex objects
  • Make sure quadruple precision is taken into account (this should not change from c++ to c so no problem)

See PR #3

Labels not showing in Feynman diagrams

Describe the bug
When GRAFED is launched to display Feynman diagrams, the latex labels are not shown at all, only the diagram edges are drawn correctly.

To Reproduce
When the texlive installation is not complete (enough), the tikz-feynman latex package may be missing in which case the labels cannot be shown in GRAFED.

Fix
Make sure the tikz-feynman package is available in your latex installation.

LoopTools target dependencies

A clear and concise description of what the bug is.

The two explicit LoopTools targets should be dependent of each other to ensure the two cannot launch concurrently (as only one makefile is used).

Compilers not found

Hi, I am trying to install following https://marty.in2p3.fr/download.html
Running source setup.sh /usr/local went smoothly, by when afterward running make I get the following error that I'm missing the library Qt5PrintSupport_debug. Googling it I could not find any indications on how to solve this issue. Thanks a lot for any suggestion!

ld: library not found for -lQt5PrintSupport_debug collect2: error: ld returned 1 exit status make[3]: *** [grafed-gui.app/Contents/MacOS/grafed-gui] Error 1 make[2]: *** [grafed] Error 2 make[1]: *** [grafed] Error 2 make: *** [all] Error 2

Unsupported names in generated libraries

The ^ symbol in mass names (probably from mass expressions, e.g. m_W^3) stays in the generated library and prevents the compilation. Code a workaround ? Should reproduce this first.

Wrong recursion in chiral traces

Correct the doc (thesis ?) about the formula for chiral traces recursion (see marty/sgl/tracer.cpp file):

   Tr(g(1)...g(n)g5) = sum(i=1:n-1)[sum(j=i+1:n)[(-1)^(1+j-i)g(ij)Tr(g(1)..^g(i)..^g(j)..g(n)g5)]] 

Test C generation for NMFV

The C libraries generated should be more robust to the large expressions in the NMFV. Should test that.

Complex mass scheme

Understand if the complex masses e.g. widths are properly handled by the narrow width approximation and a simple complex handling of mass parameters.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.