Move code from Celeritas into G4VG

[sethrj]

This improves the usability of g4vg at the cost of removing functionality and duplicating some code from celeritas. Happy to have some help from @agheata and @SeverinDiederichs .

[JuanGonzalezCaminero]

Hi, because FindCUDA is deprecated (Used by VecCore) the highest CMake version that we can currently use is 3.26

[agheata]

@sethrj This currently cuts the dependency but does not replace the CELER_XXX macros, so the compilation fails. Are you proposing we take it from here and do the rest of the changes, using a library-local copy of these macros? Just to make sure we don't start doing the same thing on the two sides of the pond. What about the testing macros, should we protect them using some #ifdef guard? We should keep @drbenmorgan in the loop since he also has some branch doing similar stuff in his fork.

[drbenmorgan]

Just for reference, my hacked "standalone" version is on this branch: https://github.com/drbenmorgan/g4vg/commits/standalone/

There are some differences in approach - I went for providing internal workarounds/translations of some of the Celeritas functionality, see https://github.com/drbenmorgan/g4vg/blob/e4b2870b833ac3a9f3d1cb39f579fc6796c5aca4/src/detail/TranslationTypes.hh

I'll have a look at the changes here in more detail.

[drbenmorgan]

Having had a quick look, I suspect that all the remaining build failures are down to the CELER_... macros and other types. As noted above, my branch dealt with this by providing an internal translation:

https://github.com/drbenmorgan/g4vg/blob/e4b2870b833ac3a9f3d1cb39f579fc6796c5aca4/src/detail/TranslationTypes.hh

which I guess is similar to the header in this PR:

https://github.com/celeritas-project/g4vg/pull/12/files#diff-7b2edb38c8fd49855a9f9835ea4cbeb490e3d01d0d5bb1e14a41a02105e85447

That could therefore be expanded to cover the remaining macros/types, or do you have a different plan/ideas here @sethrj?

[sethrj]

I think that's about right, glad I didn't do any more since I had forgotten about your patch. I paused because I wasn't sure if we wanted to delete, copy, and/or refactor the various features... looks like you got most of it though! A few things:

• I don't like that we unconditionally remove the assertions since those can check for changes in geant4 behavior etc.
• We can probably get rid of the type-safe OpaqueId entirely since it's not used for anything other than volume IDs
• I'd rather copy-paste (and add namespaces to) the softeq/demangle
• We could find/replace the few uses of for ( _ : range(..)) with for ( ; ; )
• At the end, let's replace all CELER_ with G4VG_

[drbenmorgan]

Sounds good @sethrj - agreed that the assertions are good to have!

[agheata]

@sethrj why do we need RDC in this PR since the library does not link with any cuda code?

[sethrj]

That's a question for @pcanal : I think it's necessary to correctly link downstream libraries against vecgeom cuda? If he confirms it's not necessary, I can remove it.

[pcanal]

TLDR: please use the CudaRdcUtils.cmake scaffolding.

For better or worse, keeping the CudaRdc fragment is likely the easiest solution.

It might not be needed but using it might be easier/clearer.

Without it, there will be only one libg4vg library that would need to make sure to link against the 'middle' library of VecGeom (without this VecGeom MR it is libvecgeomcuda_static.a) and then use it directly in executable one would need to add (to each executable) a direct link to the final library (libvecgeomcuda.so).

Technically we could also 'chance' it and link libg4vg to the final library and hope and pray that the nvlink output in there is ignored. However this seems to have been working for shared build but have been shown (see Atlas) to fail in static build in the most annoying, unpredictable, hard to trace, expensive to debug and just plain (expletive deleted to protect the guilty and innocent alike) ways you could imagine.

Side note: the file should be updated to follow the latest update in the Celeritas repository see celeritas-project/celeritas#1487 and celeritas-project/celeritas#1489 or https://github.com/pcanal/CudaRDCExercise

[agheata]

Without it, there will be only one libg4vg library that would need to make sure to link against the 'middle' library of VecGeom (without this VecGeom MR it is libvecgeomcuda_static.a) and then use it directly in executable one would need to add (to each executable) a direct link to the final library (libvecgeomcuda.so).

This sounds like a total overkill, given that g4vg itself does/should NOT require any linking against anything in the vecgeom::cuda namespace. g4vg should only link against libvecgeom.a ! So this library is not affected by nvlink at all, it is a pure host library !

[pcanal]

This sounds like a total overkill, given that g4vg itself does/should NOT require any linking against anything in the vecgeom::cuda namespace. g4vg should only link against libvecgeom.a ! So this library is not affected by nvlink at all, it is a pure host library !

Indeed, if this does not need to link against any libvecgeomcuda, it does not need any Rdc support.

[sethrj]

My understanding is that, if nothing else, the main "vecgeom" library (when cuda is enabled) has missing symbols that can only be filled by libvecgeomcuda. Is that the only limitation?

[agheata]

My understanding is that, if nothing else, the main "vecgeom" library (when cuda is enabled) has missing symbols that can only be filled by libvecgeomcuda. Is that the only limitation?

AFAIK this should not be the case, if it is, we are in trouble and we should fix it with the highest priority ! It is only libvecgeomcuda that should depend on libvecgeom and not the other way around

[agheata]

@sethrj can you try in this PR to link only against libvecgeom? Is there a unit test that you can run in standalone mode (w/o/ Celeritas) ? Because now all the dependencies are a bit a mess, the test mode depends on Celeritas which depends itself on VecGeom cuda library...

[sethrj]

Will do. Yes there's a standalone "smoke test" that I should be able to try... but I can't get to it today unfortunately.

[drbenmorgan]

@sethrj, trying this out locally before this afternoon I found a couple of compile errors from the use of VecGeom Logger. These were simple to fix, so changes are here in two commits:

https://github.com/drbenmorgan/g4vg/tree/remove-celeritas-logger

Important one is the second, which restricts use to VecGeom 1.2.8 or newer, as that's the version where Logger.h became available.

[sethrj]

Thanks @drbenmorgan . I'll pull those in (or you can push to my fork) and will try to get the CI online before our meeting today.

[sethrj]

Vecgeom "kind of" has a scale flag, but it's only used by VGDML. I think we should either move that flag into the vgdml loader or use it here.

P.S. @agheata @SeverinDiederichs the scale should probably be used in the "absolute" (non-relative) bump distances inside vecgeom, since otherwise loading and running the same problem at different length scales gives you different results.

[drbenmorgan]

All good to go, so LGTM!