GeoModel issueshttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues2024-03-27T12:57:32+01:00https://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/106Documentation: Update instructions for EL9, etc2024-03-27T12:57:32+01:00Nicholas StylesDocumentation: Update instructions for EL9, etcI recently tried building GeoModel inside an EL9 container (`setupATLAS -c el9`) and found a few issues with the instructions. In general Centos7 should be removed from the documentation and updated for EL9, given that support for Centos...I recently tried building GeoModel inside an EL9 container (`setupATLAS -c el9`) and found a few issues with the instructions. In general Centos7 should be removed from the documentation and updated for EL9, given that support for Centos7 is being dropped by CERN. I thought these and a few other points might be useful to report ahead of the documentation week in case
- Instructions [here](https://geomodel.web.cern.ch/home/dev/#using-cvmfs-and-lcg) should point to a newer LCG version which supports EL9.
- If one is building `simage` is the patch reported as necessary for EL9 also? I think so based on my experience - I got the following when I tried without it:
```
cmake -DCMAKE_INSTALL_PREFIX=../install -DSIMAGE_BUILD_DOCUMENTATION=0 -DSIMAGE_BUILD_EXAMPLES=0 -DSIMAGE_LIBSNDFILE_SUPPORT=0 -DSIMAGE_MPEG2ENC_SUPPORT=0 -DSIMAGE_OGGVORBIS_SUPPORT=0 ../simage
[...]
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find GIF (missing: GIF_LIBRARY GIF_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake/Modules/FindGIF.cmake:109 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:279 (find_package)
-- Configuring incomplete, errors occurred!
```
I don't know that this is the same problem as the patch solves, but in any case it seems not to work out-of-the-box?
- When installing GeoModel via the following to use all the built-in externals:
```
cmake -DCMAKE_INSTALL_PREFIX=../install -DGEOMODEL_USE_BUILTIN_EIGEN3=1 -DGEOMODEL_USE_BUILTIN_XERCESC=1 -DGEOMODEL_USE_BUILTIN_JSON=1 -DGEOMODEL_USE_BUILTIN_COIN3D=1 -DGEOMODEL_BUILD_VISUALIZATION=1 -DGEOMODEL_BUILD_TOOLS=1 ../GeoModel/
```
it seems to all compile fine, but at runtime I see:
```
Apptainer> ../install/bin/gmex
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-nstyles'
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
VP1MESSAGE: Successfully loaded libGXGeometryPlugin.so
VP1MESSAGE: providing channels: Geometry
VP1MESSAGE: Geometry/Geo: VP1GeometrySystem::buildController
```
and `gmex` fails with the message that it can't open a valid OpenGL canvas. Is this a known issue? Perhaps an issue specific to the container? I will try again on lxplus where I can run natively in EL9 to check.
- Not EL9 specific (I think), but the handling of external dependencies is a bit unclear... to me the documentation implies that either using the built-in third-party packages OR using an LCG release should mean one can "easily set up a recent version of CMake, Qt and all the other dependency packages ... After that, you can build the `GeoModel` without any extra options." and while for the built-in versions that seems to work up to the run-time issue I mention from `libGL`, after setting up a recent (EL9-compatible) LCG release (`LCG_104d`) I see:
```
-- Building GeoModelVisualization as part of the root GeoModel project.
CMake Error at cmake/SetupCoin3D.cmake:113 (find_package):
By not providing "FindCoin.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Coin", but
CMake did not find one.
Could not find a package configuration file provided by "Coin" with any of
the following names:
CoinConfig.cmake
coin-config.cmake
Add the installation prefix of "Coin" to CMAKE_PREFIX_PATH or set
"Coin_DIR" to a directory containing one of the above files. If "Coin"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (most recent call first):
GeoModelVisualization/CMakeLists.txt:67 (include)
```
so this doesn't seem to work out-of-the-box for `Coin`.
- In the "Post install settings" all of the paths to the `install` directory are given as relative paths like `.../install`. I guess this is to avoid any issues of the precise paths that people have used? The problem is that then if anyone tries to run in a slightly different location then files will not be found. It might be better then to provide instructions with an obvious placeholder path, so that it will be clear to people that they should set it to the correct thing for where they built the code, and that it should be a full path ideally to avoid run-time issues?
FYI @xilin @sroe @rbianchihttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/105required packages not abailable in ubuntui 22.042024-03-06T12:15:16+01:00Guillermo Loustau De Linaresrequired packages not abailable in ubuntui 22.04```bash
sudo apt install git cmake wget unzip build-essential nlohmann-json3-dev libsoqt-bb-dev libxerces-c-dev libeigen3-dev geant4-dev libsqlite3-dev zlib1g-dev libhdf5-dev qtbase5-dev libhepmc3-dev pythia-dev
Reading package lists... ...```bash
sudo apt install git cmake wget unzip build-essential nlohmann-json3-dev libsoqt-bb-dev libxerces-c-dev libeigen3-dev geant4-dev libsqlite3-dev zlib1g-dev libhdf5-dev qtbase5-dev libhepmc3-dev pythia-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package pythia-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
Package geant4-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
Package libsoqt-bb-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'libsoqt-bb-dev' has no installation candidate
E: Package 'geant4-dev' has no installation candidate
E: Package 'pythia-dev' has no installation candidate
```https://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/104Packaging: macOS, sometimes brew uses the "reinstall" flag for installation2024-01-24T18:41:52+01:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chPackaging: macOS, sometimes brew uses the "reinstall" flag for installationI just noticed that, sometimes (it is not clear under what circumstances, yet), `brew` uses the "reinstall" flag for installation names, and that prevents libs and executables to be found.
See this example:
![image](/uploads/dbedd212ec...I just noticed that, sometimes (it is not clear under what circumstances, yet), `brew` uses the "reinstall" flag for installation names, and that prevents libs and executables to be found.
See this example:
![image](/uploads/dbedd212eca8ce6093bfa0ad6be9f3c6/image.png)
In the example above, `gmex` could not be found, because brew installed `geomodel-visualization` in a folder called `5.0.0.reinstall`, instead of a simpler `5.0.0`.Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/103Latest main does not build on macOS due to some missing C++17 features in App...2024-01-19T13:44:54+01:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chLatest main does not build on macOS due to some missing C++17 features in Apple ClangWhile testing the latest main on macOS, I got an error due to a missing C++17 feature in Apple Clang.
We saw others of those in the past; for example, Apple Clang did not support `std::filesystem` until recently.
This time is the turn ...While testing the latest main on macOS, I got an error due to a missing C++17 feature in Apple Clang.
We saw others of those in the past; for example, Apple Clang did not support `std::filesystem` until recently.
This time is the turn of `std::from_chars`:
```
/Users/rbianchi/work/atlas/geomodel/test_main_Jan24/GeoModel/GeoModelTools/GeoModelFuncSnippets/src/StringUtils.cxx:123:13: error: call to deleted function 'from_chars'
if (std::from_chars(str.data(), str.data() + str.size(), number).ec != std::errc{}) {
^~~~~~~~~~~~~~~
```
For which, I found a comment here: https://stackoverflow.com/a/74962482
I would ping @johannes, so he knows.
Cc: @boudreau @tsulaiahttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/102TracksSystem supplying I/O for Geant4 tracks fails with multiple threads on t...2023-12-20T17:19:53+01:00Joseph BoudreauTracksSystem supplying I/O for Geant4 tracks fails with multiple threads on the Mac.Title says it all. The failure occurs in the HDF5 code. This is observed on the MAC.Title says it all. The failure occurs in the HDF5 code. This is observed on the MAC.https://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/101GMEX Instability on Mac2023-12-22T13:11:30+01:00Joseph BoudreauGMEX Instability on MacWhen gmex is started without any arguments....
... and when the mouse moves around as the input file select dialog appears
... and if you happen to be working on a Mac, or more precisely a Mac with an M1 chip
... you can quite often c...When gmex is started without any arguments....
... and when the mouse moves around as the input file select dialog appears
... and if you happen to be working on a Mac, or more precisely a Mac with an M1 chip
... you can quite often crash the program, which is not nice. It seems to be an issue with the underlying windowing system. It has been with us since at least GeoModel version 4.6.0.Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/100Our Release bundles do not contain ATLASExtensions2023-12-22T12:56:59+01:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chOur Release bundles do not contain ATLASExtensionsOur Release source bundles do not contain `ATLASExtensions` code. This also affects the build of GeoModel inside the **AthenaExternals**, when we want to build submodules code there.
For example, as part of the overall switch of `GeoMo...Our Release source bundles do not contain `ATLASExtensions` code. This also affects the build of GeoModel inside the **AthenaExternals**, when we want to build submodules code there.
For example, as part of the overall switch of `GeoModelG4` and related packages to the Externals, the `ATLASExtensions` can not be built in the `AthenaExternals` right now, with the current machinery. In the Externals CMake configuration, in fact, we start from bundled sources, but that fails when we want to build the Extensions. For that to succeed, we need to move to a fresh Git clone with recursive submodules or to a checkout of a tag.
Cc: @tsulaia @boudreau @dellacqu
You can check it by downloading, for example, the `.bz` file from our latest release:
![image](/uploads/0d587144377d75f7a506b569ca848d15/image.png)
If you extract it, you will see that the content of ATLASExtensions is 0 bytes:
![image](/uploads/1a5c00b4cfc756e9688a2c2ba9f811cf/image.png)
Basically, the ATLASExtensions Git submodule is not included when the release source bundle is created.
It is the same if we try to download the sources from the Tags page:
![image](/uploads/a8ee31083792e099abbee10281ec48ec/image.png)Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/99CI: mac jobs time out2023-12-19T16:47:09+01:00Vakhtang TsulaiaCI: mac jobs time outHi @rbianchi, I've noticed that on recent MR-s the mac pipelines were either marked as failed or were waiting their turn to start (which never happened). I canceled all such pending pipelines manually and then restarted [one of them](htt...Hi @rbianchi, I've noticed that on recent MR-s the mac pipelines were either marked as failed or were waiting their turn to start (which never happened). I canceled all such pending pipelines manually and then restarted [one of them](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/jobs/34743267). It stopped adding new lines to the log after printing:
```
Using wget
Upgrading qt5
```
and eventually timed out:
```
ERROR: Job failed: execution took longer than 30m0s seconds
```
Any ideas about what's going on with our mac jobs? Thanks.Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/98Enabling CTest-based testing and add tests2023-12-11T13:53:31+01:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chEnabling CTest-based testing and add testsWe now support CTest-based testing within our CMake project.
This MR introduces it and adds a first test:
https://gitlab.cern.ch/GeoModelDev/GeoModel/-/merge_requests/233
I should now write some documentation and add more tests.We now support CTest-based testing within our CMake project.
This MR introduces it and adds a first test:
https://gitlab.cern.ch/GeoModelDev/GeoModel/-/merge_requests/233
I should now write some documentation and add more tests.Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/97AlignableTrasnform should store the 'default position'2023-11-15T10:51:32+01:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chAlignableTrasnform should store the 'default position'While debugging the ATLAS Muon geometry, @boudreau noticed that the AlignableTransforms were dumped with the alignment constants applied.
At the moment, both `Transform` and `AlignableTransform` objects are stored by taking their transf...While debugging the ATLAS Muon geometry, @boudreau noticed that the AlignableTransforms were dumped with the alignment constants applied.
At the moment, both `Transform` and `AlignableTransform` objects are stored by taking their transformation with the use of the `GeoTransform::getTransform()` method: https://gitlab.cern.ch/GeoModelDev/GeoModel/-/blob/main/GeoModelCore/GeoModelKernel/src/GeoTransform.cxx?ref_type=heads#L17-25
That method, however, [is overwritten in the AlignableTransform class](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/blob/main/GeoModelCore/GeoModelKernel/src/GeoAlignableTransform.cxx?ref_type=heads#L38) to return the transformation plus the alignment 'delta'; while `getDefTransform()` returns the *default position* (no alignments). Both methods, instead, return the same transformation for Transform nodes.
Therefore, I updated the GeoModelWrite package to dump both transforms with the use of the `getDefTransform()` method.Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/96the saveDB helper function should have a forceDelete option2023-11-20T19:47:17+01:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chthe saveDB helper function should have a forceDelete optionWhen using the saveDB helper function we should provide an option for the user to delete an existing file with the same name, to replace it. Useful for tests and development.
By default, however, an error message should be returned.
Th...When using the saveDB helper function we should provide an option for the user to delete an existing file with the same name, to replace it. Useful for tests and development.
By default, however, an error message should be returned.
This was suggested by Sharka in https://gitlab.cern.ch/GeoModelDev/GeoModel/-/merge_requests/217#note_7238241
It relates to https://gitlab.cern.ch/GeoModelDev/GeoModel/-/merge_requests/217Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/95CI: macOS job for Coin failed due to Boost2023-11-13T18:20:40+01:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chCI: macOS job for Coin failed due to BoostThe CI job building Coin failed on macOS because it did not find Boost.
It was caused by a corrupted installation of Boost by `brew`: the directory lacked the CMake configuration file for the Boost target.
A full reinstallation of Boos...The CI job building Coin failed on macOS because it did not find Boost.
It was caused by a corrupted installation of Boost by `brew`: the directory lacked the CMake configuration file for the Boost target.
A full reinstallation of Boost with `brew reinstall boost` fixed the problem.
Cc: @tsulaiaRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/94GeoModel brew binaries failing with `Library not loaded` after local install ...2023-10-10T16:09:44+02:00Joshua Falco Beirerjoshua.beirer@cern.chGeoModel brew binaries failing with `Library not loaded` after local install from sourceHi @rbianchi,
I was using GeoModel from the brew install without issues. Now, since I am also building GeoModel from source (only installing it to a local directory with `-DCMAKE_INSTALL_PREFIX=../install`), I am suddenly encountering ...Hi @rbianchi,
I was using GeoModel from the brew install without issues. Now, since I am also building GeoModel from source (only installing it to a local directory with `-DCMAKE_INSTALL_PREFIX=../install`), I am suddenly encountering the following issue when trying to use any executable from the brew version of GeoModel:
```➜ gm2gdml
dyld[50379]: Library not loaded: @rpath/libGeoMaterial2G4.4.dylib
Referenced from: <E1BBF915-0A37-3FE5-83B3-E0B0BFE46A97> /usr/local/Cellar/geomodel-geomodelg4/4.6.0/lib/libGeoModel2G4.4.6.0.dylib
Reason: no LC_RPATH's foundLibrary not loaded: @rpath/libGeoModelDBManager.4.dylib
Referenced from: <E62E70A1-F878-3759-9E4B-06D06B0FBE73> /usr/local/Cellar/geomodel/4.6.0/lib/libGeoModelRead.4.6.0.dylib
Reason: no LC_RPATH's foundLibrary not loaded: @rpath/libGeoModelDBManager.4.dylib
Referenced from: <3155BD0C-B48E-3891-A3ED-3B303B013FD9> /usr/local/Cellar/geomodel/4.6.0/lib/libGeoModelWrite.4.6.0.dylib
Reason: no LC_RPATH's foundLibrary not loaded: @rpath/libGeoModelKernel.4.dylib
Referenced from: <14886B90-6CB2-365F-9610-285776B936CD> /usr/local/Cellar/geomodel/4.6.0/lib/libTFPersistification.4.6.0.dylib
Reason: no LC_RPATH's foundLibrary not loaded: @rpath/libGeoGenericFunctions.4.dylib
Referenced from: <1BA5C8FC-1EE2-39DB-B623-FFE6FA62494A> /usr/local/Cellar/geomodel/4.6.0/lib/libGeoModelKernel.4.6.0.dylib
Reason: no LC_RPATH's found
[1] 50379 abort gm2gdml
```
and
```➜ gmex
dyld[50443]: Library not loaded: @rpath/libGXGui.4.dylib
Referenced from: <FA464C35-BD8F-3545-ADB9-8FFD18538CBC> /usr/local/Cellar/geomodel-visualization/4.6.0/bin/gmex
Reason: no LC_RPATH's found
[1] 50443 abort gmex
```
I have tried removing GeoModel and all its dependencies and re-installing several times, but so far nothing has helped.
Are there any dependencies I am potentially missing that could cause this or does the local installation modify something permanently that GeoModel depends on?
Cheers,
Joshua
Device: MacBook Pro
OS Version: 14.0 (23A344)
CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHzhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/93CI fails while pushing to the docker registry2023-10-16T18:42:40+02:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chCI fails while pushing to the docker registryJob [#32704596](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/jobs/32704596) failed for 57e44ad4d60655caebd629546207673f93baf417:
```sh
time="2023-09-25T13:56:48Z" level=info msg="Pushing the built image to 'gitlab-registry.cern.ch/geom...Job [#32704596](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/jobs/32704596) failed for 57e44ad4d60655caebd629546207673f93baf417:
```sh
time="2023-09-25T13:56:48Z" level=info msg="Pushing the built image to 'gitlab-registry.cern.ch/geomodeldev/geomodel:main-base'"
[93](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/jobs/32704596#L93)time="2023-09-25T13:56:48Z" level=fatal msg="API error (400): Bad parameters and missing X-Registry-Auth: EOF"
```Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/92CI Docs build fails because of a Python package missing2023-09-25T16:11:32+02:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chCI Docs build fails because of a Python package missingJob [#32701299](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/jobs/32701299) failed for bc3e80537f0e1b7a682bdba56f5f1d61b0559f06:
```python
from packaging.version import Version ModuleNotFoundError: No module named 'packaging'
```Job [#32701299](https://gitlab.cern.ch/GeoModelDev/GeoModel/-/jobs/32701299) failed for bc3e80537f0e1b7a682bdba56f5f1d61b0559f06:
```python
from packaging.version import Version ModuleNotFoundError: No module named 'packaging'
```Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/91FSL: HDF5 include directory pruned from include path by CMake2023-09-15T19:00:36+02:00Charles LeggettFSL: HDF5 include directory pruned from include path by CMake
I'm building the tip of main branch on a centos7 platform, using cmake 3.27.4 and HDF5 1.14.2.
CMake is pruning the HDF5 directory from the include paths. Some googling suggests it does this because it considers the HDF5 includes to be...
I'm building the tip of main branch on a centos7 platform, using cmake 3.27.4 and HDF5 1.14.2.
CMake is pruning the HDF5 directory from the include paths. Some googling suggests it does this because it considers the HDF5 includes to be "dangerous". The only way to get FSL to compile is to create an innocuous sounding directory, copy the HDF5 includes there, and then hack the CMakeLists.txt files that have a target_include_directories for HDF5 to explicitly pull in this new directory.
For example, I have the HDF5 includes in `/opt/hdf5/1.14.2/include` and the `CMAKE_PREFIX_PATH` include `/opt/hdf5/1.14.2`. This directory never shows up in the compilation line, resulting in errors. Even if I explicitly do
```
include_directories( /opt/hdf5/1.14.2/include )
```
in say FullSimLight/Plugins/TracksPlugin/CMakeLists.txt it doesn't show up. Trying to trick CMake with `/opt/hdf5/1.14.2/include/../include` or `${HDF5_CXX_INCLUDE_DIRS}/../include` also doesn't work. If I do `/opt/hdf5/1.14.2/includeX`, it shows up in the compilation line, so it's obviously parsing that line. It really looks like it's actively removing the `${HDF5_CXX_INCLUDE_DIRS}` from the compilation line.https://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/90Homebrew install of geomodel-extensions-atlas failing on Intel Chips2023-09-14T15:30:01+02:00Joshua Falco Beirerjoshua.beirer@cern.chHomebrew install of geomodel-extensions-atlas failing on Intel ChipsHi,
the current installation of `geomodel-extensions-atlas` via Homebrew fails with
```
➜ brew install geomodel-extensions-atlas
==> Fetching atlas/geomodel/geomodel-extensions-atlas
==> Downloading https://geomodel.web.cern.ch/atlas-m...Hi,
the current installation of `geomodel-extensions-atlas` via Homebrew fails with
```
➜ brew install geomodel-extensions-atlas
==> Fetching atlas/geomodel/geomodel-extensions-atlas
==> Downloading https://geomodel.web.cern.ch/atlas-magnetic-field/bmagatlas_09_fullAsym20400.data
Already downloaded: /Users/jbeirer/Library/Caches/Homebrew/downloads/5480843d8f8b698e7a69612d84098fc074ce2d4da2e72c5b9adaee502e519205--bmagatlas_09_fullAsym20400.data
==> Cloning https://gitlab.cern.ch/atlas/geomodelatlas/ATLASExtensions.git
Updating /Users/jbeirer/Library/Caches/Homebrew/geomodel-extensions-atlas--git
==> Checking out revision 601d56beb058c80f61a85f8ccb2c6af7d23637d9
fatal: reference is not a tree: 601d56beb058c80f61a85f8ccb2c6af7d23637d9
Error: geomodel-extensions-atlas: Failed to download resource "geomodel-extensions-atlas"
Failure while executing; `/usr/bin/env git checkout -f 601d56beb058c80f61a85f8ccb2c6af7d23637d9 --` exited with 128. Here's the output:
fatal: reference is not a tree: 601d56beb058c80f61a85f8ccb2c6af7d23637d9
```
Looks like the homebrew path is pointing to a non-existing commit.
Cheers,
Joshua
Platform / OS: MacOS Ventura 13.5.2Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/89CI: How to get the pipeline's details through the GitLab API2023-09-12T14:32:38+02:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chCI: How to get the pipeline's details through the GitLab APIHere's some notes on how to get pipelines' details through the GitLab API.
It is done in the context of solving #88.Here's some notes on how to get pipelines' details through the GitLab API.
It is done in the context of solving #88.https://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/88Repository "Storage" is huge due to CI "Job Artifacts"2023-11-13T18:07:51+01:00Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRepository "Storage" is huge due to CI "Job Artifacts"The GeoModel repository "Storage" is huge:
![image](/uploads/7c9e063450a075399fe55f8f4772c81d/image.png)
And, apparently, it is due to the CI "Job Artifacts":
![image](/uploads/5f3c7f420feb82086257114f0362188c/image.png)The GeoModel repository "Storage" is huge:
![image](/uploads/7c9e063450a075399fe55f8f4772c81d/image.png)
And, apparently, it is due to the CI "Job Artifacts":
![image](/uploads/5f3c7f420feb82086257114f0362188c/image.png)Riccardo Maria Bianchiriccardo.maria.bianchi@cern.chRiccardo Maria Bianchiriccardo.maria.bianchi@cern.chhttps://gitlab.cern.ch/GeoModelDev/GeoModel/-/issues/87GeoModel 4.5.0 changes ATLAS full simulation output2023-12-11T21:01:30+01:00Vakhtang TsulaiaGeoModel 4.5.0 changes ATLAS full simulation outputThis is a follow-up to the discussion we had in the ATLAS DD technical [weekly meeting](https://indico.cern.ch/event/1315275) on August 28. It turns out that GeoModel 4.5.0 changed the output of ATLAS full simulation for Run2 and Run3 co...This is a follow-up to the discussion we had in the ATLAS DD technical [weekly meeting](https://indico.cern.ch/event/1315275) on August 28. It turns out that GeoModel 4.5.0 changed the output of ATLAS full simulation for Run2 and Run3 configurations. This was discovered when we attempted to switch Athena to GeoModel 4.5.0 in this [MR](https://gitlab.cern.ch/atlas/athena/-/merge_requests/65126). `AthSimulation` tests failed because of the GeoModel version update. Here is the list of the failed tests:
- `CITest_SimulationRun2FullSimChecks_ctest`
- `CITest_SimulationRun3FullSimChecks_ctest`
- `CITest_SimulationRun2FullSimLegacy_ctest`
- `CITest_SimulationRun3FullSimLegacy_ctest`
- `CITest_SimulationRun3HitsMergeWithSort_ctest`
I tracked down the source of these differences to !195 which changed the way volumes get calculated for several GeoModel shapes.
@evc, could you please comment on whether the changes in simulation output were expected? If you think this can be useful for you, then you can find reference outputs as well as the outputs produced with !195 at the locations listed below:
1. `SimulationRun2FullSimChecks`
Reference: `/cvmfs/atlas-nightlies.cern.ch/repo/data/data-art/WorkflowReferences/main/s4005/v1/myHITS.pool.root`
Changed: `/afs/cern.ch/user/t/tsulaia/workspace/public/GeoModel-4.5.0/s4005/myHITS.pool.root`
2. `SimulationRun3FullSimChecks`
Reference: `/cvmfs/atlas-nightlies.cern.ch/repo/data/data-art/WorkflowReferences/main/s4006/v1/myHITS.pool.root`
Changed: `/afs/cern.ch/user/t/tsulaia/workspace/public/GeoModel-4.5.0/s4006/myHITS.pool.root`
3. `SimulationRun3HitsMergeWithSort`
Reference: `/cvmfs/atlas-nightlies.cern.ch/repo/data/data-art/WorkflowReferences/main/s4007/v1/myHITS.pool.root`
Changed: `/afs/cern.ch/user/t/tsulaia/workspace/public/GeoModel-4.5.0/s4007/myHITS.pool.root`
Thanks.