Skip to content

MadMatrix: UMAMI setters/getters and model/fptype-tagged libraries - #317

Open
zeniheisser wants to merge 1 commit into
MadGraphTeam:mainfrom
zeniheisser:madmatrix-umami-parameters
Open

zeniheisser wants to merge 1 commit into
MadGraphTeam:mainfrom
zeniheisser:madmatrix-umami-parameters

Conversation

@zeniheisser

Copy link
Copy Markdown
Contributor

Original implementation was written as part of the MadtRex implementation, but I had Claude port it to a separate branch to avoid a huge PR that both introduces MadtRex and modifies existing structures.

Changes: explicit inclusion of physics model and FPTYPE in the names of compiled libraries; necessary in MadtRex to differentiate between different models running on the same backend.
UMAMI parameter setters/getters: Implements the functions in the UMAMI interface to set parameters in a loaded library, rather than having to reparse the entire param_card.dat for every library launch. Probably not useful, but it could also be used to run event generation with varying physics parameters (e.g. a scan).

Claude's comments:

  • umami_set_parameter / umami_get_parameter: runtime access to independent model parameters (by name or SLHA location) and to parton masses, for the MadMatrix backends (cpu/simd/gpu umami.cc) and the mg7 C++ api; the exporters register every scalar parameter/coupling in a name -> pointer table. Couplings and parameters are registered into separate maps so that FPTYPE=f builds compile (couplings are cxtype, parameters stay double).
  • Process and common libraries now carry the model name and FPTYPE (libmadmatrix__.so), so builds for different models/precisions out of the same directory never collide; me_path in subprocesses.json gains an {fptype} placeholder, resolved by mg7 launch.py and gridpack.py from [run] precision.
  • madmatrix.mk/madmatrix_src.mk pass FPTYPE through to the common library build and clean targets.

…braries

- umami_set_parameter / umami_get_parameter: runtime access to independent
  model parameters (by name or SLHA location) and to parton masses, for the
  MadMatrix backends (cpu/simd/gpu umami.cc) and the mg7 C++ api; the
  exporters register every scalar parameter/coupling in a name -> pointer
  table. Couplings and parameters are registered into separate maps so that
  FPTYPE=f builds compile (couplings are cxtype, parameters stay double).
- Process and common libraries now carry the model name and FPTYPE
  (libmadmatrix_<model>_<proc>_<backend>_<fptype>.so), so builds for
  different models/precisions out of the same directory never collide;
  me_path in subprocesses.json gains an {fptype} placeholder, resolved by
  mg7 launch.py and gridpack.py from [run] precision.
- madmatrix.mk/madmatrix_src.mk pass FPTYPE through to the common library
  build and clean targets.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant