Search Criteria
Package Details: geant4 11.2.2-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/geant4.git (read-only, click to copy) |
---|---|
Package Base: | geant4 |
Description: | A simulation toolkit for particle physics interactions. |
Upstream URL: | http://geant4.cern.ch/ |
Keywords: | matter montecarlo radiation transport |
Licenses: | custom: http://geant4.cern.ch/license/ |
Conflicts: | geant4_devel |
Submitter: | Eothred |
Maintainer: | donpicoro |
Last Packager: | donpicoro |
Votes: | 19 |
Popularity: | 0.000178 |
First Submitted: | 2010-04-08 08:54 (UTC) |
Last Updated: | 2024-06-25 16:12 (UTC) |
Dependencies (25)
- boost (boost-gitAUR)
- clhepAUR
- cmake (cmake-gitAUR)
- glu (glu-gitAUR)
- openmotif
- python (python37AUR, python311AUR, python310AUR)
- qt6-base (qt6-base-headlessAUR, qt6-base-gitAUR)
- soqt (soqt-gitAUR)
- xerces-c
- zlib (zlib-ng-compat-gitAUR, zlib-gitAUR, zlib-ng-compat)
- geant4-abladataAUR (optional) – Data files for nuclear shell effects in INCL/ABLA hadronic mode
- geant4-ensdfstatedataAUR (optional) – Nuclei properties from the Evaluated Nuclear Structure Data Files
- geant4-incldataAUR (optional) – Data files for proton and neutron density profiles
- geant4-ledataAUR (optional) – Data files for low energy electromagnetic processes
- geant4-levelgammadataAUR (optional) – Data files for photon evaporation
- geant4-neutronhpdataAUR (optional) – Experimental neutron data files with thermal cross sections
- geant4-particlehpdataAUR (optional) – Data files from the TALYS nuclear model code
- geant4-particlexsdataAUR (optional) – Data files for evaluated p, d, t, He3, He4 and gamma cross sections, replaces geant4-neutronxsdata
- geant4-piidataAUR (optional) – Data files for shell ionisation cross sections
- geant4-radioactivedataAUR (optional) – Data files for radioactive decay hadronic processes
- Show 5 more dependencies...
Required by (24)
- bxdecay0-geant4
- bxdecay0-geant4-git
- dd4hep
- g4python-git
- g4see-git
- geant4-abladata (optional)
- geant4-channelingdata (optional)
- geant4-ensdfstatedata (optional)
- geant4-incldata
- geant4-ledata (optional)
- geant4-lend (optional)
- geant4-levelgammadata (optional)
- geant4-neutronhpdata (optional)
- geant4-neutronxsdata
- geant4-nudexlibdata (optional)
- geant4-particlehpdata (optional)
- geant4-particlexsdata (optional)
- geant4-piidata (optional)
- geant4-radioactivedata (optional)
- geant4-realsurfacedata (optional)
- geant4-saiddata (optional)
- geant4-urrptdata (optional)
- opengate
- opengate-git
Latest Comments
1 2 3 4 5 6 .. 15 Next › Last »
Ifnister commented on 2024-03-12 09:13 (UTC)
Hi @donpicoro,
sounds good, many thanks! I'll try the new version once it's out.
Cheers
donpicoro commented on 2024-03-11 10:54 (UTC)
Hello @ifnister,
as I said before, I myself have no strong argument to keep it as is. You provide a good argument to use the external CLHEP and since no one has weighted in in either direction I will change it.
I will do it in connection with the next patch release as I do not want to trigger an unnecessary compilation for everyone.
/Pico
Ifnister commented on 2024-03-09 09:39 (UTC)
Hi @donpicoro,
coming back to the CLHEP issue that I mentioned before, and after some thought and having worked with this Geant4 package I now think that depending on an external CLHEP should be the default because: - By default Geant4 brings its own version of CLHEP so not much is saved by not depending on CLHEP other than whatever stripping is done by Geant4 on their own version of CLHEP - When building something on top of Geant4 and linking to it, the flag -lG4clhep will be added together with a path to the CLHEP library provided by Geant4. If you have something that happens to depend on CLHEP and Geant4 at the same time, well then there will be issues since the CLHEP libraries are not the same. One possible workaround would be to make sure only the CLHEP installation from G4 is used, but we have a better way of having a standard installation that every package can use - use the clhep package instead of the library provided by Geant4
This is how, for example, the LCG stacks (the stacks of software used by some LHC experiments) install Geant4 since you don't want to have two different installations of CLHEP around.
Cheers
donpicoro commented on 2024-01-22 16:51 (UTC)
So,
I had to patch the G4InterfaceOptions.cmake to accept 1.6.1 and I realized that SoQt bring a dependency to Qt6, so now it build on qt6. I tested on my system and the application worked. I no longer could use
/vis/open OGLSQt
but if I swapped it for/vis/open OGL
or/vis/open DAWNFILE
it does work.I hope this works for people.
/Pico
donpicoro commented on 2024-01-22 14:41 (UTC) (edited on 2024-01-22 15:15 (UTC) by donpicoro)
OK, I'm looking into it... this didn't happened when I updated the package. This is more recent. The bright side is that I can reproduce the error ;-)
It is Geant4 that demands SoQt 1.6.0... I'll see if I can find a workaround.
Eothred commented on 2024-01-16 12:26 (UTC) (edited on 2024-01-16 12:30 (UTC) by Eothred)
I'm getting some error with SoQt version when trying to build version 11.2.0-1. Seems very specific to demand exactly version 1.6.0?
Edit: for now just disabled the inventor_qt option to avoid the dependency on soqt.
donpicoro commented on 2023-09-18 09:38 (UTC)
Hello @ifnister
There is no real strong argument for one or the other. I maintain both packages because I use to build Geant4 as a full dependency, so it was convenient.
The only reason to drop it as an explicit dependency is that Geant4 does not really include CLHEP. From the documentation (https://geant4-userdoc.web.cern.ch/UsersGuides/InstallationGuide/html/gettingstarted.html?highlight=clhep#prerequisites-for-optional-components-of-geant4) it is explicitly mentioned that it is a minimal version of clhep.
If I were to have the "full" CLHEP as a dependency, I may get a user saying that this way would be better.
In reality both are fine and I do not mind either way... but you know... a decision has to be made and people has opinions on decisions. If more users come forward with the same request I do not mind change it at all.
For the time being, while people express opinions, if any, an since this is such a small adjustment in the PKGBUILD, I suppose you can do it yourself?
This package is updated about 3 times a year. - new release in first week of december - couple of patches version during the year
Cheers,
/Pico
Ifnister commented on 2023-09-15 12:14 (UTC)
Would it be interesting to build it with CLHEP? Most of the time it has to be installed for other packages (in which case it is worse to have also the CLHEP from AUR as you have two installations in your system) and it would only add one dependency; and the maintainer is the same person. For me it would be nice to have it
Eothred commented on 2022-11-07 15:32 (UTC)
That's not to be defined in the PKGBUILD, so the maintainer is correct in doing it this way. makepkg can be configured for parallel builds, see https://wiki.archlinux.org/title/makepkg#Improving_compile_times
Firestar commented on 2022-11-07 15:20 (UTC)
I found that you enabled
GEANT4_BUILD_MULTITHREADED=ON
butmake
do not have the-j
parameter. Can you enable it as the compilation is very slow?1 2 3 4 5 6 .. 15 Next › Last »