{"id":20683232,"url":"https://github.com/tudasc/pira","last_synced_at":"2025-06-21T07:02:52.919Z","repository":{"id":56330203,"uuid":"286400200","full_name":"tudasc/PIRA","owner":"tudasc","description":"PIRA - Automatic Instrumentation Refinement","archived":false,"fork":false,"pushed_at":"2024-03-28T12:26:25.000Z","size":746,"stargazers_count":16,"open_issues_count":2,"forks_count":1,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-04-22T12:28:00.380Z","etag":null,"topics":["hpc","instrumentation","llvm","profiler","score-p"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tudasc.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":"CITATION.cff","codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":"AUTHORS","dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2020-08-10T06:57:52.000Z","updated_at":"2025-02-09T00:38:42.000Z","dependencies_parsed_at":"2023-12-27T12:26:01.206Z","dependency_job_id":"468b5a4b-a25d-4e22-a8c6-718a879ce852","html_url":"https://github.com/tudasc/PIRA","commit_stats":null,"previous_names":[],"tags_count":6,"template":false,"template_full_name":null,"purl":"pkg:github/tudasc/PIRA","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tudasc%2FPIRA","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tudasc%2FPIRA/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tudasc%2FPIRA/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tudasc%2FPIRA/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tudasc","download_url":"https://codeload.github.com/tudasc/PIRA/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tudasc%2FPIRA/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":261080420,"owners_count":23106593,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["hpc","instrumentation","llvm","profiler","score-p"],"created_at":"2024-11-16T22:15:59.991Z","updated_at":"2025-06-21T07:02:47.898Z","avatar_url":"https://github.com/tudasc.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"[![License](https://img.shields.io/badge/License-BSD%203--Clause-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)\n\n# PIRA\n\nThe **P**erformance **I**nstrumentation **R**efinement **A**utomation framework *PIRA* approaches the time-consuming task of generating a reasonable performance measurement for an unknown code base when using Score-P.\nFor more information please see our papers:\n\n\u003ctable style=\"border:0px\"\u003e\n\u003ctr\u003e\n  \u003ctd valign=\"top\"\u003e\u003ca name=\"ref-pira-2018\"\u003e\u003c/a\u003e[PI18]\u003c/td\u003e\n  \u003ctd\u003eJan-Patrick Lehr, Alexander Hück, Christian Bischof. \u003ca href=\"https://doi.org/10.1145/3281070.3281071\"\u003ePIRA: performance instrumentation refinement automation\u003c/a\u003e. In \u003ci\u003e5th ACM SIGPLAN International Workshop on Artificial Intelligence and Empirical Methods for Software Engineering and Parallel Computing Systems (AI-SEPS)\u003c/i\u003e, pages 1-10, ACM, 2018.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd valign=\"top\"\u003e\u003ca name=\"ref-pira-2019\"\u003e\u003c/a\u003e[PI19]\u003c/td\u003e\n  \u003ctd\u003eJan-Patrick Lehr, Alexandru Calotoiu, Christian Bischof, Felix Wolf. \u003ca href=\"https://doi.org/10.1109/ProTools49597.2019.00011\"\u003eAutomatic Instrumentation Refinement for Empirical Performance Modeling\u003c/a\u003e. In \u003ci\u003eInternational Workshop on Programming and Performance Visualization Tools (ProTools)\u003c/i\u003e, pages 40-47, IEEE, 2019.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n  \u003ctd valign=\"top\"\u003e\u003ca id=\"ref-pira-2021\"\u003e\u003c/a\u003e[PI21]\u003c/td\u003e\n  \u003ctd\u003ePeter Arzt, Yannic Fischler, Jan-Patrick Lehr, Christian Bischof. \u003ca href=\"https://doi.org/10.1007/978-3-030-85665-6_2\"\u003eAutomatic Low-Overhead Load-Imbalance Detection in MPI Applications\u003c/a\u003e. In \u003ci\u003eEuro-Par 2021: Parallel Processing. Lecture Notes in Computer Science, vol 12820\u003c/i\u003e, pages 19-34, Springer, 2021.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\n\n## General Approach\n\nPIRA runs the following four phases (2-4 are iterated):\n\n1) Build the target application and perform a baseline measurement.\n2) Generate an initial performance instrumentation, based on the statement aggregation selection strategy (cf. [this paper](https://ieeexplore.ieee.org/document/7530067)).\n3) Run the instrumented target application to generate a profile in the cubex format.\n4) Analyze the generated profile to find a new and improved instrumentation.\n\nPIRA supports both *compile-time* and *run-time* filtering of functions, including runtime filtering of MPI functions through automatically generated wrappers.\nIn compile-time filtering, only the desired functions are instrumented at compile-time, reducing the overall measurement influence significantly.\nIn contrast, in runtime filtering, the compiler inserts instrumentation hooks into  *every* function of the target application, and the filtering happens at runtime.\n\n## Requirements, obtain PIRA, build it, use it\n\n### Requirements\n\nPIRA requires CMake (\u003e=3.16), Clang/LLVM 10, Python 3, Qt5 and OpenMPI 4.\nIt (or MetaCG) will further download (and build)\n\n- [MetaCG](https://github.com/tudasc/MetaCG)\n- [Modified Score-P 6.0](https://github.com/jplehr/score-p-v6)\n- [Extra-P (version 3.0)](https://www.scalasca.org/software/extra-p/download.html)\n- [LLNL's wrap](https://github.com/LLNL/wrap)\n- [bear (version 2.4.2)](https://github.com/rizsotto/Bear)\n- [cxxopts (version 2.2.1)](https://github.com/jarro2783/cxxopts)\n- [nlohmann json (version 3.10.5)](https://github.com/nlohmann/json)\n- [spdlog (version 1.8.2)](https://github.com/gabime/spdlog)\n\nIf you want to build PIRA in an environment without internet access, please see the `resources/build_submodules.sh` script, and adjust it to your needs.\n\n### Obtaining PIRA\n\nClone the PIRA repository.\n\n```{.sh}\n$\u003e git clone https://github.com/tudasc/pira\n$\u003e cd pira\n```\n\n### Building PIRA\n\nSecond, build the dependent submodules using the script provided, or pass values for the different options (see usage info via `-h` for options available).\nAll downloaded and built files will be placed into `external/src/` while all installations will be placed into `external/install/`.\nSpecify the number of compile processes to be spawned for the compilation of PIRA's externals.\nThe script will download PIRA's dependencies in their default version.\nThese versions are also tested in our CI and are expected to work.\n\n```{.sh}\n$\u003e cd resources\n$\u003e ./build_submodules.sh -p \u003cncores\u003e\n```\n\nAs final step, the build script will write the install paths of the submodules into the file `resources/setup_paths.sh`.\nShould you wish to rebuild PIRA, please remember to `git restore` this file.\n\n#### PIRA Docker\n\nWe also provide an (experimental) `Dockerfile` to build PIRA and try it.\n\n```{.sh}\n$\u003e podman build -t pira:master -f docker/Dockerfile .\n```\n\nWhen running inside the container, e.g., the integration tests, please invoke the scripts as follows.\n\n```{.sh}\n$\u003e cd resources\n$\u003e . setup_paths.sh\n$\u003e cd ../test/integration/GameOfLife # Example test case\n# By default PIRA will look into $HOME/.local, which is not currently existent in the docker\n# XDG_DATA_HOME signals where to put the profiling data PIRA generates\n$\u003e XDG_DATA_HOME=/tmp ./run.sh \n```\n\n### Using PIRA\n\nFor a full example how to use PIRA, checkout the `run.sh` scripts in the `/test/integration/*` folder.\nA potentially good starting point is the `GameOfLife` folder and its test case.\n\nFirst, set up the required paths by sourcing the script in the `resources` folder.\n\n```{.sh}\n$\u003e cd resources/\n$\u003e . setup_paths.sh\n```\n\nThen, you can run an example application of PIRA on a very simple implementation of Conway's Game of Life by using the provided `run.sh` script in the `./test/integration/GameOfLife` folder.\n\n```{.sh}\n$\u003e cd ./test/integration/GameOfLife\n$\u003e ./run.sh\n```\n\nThe script performs all steps required from the start, i.e., preparing all components for a new target code, to finally invoke PIRA.\nIn the subsequent sections, the steps are explained in more detail.\nThe steps are:\n\n1. Construct a whole-program call graph that contains the required meta information. This needs to be done for a target application whenever the code base changed.\n2. Implement the PIRA configuration. For the example, the integration tests provide example configurations.\n3. Implement the required PIRA functors. For the example, simple example functors are provided, which may also work for other applications.\n4. Invoke PIRA with the respective configuration.\n\n#### Arguments for Invoking PIRA\n\n* ```config``` Path to the config-file (required argument)\n* ```--config-version [1,2]``` Version of PIRA configuration, 2 is the default and encouraged; 1 is deprecated.\n* ```--runtime-filter``` Use run-time filtering, the default is false. In compile-time filtering, the functions are not instrumented at compile-time, reducing the overall measurement influence significantly, but requiring the target to be rebuilt in each iteration.\nIn contrast, with runtime filtering, the compiler inserts instrumentation hooks in every function of the target application.\n* ```--iterations [number] ``` Number of Pira iterations, the default value is 3.\n* ```--repetitions [number]``` Number of measurement repetitions, the default value is 3.\n* ```--tape``` Location where a (somewhat extensive) logging tape should be written to.\n* ```--extrap-dir``` The base directory where the Extra-p folder structure is placed.\n* ```--extrap-prefix``` Extra-P prefix, should be a sequence of characters.\n* ```--version``` Prints the version number of the PIRA installation\n* ```--analysis-parameters``` Path to configuration file containing analysis parameters for PGIS. Required for both Extra-P and LIDe mode.\n* ```--slurm-config [path to slurm cfg file]``` Enables running the target code on a slurm cluster. A slurm config file is needed. Please see [this section](#run-pira-on-a-slurm-cluster) for more information.\n\n#### Highly Experimental Arguments to PIRA\n\n* ```--hybrid-filter-iters [number]``` Re-compile after [number] iterations, use runtime filtering in between.\n* ```--export``` Attaches the generated Extra-P models and data set sizes into the target's IPCG file.\n* ```--export-runtime-only``` Requires `--export`; Attaches only the median runtime value of all repetitions to the functions. Only available when not using Extra-P.\n* ```--load-imbalance-detection [path to cfg file]``` Enables and configures the load imbalance detection mode. Please read [this section](#load-imbalance-detection) for more information.\n\n\n#### Whole Program Call Graph\n\nPIRA uses source-code information for constructing an initial instrumentation and deciding which functions to add to an instrumentation during the iterative refinement.\nIt provides a Clang-based call-graph tool that collects all required information and outputs the information in a `.json` file.\nYou can find the `cgcollector` tool in the subdirectory `./extern/src/metacg/cgcollector`.\nPIRA requires the callgraph file to be in the MetaCG file format in version 2 (MetaCG v2).\n\nMore information on the CGCollector and its components can be found in the [MetaCG](https://github.com/tudasc/MetaCG) documentation.\n\nApplying the CGCollector usually happens in two steps.\n\n1. At first, `cgc` is invoked on every source file in the project. e.g.:\n\n    ~~~{.sh}\n    for f in $(find ./src -type f \\( -iname  \"*.c\" -o -iname \"*.cpp\" \\) ); do\n        cgc --metacg-format-version=2 $f\n    done\n    ~~~\n2. The `.ipcg`-files created in step 1 are then merged to a general file using `cgmerge`.\n    1. Create an output file, solely containing the string `\"null\"`\n\t\t2. If your project contains more than one `main` function, please only merge the file with the correct `main` function.\n   \n    ~~~{.sh}\n    echo \"null\" \u003e $IPCG_FILENAME\n    find ./src -name \"*.ipcg\" -exec cgmerge $IPCG_FILENAME $IPCG_FILENAME {} +\n    ~~~\n\nThe final graph needs to be placed into the directory of the callgraph-analyzer. Since **PGIS** is currently used for the CG analysis, the generated whole program file is copied into the PGIS directory.\nCurrently, it is important that the file in the PGIS directory is named following the pattern `item_flavor.mcg`. An item stands for a target application. More on the terms flavor and item in the next section.\n\n~~~{.sh}\n# Assuming $PIRA holds the top-level PIRA directory\n$\u003e cp my-app.mcg $PIRA/extern/install/pgis/bin/item_flavor.mcg\n~~~\n\n#### Configuration\n\nThe PIRA configuration contains all the required information for PIRA to run the automatic process.\nThe various directories that need to be specified in the configuration-file can either be *absolute* paths, or *paths, relative to the execution path of pira*. Paths may contain environment variables, e.g., `$HOME`.\nThe examples are taken from the GameOfLife example in `./test/integration/GameOfLife`.\n\n##### Directory and items\n\nThe user specifies: *the directory* in which to look for subsequently defined *items*, in the example, the directory is `./gol/serial_non_template`.\nThese directories are given aliases, which are dereferenced using the '%' sign.\nAn item in PIRA is a target application, built in a specific way, which is the reason for it being grouped in the configuration under *builds*.\n\n```{.json}\n{\n  \"builds\": {\n    \"%gol\": {\n      \"items\": {\n        \"gol\": {\n          ...\n        }\n      }\n    }\n  }\n  \"directories\": {\n    \"gol\": \"./gol/serial_non_template\"\n  }\n}\n```\n\n##### Analyzer\n\nEvery item specifies which *analyzer* should be used.\nThe **default** analyzer ships with PIRA, and the sources can be found in `./extern/src/metacg/pgis` or the installation in `./extern/install/pgis/bin`, respectively.\nThe analyzer is responsible for steering the instrumentation refinement, and is, therefore, an essential part of the PIRA framework.\n\n##### Argmap\n\nThe *argmap* field specifies the different arguments that are passed to the target application when running the performance experiments.\nHow the arguments are passed to the target application is defined by different *mappers*.\nIn the example, a *linear* mapper is used, which simply iterates the values of the parameter named *size* in the order given in the list.\n\n```{.json}\n\"argmap\": {\n  \"mapper\": \"Linear\",\n  \"size\": [50, 80, 110, 150, 300, 500]\n}\n```\n##### Cubes\n\nThe *cubes* field is the location where PIRA should store the obtained Score-P profiles.\nIt will construct a directory tree in that location, so the user can, after PIRA finished, also easily invoke the Extra-P modeling tool by simply passing it the respective location, i.e., */tmp/pira* in the example.\n\n```{.json}\n\"cubes\": \"/tmp/pira\"\n```\n##### Flavors\n\nThe *flavors* field adds another level of possible distinction, as target applications can be built in different *flavors*.\nAn example would be to specify different math libraries that the target application should link against.\n\n##### Functors\n\nFinally, the *functors* directory points PIRA to the location where it looks for the user-provided Python functions that ultimately tells PIRA how to build, run, and analyze the target application.\nIn the example, PIRA is pointed to a directory called *functors* relative to the location of the configuration.\n\n```{.json}\n\"flavors\": [\n  \"ct\"\n],\n\"functors\": \"./functors\",\n\"mode\": \"CT\"\n```\n##### Mode\n\nThe *mode* field, in this version of PIRA, is ignored.\n\n#### Implementing Functors\n\nAs of now, the user needs to implement five different functors:\n\n* `analyze_\u003cITEM\u003e_\u003cFLAVOR\u003e.py`: invokes the analyzer.\n* `clean_\u003cITEM\u003e_\u003cFLAVOR\u003e.py`: cleans the build directory.\n* `\u003cITEM\u003e_\u003cFLAVOR\u003e.py`: build the instrumented version.\n* `no_instr_\u003cITEM\u003e_\u003cFLAVOR\u003e.py`: builds the vanilla version.\n* `runner_\u003cITEM\u003e_\u003cFLAVOR\u003e.py`: runs the target application.\n\nFunctors, generally, support two modes of invocation: *active* and *passive*.\nThe functor tells PIRA which mode it uses by setting the respective value to `True` in the dictionary returned by the function `get_method()`.\n\nIn active mode, the functor itself invokes the required commands, for example, to build the software.\nWhen invoked, the functor is passed a `**kwargs` parameter holding, for example, the current directory and an instance of a subprocess shell.\n\nThe passive mode solely returns the commands to execute, e.g. the string `make` to invoke a simple Makefile at the item's top-level directory.\nIt is also passed a `kwargs` parameter that holds specific information, like pre-defined values needed to add to CXXFLAGS or additional linker flags.\nAn example of a passive functor may be found in the `examples` and `test` directories.\nCurrently, all implemented functors use the passive mode.\n\n#### List of Keyword Arguments Passed to Functors\n\nPIRA passes the following keyword arguments to all functors.\nIn addition, different PIRA components may pass additional arguments.\n\n*Important*: We now ship our own Score-P version. Thus, it is no longer required to adjust compile commands in PIRA.\nCheck out the functors in `test/integration/AMG2013` for example usages of the different information.\n\n##### All Functors\n\nCurrently, no information is passed to all functors\n\n##### Analysis Functor\n\n* ***ANALYZER_DIR***: The directory in which the analyzer i.e. PGIS, is searched for.\n\n##### Build Functor\n\n* ***filter-file***: The path to the generated white list filter file (to be passed to Score-p).\n\n##### Run Functor\n\n* ***util***: Reference to a PIRA *Utility* object.\n* ***args***: The arguments passed to the target application as a list, i.e., `[0]` accesses the first argument, `[1]` the second, and so on.\n* ***LD_PRELOAD***: The path to the `.so` file implementing the MPI wrapper functions (crucial for MPI filtering).\n\n#### Analyzer parameters\nAdditional parameters are required for some analysis modes. Specifically, PIRA LIDe (see below) and Extra-P modeling analysis require user provided parameters. Create a JSON file and provide its path to PIRA using the `--analysis-parameters`-switch. The following example contains parameters for the Extra-P modeling mode. The available strategies to aggregate multiple Extra-P models (when a function is called in different contexts) are: `FirstModel`, `Sum`, `Average`, `Maximum`.\n```{.json}\n{\n  \"Modeling\": {\n    \"extrapolationThreshold\": 2.1,\n    \"statementThreshold\": 200,\n    \"modelAggregationStrategy\": \"Sum\"\n  }\n}\n```\n\n### Load imbalance detection (PIRA LIDe)\nFor more details about the load imbalance detection feature, please refer to \u003ca href=\"#ref-pira-2021\"\u003e[PI21]\u003c/a\u003e. \nProvide the PIRA invocation with a path to a configuration file using the `--load-imbalance-detection`-parameter. This JSON-file is required to have the following structure:\n\n```{.json}\n{\n  \"metricType\": \"ImbalancePercentage\",\n  \"imbalanceThreshold\": 0.05,\n  \"relevanceThreshold\": 0.05,\n  \"contextStrategy\": \"None\",\n  \"contextStepCount\": 5,\n  \"childRelevanceStrategy\": \"RelativeToMain\",\n  \"childConstantThreshold\": 1,\n  \"childFraction\": 0.001\n}\n```\n* ***metricType***: Metric which is used to quantify load imbalance in function runtimes. If unsure, use *Imbalance Percentage*. (Other experimental options: *Efficiency*, *VariationCoeff*)\n* ***imbalanceThreshold***: Minimum metric value to be rated as imbalanced. For *Imbalance Percentage*, 5% can be used a starting value.\n* ***relevanceThreshold***: Minimum runtime fraction a function is required to surpass in order to be rated as relevant.\n* ***contextStrategy***: Optional context handling strategy to expand instrumentation with further functions. Use *MajorPathsToMain* for profile creation and *FindSynchronizationPoints* for tracing experiments. Use *None* to disable context handling. (Other experimental option: *MajorParentSteps* with its suboption *contextStepCount*)\n* ***childRelevanceStrategy***: Strategy to calculate statement threshold for the iterative descent. If unsure, use *RelativeToMain* which will calculate the threshold as max(*childConstantThreshold*, *childFraction* * (main's inclusive statement count))\n\n### Run PIRA on a SLURM cluster\n\nTo run PIRA on a cluster with the SLURM workload manager, invoke it with the `--slurm-config` flag. Give the path to your batch system configuration file with it. See the integration tests suffixed with `_Slurm` (`test/integration/*_Slurm/`). PIRA currently supports batch systems with the [SLURM workload manager](https://slurm.schedmd.com/overview.html). PIRA supports the use of a `module`-system, which may be found on slurm clusters.\n\nThe batch system configuration file is a JSON-file, which is structured as follows:\n\n```{.json}\n{\n  \"general\": {\n    \"backend\": \"slurm\",\n    \"interface\": \"pyslurm\",\n    \"timings\": \"subprocess\"\n  },\n  \"module-loads\": [\n    {\n      \"name\": \"gcc\",\n      \"version\": \"8.5\"\n    },\n    {\n      \"name\": \"llvm\",\n      \"version\": \"10.0.0\",\n      \"depends-on\": [\n        {\n          \"name\": \"gcc\",\n          \"version\": \"8.5\"\n        }\n      ]\n    }\n  ],\n  \"batch-settings\": {\n    \"time_str\": \"00:10:00\",\n    \"mem_per_cpu\": 3800,\n    \"number_of_tasks\": 1,\n    \"partition\": null,\n    \"reservation\": null,\n    \"account\": \"your_account_here\",\n    \"cpus_per_task\": 96\n  }\n}\n```\n\nBreakdown:\n\n- `general` section: Lets you choose in which way PIRA will execute your code on the batch system. Since every option in this section is optional, you can omit the whole section, if you are fine with using the defaults:\n    + `backend`: What workload manager to use. Choices: `slurm`, for the slurm workload manager. Default: `slurm`, therefor optional.\n    + `interface`: In which way PIRA should interact with your batch system manager. For the SLURM backend, these are: `pyslurm`, to use [PySlurm](https://github.com/pyslurm/pyslurm) (this requires PySlurm to be installed, see [this section](#notes-on-installing-pyslurm); `sbatch-wait`, to use standard `sbatch` with the `--wait` flag; `os`, for standard `sbatch` and `squeue` interaction calls. Default: `pyslurm`, therefor optional.\n    + `timings`: How timing of the target code should be done. Choices: `subprocess`, for timing with a python wrapper and `os.times` in a subprocess (exactly like PIRA does it if ran local); `os`, to use `/usr/bin/time`. Default: `subprocess`, therefor optional.\n    + `force-sequential`: Default `false`. Set to `true` to force PIRA/your batch system to do all runs in sequential order (only one execution of the target code at a time). This means PIRA will take care that your batch system runs repetitions, as well as different jobs in scaling experiments in sequential order. If set to/left on `false` PIRA will try to instruct the batch system to do as many executions as possible within every iteration in parallel. \n- `module-loads` section: *Currently not in use in PIRA, work in progress! Currently, you need to load all modules manually, before starting PIRA!* Meant for which modules should be loaded with the `module` system. This requires one to be in place (commands `module load` and `module purge` may be used by PIRA). If you do not have a `module` system in place, or do not want to use it, either omit this section completely, or set `\"module-loads\": null`. To specify modules PIRA should load, specify a list of modules, as in the example above. \n    + Each module have to have a `name`. \n    + The `version` is optional, if not given, it will depend on what the `module` system loads as default module version. It is recommended to always give versions explicitly.\n    + `depends-on` is also optional. Give a list of modules on which this module depends. These modules have to have a `name` and can optional have a `version` given. The dependencies defined here are used by PIRA to determine the order in which modules should be loaded\n        - If you do not give a version, it will only check that *some* version of this module was loaded. It is recommended to always give versions explicitly.\n        - If you do not specify this, or set it to `null`, it is assumed, this module has no dependencies. \n        - Be aware that PIRA will crash with a corresponding error, if you define dependency cycles here. \n        - Note that you can care about dependency management on your own: If not given any `depends-on` PIRA will (try to) load the modules in exactly that order that was given in the config file. \n- `batch-setting` section: The actual hardware and job options for the batch system. Some options in the section are mandatory, you cannot omit this section.\n    + `time`: The `sbatch --time` option, mandatory. \n    + `mem-per-cpu`: The `sbatch --mem-per-cpu` option, mandatory.\n    + `ntasks`: The `sbatch --ntasks` option, mandatory.\n    + You can optionally further specify the following options: `partition`, `reservation`, `account` (all default to `null`=not given), `cpus-per-task` (defaults to `4`), `exclusive` (defaults to `true`; not supported with `pyslurm`), and `cpu-freq` (defaults to `null`).\n    + Note that there are some `sbatch` options you cannot define in this config. This is due to some options used by PIRA internally, for example the `--array` option, to map the repetitions to job arrays.\n\t\n#### Notes on installing PySlurm\n\nHow and which version of PySlurm to install on your cluster, highly depends on your SLURM version, and your SLURM installation. The installation and packaging solution for pyslurm with PIRA is work in progress. Refer to their [README](https://github.com/PySlurm/pyslurm#readme). You might try some of the following:\n\n- If your SLURM version is XX.YY.\\*, you want to look for a release/brach of pyslurm with the version XX.YY.\\* (Note that \\* does not have to be identical).\n- Determine where SLURM is set up, look for a `include` and a `lib` dir. \n- Build pyslurm with these options, e.g. `python3 setup.py build --slurm-lib=/opt/slurm/21.08.6/lib --slurm-inc=/opt/slurm/21.08.6/include`\n- Install it: `python3 setup.py install --slurm-lib=/opt/slurm/21.08.6/lib --slurm-inc=/opt/slurm/21.08.6/include`.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftudasc%2Fpira","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftudasc%2Fpira","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftudasc%2Fpira/lists"}