You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* remove entrypoint script now that denv has been more fully adopted
* put GENIE ld libs and PATH into image build at temp location
* don't define LDMX_BASE, update LDMX_SW_INSTALL deduction
- support ldmx-sw being HOME or inside HOME
- remove GENIE LD_LIBRARY_PATH and PATH now in image
- cleanup CMAKE_PREFIX_PATH deduction
* update comments in init script
* move genie ld libs and PATH defs to where GENIE is built
* remove custom Geant4 scripting
* first draft of updating documentation of custom geant4
* move base definition of CMAKE_PREFIX_PATH into Dockerfile
* reread and fixup custom geant4 instructions
Geant4 is our main simulation engine and it has a large effect on the products of our simulation samples.
4
4
As such, it is very common to compare multiple different versions, patches, and tweaks to Geant4 with our simulation.
5
5
6
-
With release 4.2.0 of the ldmx/dev image, the entrypoint script now checks the environment variable `LDMX_CUSTOM_GEANT4` for a path to a local installation of Geant4.
7
-
This allows the user to override the Geant4 that is within the image with one that available locally. In this way, you can choose whichever version of Geant4 you want,
8
-
with whatever code modifications applied, with whatever build instructions you choose.
9
-
10
6
~~~admonish warning title="Confirm Image Version"
11
7
Make sure you have an image that is at least v4.2.0.
12
8
You can check your version of the image by [inspecting the image labels](image-version.md).
13
9
~~~
14
10
15
-
###Building Your Geant4
11
+
## Building Your Geant4
16
12
You can build your Geant4 in a similar manner as ldmx-sw. It does take much longer to compile than ldmx-sw since it is larger, so be sure to leave enough time for it.
17
13
18
14
```admonish warning title="Remember"
19
15
You can only run this custom build of Geant4 with whatever image you are building it with, so make sure you are happy with the image version you are using.
20
16
```
21
17
22
18
```shell
23
-
cd path/to/ldmx #directory that contains ldmx-sw
19
+
cd path/to/ldmx/ldmx-sw# ldmx-sw you want to build with custom geant4
24
20
git clone git@github.com:LDMX-Software/geant4.git # or could be mainline Geant4 or an unpacked tar-ball
Now building Geant4 from source has a lot of configuration options that can be used to customize how it is built.
29
25
Below are a few that are highlighted for how we use containers and their interaction with the Geant4 build.
30
26
31
-
-`CMAKE_INSTALL_PREFIX`: This should be set to a path accessible from the container so that the programs within the container can read from and write to this directory. If the geant4 build directory is within `LDMX_BASE` (like it is above), then you could do something like `-DCMAKE_INSTALL_PREFIX=../install` when you run `ldmx cmake` within the build directory.
32
-
-`GEANT4_INSTALL_DATADIR`: If you are building a version of Geant4 that has the same data files as the Geant4 version built into the container image, then you can tell the Geant4 build to use those data files with this option, saving build time and disk space. This is helpful if (for example) you are just re-building the same version of Geant4 but in Debug mode. You can see where the Geant4 data is within the container with `ldmx 'echo ${G4DATADIR}'` and then use this value `-DGEANT4_INSTALL_DATADIR=/usr/local/share/geant4/data`.
27
+
-`CMAKE_INSTALL_PREFIX`: This should be set to a path accessible from the container so that the programs within the container can read from and write to this directory. If the geant4 build directory is within ldmx-sw (like it is above), then you could do something like `-DCMAKE_INSTALL_PREFIX=geant4/install` when you run `denv cmake ...`
28
+
- If you are keeping Geant4 outside of ldmx-sw, then you may need to mount it into the ldmx-sw container image with `denv config mounts` if it is not already within a mounted directory.
29
+
-`GEANT4_INSTALL_DATADIR`: If you are building a version of Geant4 that has the same data files as the Geant4 version built into the container image, then you can tell the Geant4 build to use those data files with this option, saving build time and disk space. This is helpful if (for example) you are just re-building the same version of Geant4 but in Debug mode. You can see where the Geant4 data is within the container with `denv printenv G4DATADIR` and then use this value `-DGEANT4_INSTALL_DATADIR=/usr/local/share/geant4/data`.
33
30
34
-
The following are the build options used when setting up the container and are likely what you want to get started
31
+
The following are the build options used when setting up the image and are likely what you want to get started
35
32
-`-DGEANT4_USE_GDML=ON` Enable reading geometries with the GDML markup language which is used in LDMX-sw for all our geometries
36
33
-`-DGEANT4_INSTALL_EXAMPLES=OFF` Don't install the Geant4 example applications (just to save space and compilation time)
37
34
-`-DGEANT4_USE_OPENGL_X11=ON` enable an X11-based GUI for inspecting geometries
38
35
-`-DGEANT4_MULTITHREADED=OFF` If you are building a version of Geant4 that is multithreaded by default, you will want to disable it with. The dynamic loading used in LDMX-sw will often not work with a multithreaded version of Geant4
39
36
40
-
####Concerns when building different versions of Geant4 than 10.2.3
37
+
### Concerns when building different versions of Geant4 than 10.2.3
41
38
42
-
For most use cases you will be building a modified version of the same release of Geant4 that is used in the container (10.2.3). It is also possible to build and use later versions of Geant4 although this should be done with care. In particular
43
-
- Different Geant4 release versions will require that you rebuild LDMX-sw for use with that version, it will not be sufficient to set the `LDMX_CUSTOM_GEANT4` environment variable and pick up the shared libraries therein
39
+
For most use cases you will be building a modified version of the same release of Geant4 that is used in the image (10.2.3). It is also possible to build and use later versions of Geant4 although this should be done with care. In particular
40
+
- Different Geant4 release versions will require that you rebuild LDMX-sw for use with that version, it will not be sufficient to just source the custom Geant4's environment and pick up the shared libraries therein
44
41
- Recent versions of Geant4 group the electromagnetic processes for each particle into a so-called general process for performance reasons. This means that many features in LDMX-sw that rely on the exact names of processes in Geant4 will not work. You can disable this by inserting something like the following in [RunManager::setupPhysics()](https://github.com/LDMX-Software/SimCore/blob/20d9bcb6d2bad2b99255cf32c1b3f099b26752b0/src/SimCore/RunManager.cxx#L60)
45
42
```C++
46
43
// Make sure to include G4EmParameters if needed
@@ -49,9 +46,8 @@ auto electromagneticParameters {G4EmParameters::Instance()};
49
46
// i.e. G4GammaGeneralProcess and G4ElectronGeneralProcess
- Geant4 relies on being able to locate a set of datasets when running. For builds of 10.2.3, the ones that are present in the container will suffice but other versions may need different versions of these datasets. If you run into issues with this, use `ldmx env` and check that the following environment variables are pointing to the right location
49
+
- Geant4 relies on being able to locate a set of datasets when running. For builds of 10.2.3, the ones that are present in the container will suffice but other versions may need different versions of these datasets. If you run into issues with this, use `denv printenv` and check that the following environment variables are pointing to the right location
53
50
- `GEANT4_DATA_DIR` should point to `$LDMX_CUSTOM_GEANT4/share/Geant4/data`
54
-
- You can define the `LDMX_CUSTOM_GEANT4_DATA_DIR` environment variable in the container environment to manually point it to a custom location
55
51
- The following environment variables should either be unset or point to the correct location in `GEANT4_DATA_DIR`
- When using CMake, ensure that the right version of Geant4 is picked up at configuration time (i.e. when you run `ldmx cmake`)
68
-
- You can always check the version that is used in a build directory by running `ldmx ccmake .` in the build directory and searching for the Geant4 version variable
63
+
- When using CMake, ensure that the right version of Geant4 is picked up at configuration time (i.e. when you run `denv cmake`)
64
+
- You can always check the version that is used in a build directory by running `denv ccmake .` in the build directory and searching for the Geant4 version variable
69
65
- If the version is incorrect, you will need to re-configure your build directory. If `cmake` isn't picking up the right Geant4 version by default, ensure that the `CMAKE_PREFIX_PATH` is pointing to your version of Geant4
70
66
- Make sure that your version of Geant4 was built with multithreading disabled
71
67
@@ -216,8 +212,100 @@ mostly the same datasets, it is easier just to have each Geant4 version have its
216
212
own downloaded copies of the datasets.
217
213
~~~
218
214
215
+
## Running with your Geant4
216
+
The way we use different versions of Geant4 has changed over the years, so it depends on which version of the image you are using.
217
+
218
+
### >=5.1.1
219
+
Since we are using `denv` to interact with the development image, you now have access to a local file that
220
+
can customize your development environment within the container image.
221
+
This file is `.profile` located within the container's home directory.
222
+
To find the location of this file, run
223
+
```sh
224
+
denv printenv HOME
225
+
```
226
+
from the location where you want to use the custom Geant4.
227
+
The path output by this command is where the `.profile` is that you will edit.
After these changes, you should be able to compile and run ldmx-sw from this environment using
281
+
your custom build of Geant4 with the normal development commands.
282
+
```
283
+
just compile
284
+
just fire config.py
285
+
```
286
+
287
+
You can make sure your Geant4 was found and is being used by going into the build and inspecting
288
+
the configuration.
289
+
```
290
+
cd build && denv ccmake .
291
+
```
292
+
You should see `Geant4_DIR` set to the path of your custom Geant4 instead of some path in `/usr/local/...`.
293
+
294
+
~~~admonish note title="Returning to Normal" collapsible=true
295
+
If you want to return to the normal environment, you can comment-out or remove your `.profile` changes
296
+
at the bottom of that file.
297
+
298
+
A nuclear option is to have the image re-copy of new `.profile` by removing the `.profile` file and a `denv`
299
+
internal file signalling that the profile has already been copied.
300
+
```
301
+
rm .profile .denv/skel-init
302
+
```
303
+
~~~
219
304
220
-
### Running with your Geant4
305
+
### <5.1.1,>=4.2.0
306
+
With release 4.2.0 of the ldmx/dev image, the entrypoint script now checks the environment variable `LDMX_CUSTOM_GEANT4` for a path to a local installation of Geant4.
307
+
This allows the user to override the Geant4 that is within the image with one that available locally. In this way, you can choose whichever version of Geant4 you want,
308
+
with whatever code modifications applied, with whatever build instructions you choose.
221
309
Just like with ldmx-sw, you can only run a specific build of Geant4 in the same image that you used to build it.
222
310
```shell
223
311
just setenv LDMX_CUSTOM_GEANT4=/path/to/geant4/install
# Developer option: If a custom geant4 install is to be used, source the
28
-
# environment script from that install
29
-
#
30
-
# Note: Use with care!
31
-
#
32
-
# The custom Geant4 install still needs to have been built with the same
33
-
# container environment
34
-
if [ -n"${LDMX_CUSTOM_GEANT4+x}" ];then
35
-
# Overly obnoxious warning to make sure this feature isn't used accidentally
36
-
# Also detail how to set custom Geant4 data directories
37
-
if [ -z"${LDMX_CUSTOM_GEANT4_CONFIRM_DEV+x}" ];then
38
-
echo"Warning: You are relying on a non-container version of Geant4. This mode of operation can come with some reproducibility concerns if you aren't careful. "
39
-
echo"Define the environment variable LDMX_CUSTOM_GEANT4_CONFIRM_DEV in the container environment to suppress this message"
40
-
echo"If using the standard ldmx-env.sh shell script, use 'ldmx setenv' to set environment variables within the container environment"
41
-
echo"You may also want to define LDMX_CUSTOM_GEANT4_DATA_DIR if you are using a version of Geant4 different from 10.2.3 and the Geant4 build you intend to use has the data directory in an non-standard location (i.e. one that isn't picked up by the geant4.sh script) "
42
-
fi
43
-
# First: Unset the container-specific versions of the Geant4 data directories
44
-
unset G4NEUTRONHPDATA
45
-
unset G4LEDATA
46
-
unset G4LEVELGAMMADATA
47
-
unset G4RADIOACTIVEDATA
48
-
unset G4PARTICLEXSDATA
49
-
unset G4PIIDATA
50
-
unset G4REALSURFACEDATA
51
-
unset G4SAIDXSDATA
52
-
unset G4ABLADATA
53
-
unset G4INCLDATA
54
-
unset G4ENSDFSTATEDATA
55
-
unset G4NEUTRONXSDATA
56
-
# If explicitly requested, use a custom location for Geant4's data directories
0 commit comments