Remeis-Wiki - Recent changes [en]

Guided Tours and Public Outreach

Zalot — Tue, 18 Aug 2026 10:53:37 GMT

Tours looking for a guide

← Older revision		Revision as of 12:53, 18 August 2026
Line 162:		Line 162:

	\|-		\|-
	\| ~~Friday~~, 21.08.2026 at 20:00		\| Wednesday, 26.08.2026 at 19:00
	\| German		\| English or German
	\| ~~Koebler~~		\| Geppert
	\| ~~Tour also possible on 23.08.~~, ~~24.08~~., ~~25.08., 31.08. or 01.09.~~		\| Family who wants to visit the observatory for their wedding anniversary, only short tour requested. More info available, just contact me!
	\| 10 adults		\| 2 adults, 2 children (aged unknown)
	\| Yes		\| Yes
	\| 07.08.2026		\| 23.08.2026

	\|-		\|-

Bundschuh house booking

Gulbahar — Mon, 17 Aug 2026 11:50:36 GMT

Created page with " Category:Visitors Link to the calendar to view and book the Bundschuh house for guests: https://sternwarte.uni-erlangen.de/calendar/"

New page

[[Category:Visitors]]

Link to the calendar to view and book the Bundschuh house for guests: https://sternwarte.uni-erlangen.de/calendar/

Welcome Newbies

Zalot — Thu, 06 Aug 2026 07:00:58 GMT

Carpool

