# TRIMSP-NL Workbench
### Contents ###
This repository contains TRIMSP-NL Workbench, an application for performing
[Monte Carlo] simulations of low-energy muon and ion implantation. The
workbench combines a [Fortran] transport engine with a graphical user
interface ([GUI]) for preparing input decks, running scans, and plotting the
results.
In the terminology used in the accompanying publication:
* **TRIM.SP-NL** is the generalized multilayer Fortran transport engine.
* **TRIMSP-NL Workbench** is the complete engine, GUI, and scan-management
workflow.
* This code is specifically tuned to simulate implantation of low-energy projectiles in materials.
* The code is maintained by the Low Energy Muons ([LEM]) group at the Paul Scherrer Institute ([PSI]).
* The [GUI] is written in [Node.js], [JavaScript] and [Electron].
* The [Fortran] executable is built from source during packaging.
* Linux packages can be generated locally from the current source tree.
Further information can be found in the following publications:
- Z. Salman, R. M. L. McFadden, and T. Prokscha,
Modernization and Statistical Validation of a Multilayer TRIM.SP Code for
Low-Energy Muon and Ion Implantation (2026).
- J. P. Biersack and W. Eckstein,
Sputtering studies with the Monte Carlo program TRIM.SP,
Appl. Phys. A 34 (2), 73-94 (1984).
- W. Eckstein,
Computer Simulation of Ion-Solid Interactions,
Springer Series in Materials Science Vol. 10
(Springer-Verlag, Berlin, Heidelberg, 1991).
- W. Eckstein,
Backscattering and sputtering with the Monte-Carlo program TRIM.SP,
Radiat. Eff. Defects Solids 130-131 (1), 239-250 (1994).
- E. Morenzoni et al.,
Implantation studies of keV positive muons in thin metallic layers,
Nucl. Instrum. Methods Phys. Res., Sect. B 192 (3), 245-266 (2002).
### How to cite ###
If you use this software in published work, please cite the relevant
TRIM.SP references listed above and the TRIMSP-NL Workbench paper.
Repository metadata is also provided in [CITATION.cff](CITATION.cff).
### Supported platforms ###
* [Linux]
* Online at: http://musruser.psi.ch/TRIMSP-NL/
* Source repository: https://gitea.psi.ch/LMU/TRIMSP
### Installation ###
Packages are not stored in this repository. You can either run the application
directly from source or build Linux packages locally as described below.
###### Fortran code compilation ######
Install the `gfortran` compiler, then:
```bash
cd trimsp/fortran
make
```
This creates the `trimspNL` binary in the repository root. For packaged
Electron builds, the default is now to use the static binary:
```bash
cd trimsp/fortran
make trimspNL-static
```
and copy or rebuild it into:
```text
resources/bin/trimspNL
```
The application will prefer that bundled copy when running from a packaged
install. During development it can still use a local checkout copy or a
`trimspNL` binary found in the configured path or in `PATH`.
`trimspNL` now requires an explicit run basename when called directly, for
example:
```bash
./trimspNL myrun
```
This reads `myrun.inp` and writes `myrun.out`, `myrun.rge`, and `myrun.err`.
If you need the dynamic binary explicitly, build:
```bash
cd trimsp/fortran
make trimspNL
```
###### Running the GUI ######
Install [Node.js] (`nodejs`, `nodejs-libs` and `npm`),
then run:
```bash
cd trimsp
npm install
npm start
```
Note: you do not need to run `npm install` every time.
Next time you can simply run `npm start` only.
Use the `?` button for contextual Quick Start help. The adjacent share button
copies a link containing the current scientific configuration for the web
application. Shared links include layers, projectile, scan, RNG, and advanced
settings, but exclude local paths, file prefixes, worker counts, and results.
###### Building RPM and DEB packages ######
Install [Node.js] (`nodejs`, `nodejs-libs` and `npm`), plus the Fortran toolchain
(`make` and `gfortran`), then run:
```bash
cd trimsp
npm install
npm run make
```
This automatically compiles `fortran/trimspNL-static` and copies it to
`resources/bin/trimspNL` before Electron Forge builds the packages.
If static linking fails on a given machine, you can stage the dynamic binary
manually instead:
```bash
npm run build:fortran:dynamic
```
To build packages with the dynamic binary in one step, run:
```bash
npm run make:dynamic
```
For Flatpak, build with the same default static Fortran binary:
```bash
npm run make:flatpak
```
This compiles `fortran/trimspNL-static` and stages it as
`resources/bin/trimspNL` before the Flatpak packaging step.
The generated files are written under:
```text
out/make/deb/x64/
out/make/rpm/x64/
```
Typical output files are:
```text
out/make/deb/x64/trimsp__amd64.deb
out/make/rpm/x64/TrimSP--1.x86_64.rpm
```
To generate matching checksum sidecar files for each generated package, run:
```bash
npm run checksums
```
This creates files next to each package, for example:
```text
out/make/rpm/x64/TrimSP--1.x86_64.rpm.md5
out/make/rpm/x64/TrimSP--1.x86_64.rpm.sha256
```
If you only want one checksum type, you can also run:
```bash
npm run checksums:md5
npm run checksums:sha256
```
Depending on the host system, additional packaging tools may be required for
the RPM/DEB build chain.
###### Building a Flatpak ######
Install the Flatpak build tools in addition to [Node.js]:
```bash
flatpak
flatpak-builder
elfutils
```
Then run:
```bash
cd trimsp
cp fortran/trimspNL resources/bin/trimspNL
npm install
npm run make:flatpak
```
This uses Electron Forge's Flatpak maker and writes the resulting `.flatpak`
under:
```text
out/make/flatpak/x86_64/
```
Checksum sidecar files can be generated afterward with:
```bash
npm run checksums
```
The current Flatpak config grants access to the home directory and `/tmp`,
which matches how the packaged app currently handles simulation input/output.
###### Deploying on a web server ######
The repository includes the browser assets, CGI runner, and a deployment
script for an Apache-style server. With the default settings, run:
```bash
sudo ./scripts/deploy-web.sh
```
The script expects the TRIM.SP-NL engine to be installed already and installs:
```text
/var/www/html/TRIMSP-NL/ browser application
/var/www/cgi-bin/singleTrimSP.cgi CGI runner
```
By default, the CGI uses the existing executable at
`/usr/local/bin/trimspNL`. Set `TRIMSP_BIN_PATH` if it is installed elsewhere.
Deployment paths and ownership can be changed through environment variables:
| Variable | Default | Purpose |
| --- | --- | --- |
| `TRIMSP_WEB_TARGET` | `/var/www/html/TRIMSP-NL` | Browser asset directory |
| `TRIMSP_CGI_TARGET` | `/var/www/cgi-bin/singleTrimSP.cgi` | Installed CGI path |
| `TRIMSP_WEB_OWNER` | `apache` | Web file owner |
| `TRIMSP_WEB_GROUP` | `apache` | Web file group |
| `TRIMSP_BIN_PATH` | `/usr/local/bin/trimspNL` | Existing engine executable used by the CGI |
For example, to use an engine installed in `/opt/trimsp/bin`:
```bash
sudo TRIMSP_BIN_PATH=/opt/trimsp/bin/trimspNL \
./scripts/deploy-web.sh
```
The web server must execute the CGI through `/cgi-bin/singleTrimSP.cgi`. The
CGI keeps simulation files in filesystem `/tmp` and serves only requested run
outputs and archives; `/tmp` does not need to be exposed through the web
server. On SELinux systems, inspect denied operations with:
```bash
ausearch -m avc -ts recent
```
The Apache account needs permission to execute the CGI and engine and to create
the per-run directories in `/tmp`.
After a web run, the status bar provides the results archive through
**Outputs** and shows CGI status plus captured TRIM.SP-NL output through
**Details**. Diagnostic output is kept in the browser session only and is not
included in the `.tgz` archive.
### Contact ###
Zaher Salman
[Fortran]: https://fortran-lang.org/
[Node.js]: https://nodejs.org/en/
[JavaScript]: https://www.javascript.com/
[Electron]: https://www.electronjs.org/
[PSI]: https://www.psi.ch/en
[LEM]: https://www.psi.ch/en/low-energy-muons
[RPM]: https://rpm.org/
[DEB]: https://en.wikipedia.org/wiki/Deb_(file_format)
[Linux]: https://en.wikipedia.org/wiki/Linux
[Monte Carlo]: https://en.wikipedia.org/wiki/Monte_Carlo_method
[GUI]: https://en.wikipedia.org/wiki/Graphical_user_interface