← Older revision		Revision as of 09:00, 6 August 2026
(One intermediate revision by the same user not shown)
Line 94:		Line 94:
	Contact person: Max, Nico		Contact person: Max, Nico

	We coordinate commuting for the carpool via the app [https://www.michael-obach.de MyCarpoolApp], which is available on Android and iOS. We use a group account with the name "Remeis Reloaded". The access password is Sternwartstr. 7 . By using "change user" in the menu you can create your user account. The fuel costs are shared equally by everybody in the car. In addition to the fuel costs there is a rate of 2.50€ per car per ride, which is also shared equally by everybody. This is used to reduce the driver's additional costs, like maintenance and such.		We coordinate commuting for the carpool via the app [https://www.michael-obach.de MyCarpoolApp], which is available on Android and iOS. We use a group account with the name "Remeis Reloaded". The access password is "Sternwartstr. 7". By using "change user" in the menu you can create your user account. The fuel costs are shared equally by everybody in the car. In addition to the fuel costs there is a rate of 2.50€ per car per ride, which is also shared equally by everybody. This is used to reduce the driver's additional costs, like maintenance and such.

			The meeting point in Erlangen is directly behind the train station [https://maps.app.goo.gl/YKwzgQVLrnM32bLo9 at the Northern end of the Großparkplatz (large car park)].

	=Lunch=		=Lunch=

Lab course manual

Zalot — Fri, 31 Jul 2026 07:09:18 GMT

GIT repository

← Older revision		Revision as of 09:09, 31 July 2026
Line 1:		Line 1:
	== GIT repository ==		== GIT repository ==

	git clone ~~phoenix~~.sternwarte.uni-erlangen.de:/data/git/Praktikumsanleitung.git		git clone serpens.sternwarte.uni-erlangen.de:/data/git/Praktikumsanleitung.git
	cd Praktikumsanleitung		cd Praktikumsanleitung
	cd anleitung		cd anleitung

Guided Tours and Public Outreach

Zalot — Thu, 30 Jul 2026 13:12:33 GMT

Tours looking for a guide

← Older revision	Revision as of 15:12, 30 July 2026
(One intermediate revision by the same user not shown)
(No difference)

Geant4

Thalhammer — Thu, 30 Jul 2026 08:27:56 GMT

← Older revision		Revision as of 10:27, 30 July 2026
(2 intermediate revisions by the same user not shown)
Line 3:		Line 3:
	This page describes a practical workflow for building and running		This page describes a practical workflow for building and running
	[https://geant4.web.cern.ch/ Geant4] Monte-Carlo simulations on the Remeis		[https://geant4.web.cern.ch/ Geant4] Monte-Carlo simulations on the Remeis
	~~compute~~ cluster, using SLURM for ~~parameter scans~~ and conda to provide the		cluster, using SLURM for longer runs and conda to provide the
	Geant4 ~~toolkit~~. The examples are taken from ''Cu67'' simulations,		Geant4 package itself. The examples are taken from ''Cu67'' simulations,
	but the mechanics apply to any Geant4 application.		but the mechanics apply to any Geant4 application.

	== Overview ==		== Overview ==

	A Geant4 simulation ~~on the cluster~~ involves three steps, although the last step is optional:		A Geant4 simulation involves three steps, although the last step is optional:

	* the compiled Geant4 application (a C++ executable, here <code>cu67_sim</code>);		* the compiled Geant4 application (a C++ executable, here <code>cu67_sim</code>);
Line 183:		Line 183:

	If interest lies not in exploring the parameter but to maximize statistics for a single simulation, the parameters just need to be kept constant and the results of identical simulations merged in the end.		If interest lies not in exploring the parameter but to maximize statistics for a single simulation, the parameters just need to be kept constant and the results of identical simulations merged in the end.

			== Miscellaneous ==
			* If you need TENDL data – a nuclear data library which provides the output of the TALYS nuclear model code – the data is available on the cluster and you can set the respective environmental variable accordingly:
			<syntaxhighlight lang="bash">
			export G4PARTICLEHPDATA=/userdata/data/thalhammer/geant4/G4TENDL1.4
			</syntaxhighlight>

Guided Tours and Public Outreach

Zalot — Mon, 27 Jul 2026 05:39:16 GMT

Tours looking for a guide

← Older revision		Revision as of 07:39, 27 July 2026
Line 160:		Line 160:
	! Observing		! Observing
	! Deadline for guides		! Deadline for guides

			\|-
			\| Friday, 21.08.2026 at 20:00
			\| German
			\| Koebler
			\| Tour also possible on 23.08., 24.08., 25.08., 31.08. or 01.09.
			\| 10 adults
			\| Yes
			\| 07.08.2026

	\|-		\|-

Geant4

Thalhammer — Fri, 24 Jul 2026 13:30:01 GMT

← Older revision		Revision as of 15:30, 24 July 2026
(5 intermediate revisions by the same user not shown)
Line 1:		Line 1:
	= Running Geant4 simulations on the Remeis cluster =		= Running Geant4 simulations on the Remeis cluster =

	This page describes a practical workflow for building and running		This page describes a practical workflow for building and running
Line 26:		Line 26:
	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	module load conda		module load conda
	conda create -n geant4 -c geant4 numpy scipy matplotlib		conda create -n geant4 -c conda-forge geant4 numpy scipy matplotlib
	</syntaxhighlight>		</syntaxhighlight>

	~~and~~ load it in every subsequent session (interactive shell or batch script):		This might take a while. Afterwards, you can load it in every subsequent session (interactive shell or batch script) -- you might also place the following into you .bashrc /.cshrc:

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
Line 41:		Line 41:

	== Building the application ==		== Building the application ==

			At this point you can the build your sepecific application and setup a file estructurer like this:

			<syntaxhighlight lang="bash">
			+- CMakeLists.txt
			+- cu67.cc
			+- include/
			\| ... headers.hh ...
			+- src/
			... sources.cc ...
			</syntaxhighlight>


	CMake locates the conda-provided Geant4 through <code>CMAKE_PREFIX_PATH</code>,		CMake locates the conda-provided Geant4 through <code>CMAKE_PREFIX_PATH</code>,
	which is pointed at the active environment via <code>$CONDA_PREFIX</code>:		which is pointed at the active environment via <code>$CONDA_PREFIX</code>:´. And the application can be compiled via:

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
Line 54:		Line 66:
	</syntaxhighlight>		</syntaxhighlight>

	It can be ~~use full~~ to ~~contain this in~~ e.g. a <code>build.sh</code>, scripts, which builds the simulation and copies the resulting <code>cu67_sim</code> executable to the		It can be usefull to package these, e.g. in a <code>build.sh</code>, scripts, which builds the simulation and copies the resulting <code>cu67_sim</code> executable to the
	project root.		project root - or use a makefile.

	== Macros and templates ==		== Macros and templates ==
Line 95:		Line 107:
	"1.0 mm" as a tag like <code>t1000um</code>).		"1.0 mm" as a tag like <code>t1000um</code>).

	== Python ~~drivers~~ ==		== Python Wrapper ==

	Python can be ~~used~~ to run everything together. ~~For~~ a ~~single-machine scan~~		Python can be useful to run everything together. To can e.g. several simulations on a grid of parameters. A script can be used that:
	~~(<code>scan_thickness~~.~~py</code>) each grid point~~:

	# renders <code>run.mac.tpl</code> into a concrete macro with the point's parameters;		# renders <code>run.mac.tpl</code> into a concrete macro with the point's parameters;
Line 109:		Line 120:
	== Running scans with SLURM ==		== Running scans with SLURM ==

	Parameter scans are submitted as job arrays: the ~~driver~~		For longer simulations it is best to use SLURM. Parameter scans are submitted as job arrays: the python script called by srun runs the simulation for one grid point per array task,
	~~(<code>scan_thickness_slurm.py</code>)~~ runs one grid point per array task,
	indexed by <code>$SLURM_ARRAY_TASK_ID</code>, with each task using		indexed by <code>$SLURM_ARRAY_TASK_ID</code>, with each task using
	<code>$SLURM_CPUS_PER_TASK</code> Geant4 worker threads. The batch script:		<code>$SLURM_CPUS_PER_TASK</code> Geant4 worker threads. The batch script. More CPUS per task can be used but as they all need to be available simultaneously, SLURM might delay the scheduling of the job:

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
Line 140:		Line 150:
	</syntaxhighlight>		</syntaxhighlight>

	Submit it ~~(creating the log directory first)~~ with:		Submit it with:

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	~~mkdir -p log &&~~ sbatch scan_thickness.slurm		sbatch scan_thickness.slurm
	</syntaxhighlight>		</syntaxhighlight>

Line 150:		Line 160:
	* The <code>--array</code> range must span the number of grid points (0–39 here = 40 points). Keep it in sync with the grid defined in the driver.		* The <code>--array</code> range must span the number of grid points (0–39 here = 40 points). Keep it in sync with the grid defined in the driver.
	* Isolated working directories. Each task runs in its own work directory, so the flat per-thread CSVs of concurrently running tasks never collide.		* Isolated working directories. Each task runs in its own work directory, so the flat per-thread CSVs of concurrently running tasks never collide.
	* Rather than 40 tasks appending to one summary file, each task writes its single result ~~row atomically~~ to <code>rows/<tag>.csv</code>.		* Rather than 40 tasks appending to one summary file, each task writes its single result to <code>rows/<tag>.csv</code>.
	* A point whose row file already exists is skipped, so a partially failed array can simply be resubmitted.
	* <code>nice -n +19</code> keeps the jobs from crowding out interactive use of the node.		* <code>nice -n +19</code> keeps the jobs from crowding out interactive use of the node.

Geant4

Thalhammer — Thu, 23 Jul 2026 13:59:17 GMT

Create documentation for Geant4

New page

= Running Geant4 simulations on the Remeis cluster =

This page describes a practical workflow for building and running
[https://geant4.web.cern.ch/ Geant4] Monte-Carlo simulations on the Remeis
compute cluster, using SLURM for parameter scans and conda to provide the
Geant4 toolkit. The examples are taken from ''Cu67'' simulations,
but the mechanics apply to any Geant4 application.

== Overview ==

A Geant4 simulation on the cluster involves three steps, although the last step is optional:

* the compiled Geant4 application (a C++ executable, here <code>cu67_sim</code>);
* one or more macro files (<code>.mac</code>) that configure geometry, beam and run size;
* a Python wrapper that renders macros from a template, launches the executable, merges the output, and produces summary tables and plots.

For parameter scans the Python wrapper is submitted to a SLURM array job,
so that each grid point runs as an independent task.

== Geant4 via conda ==

Geant4 (including its data libraries) is available from
[https://conda-forge.org/ conda-forge]; there is no need to compile the toolkit
by hand. Create the environment once:

<syntaxhighlight lang="bash">
module load conda
conda create -n geant4 -c geant4 numpy scipy matplotlib
</syntaxhighlight>

and load it in every subsequent session (interactive shell or batch script):

<syntaxhighlight lang="bash">
module load conda
conda activate geant4
</syntaxhighlight>

Activating the environment sets the Geant4 data-library variables
(<code>G4NEUTRONHPDATA</code>, <code>G4PARTICLEXSDATA</code>, …), so — unlike a
manual install — there is no <code>geant4.sh</code> to source. Version 11.4 is the version used so far.

== Building the application ==

CMake locates the conda-provided Geant4 through <code>CMAKE_PREFIX_PATH</code>,
which is pointed at the active environment via <code>$CONDA_PREFIX</code>:

<syntaxhighlight lang="bash">
module load conda
conda activate geant4

mkdir -p build && cd build
cmake -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
make -j$(nproc)
</syntaxhighlight>

It can be use full to contain this in e.g. a <code>build.sh</code>, scripts, which builds the simulation and copies the resulting <code>cu67_sim</code> executable to the
project root.

== Macros and templates ==

What is simulated is set by macro files:

<syntaxhighlight lang="bash">
./cu67_sim run.mac
</syntaxhighlight>

or interactively (with visualisation) by passing no argument.

Two points to keep in mind are:

* Commands that alter the geometry (e.g. <code>/det/converter/halfThickness</code>) must appear before <code>/run/initialize</code>, because the geometry is built when the run is initialised. Beam and run commands (<code>/gun/…</code>, <code>/run/beamOn</code>) come after.
* Multithreaded runs are requested with <code>/run/numberOfThreads N</code>. Note that high-precision (HP) physics data can cost ~1–2 GB per worker thread, which matters for the memory requested via SLURM.

For parameter scans the macro is kept as a template (<code>run.mac.tpl</code>)
with Python <code>str.format</code> placeholders, which the driver substitutes at
run time:

<syntaxhighlight lang="text">
/det/converter/halfThickness {HALF_THICKNESS_MM} mm
/analysis/setFileName {OUTPUT_BASE}

/run/initialize

/gun/particle e-
/gun/energy {BEAM_ENERGY_MEV} MeV
/gun/position 0 0 -5 cm
/gun/direction 0 0 1

/tracking/verbose 0
/run/beamOn {N_EVENTS}
</syntaxhighlight>

Caveat: <code>/analysis/setFileName</code> treats text after the last dot
as a file extension, so output base names must not contain dots (e.g. encode
"1.0 mm" as a tag like <code>t1000um</code>).

== Python drivers ==

Python can be used to run everything together. For a single-machine scan
(<code>scan_thickness.py</code>) each grid point:

# renders <code>run.mac.tpl</code> into a concrete macro with the point's parameters;
# runs the executable and captures stdout;
# merges the per-thread CSV output and moves it into the output directory;
# parses the result from stdout with a regex.

At the end it writes a summary CSV and the plots.

== Running scans with SLURM ==

Parameter scans are submitted as job arrays: the driver
(<code>scan_thickness_slurm.py</code>) runs one grid point per array task,
indexed by <code>$SLURM_ARRAY_TASK_ID</code>, with each task using
<code>$SLURM_CPUS_PER_TASK</code> Geant4 worker threads. The batch script:

<syntaxhighlight lang="bash">
#!/bin/bash
#SBATCH --job-name cu67_scan
#SBATCH --partition meggie
#SBATCH --account meggie
#SBATCH --time 12:00:00
#SBATCH --output log/scan_%A_%a.out
#SBATCH --error log/scan_%A_%a.err
#SBATCH --array 0-39
#SBATCH --ntasks 1
#SBATCH --cpus-per-task 4
#SBATCH --mem-per-cpu 1G
#SBATCH --mail-type END,FAIL
#SBATCH --mail-user user@mail.de

module load conda
conda activate geant4

cd /path/to/project

srun /usr/bin/nice -n +19 \
python3 scan_thickness_slurm.py \
--task-id ${SLURM_ARRAY_TASK_ID} \
--threads ${SLURM_CPUS_PER_TASK}
</syntaxhighlight>

Submit it (creating the log directory first) with:

<syntaxhighlight lang="bash">
mkdir -p log && sbatch scan_thickness.slurm
</syntaxhighlight>

A few points are relevant for running simulations on the cluster:

* The <code>--array</code> range must span the number of grid points (0–39 here = 40 points). Keep it in sync with the grid defined in the driver.
* Isolated working directories. Each task runs in its own work directory, so the flat per-thread CSVs of concurrently running tasks never collide.
* Rather than 40 tasks appending to one summary file, each task writes its single result row atomically to <code>rows/<tag>.csv</code>.
* A point whose row file already exists is skipped, so a partially failed array can simply be resubmitted.
* <code>nice -n +19</code> keeps the jobs from crowding out interactive use of the node.

== Collecting and plotting ==

After the array finishes, a single collect step merges the per-task row
files into the summary table and draws the plots (this is the step that needs
matplotlib):

<syntaxhighlight lang="bash">
python3 scan_thickness_slurm.py --collect
</syntaxhighlight>

It can also be chained as a dependent job so it runs automatically once the
array completes:

<syntaxhighlight lang="bash">
sbatch --dependency=afterany:<jobid> --ntasks 1 \
--wrap "python3 scan_thickness_slurm.py --collect"
</syntaxhighlight>

If interest lies not in exploring the parameter but to maximize statistics for a single simulation, the parameters just need to be kept constant and the results of identical simulations merged in the end.

== Summary ==

{| class="wikitable"
! Step !! Command
|-
| Load Geant4 || <code>module load conda && conda activate geant4</code>
|-
| Build || <code>cmake -DCMAKE_PREFIX_PATH=$CONDA_PREFIX .. && make -j</code>
|-
| Single run || <code>./cu67_sim run.mac</code>
|-
| Submit scan || <code>mkdir -p log && sbatch scan_thickness.slurm</code>
|-
| Collect + plot || <code>python3 scan_thickness_slurm.py --collect</code>
|}

[[Category:Software]]