katrin-experiment / kassiopeia Goto Github PK

When attempting to set up Kassiopeia with VTK an issue arises where it attempts to include the file "ON" whenever kasper_find_vtk is called as shown in the first image. The second image shows the kasper_find_vtk macro setting VTK_USE_FILE to ON and then including it.

I'm trying to simulate an electron gun with a simple setup that includes two electrodes with one with a hole. The electrons generated from the cathode are accelerated to the anode with a hole. Two termination events are defined ksterm_max_z and ksterm_death, this one seems to produce this error each time the electrons collide with the anode surface

16:55:04 [ERROR] l/Utility/KGslErrorHandler.cxx:84    GSL error: ellint.c:542: domain error (1)
  1# gsl_sf_ellint_Ecomp_e
  2# gsl_sf_ellint_Ecomp
  3# KEMField::KElectrostaticAnalyticRingIntegrator::EFieldRFromChargedRing(double const*, double const*)
  4# KEMField::KGaussianQuadrature::operator()(double (**)(double const*, double const*), int, double, double, double*, int, double*) const
  5# KEMField::KElectrostaticAnalyticConicSectionIntegrator::ElectricField(KEMField::KConicSection const*, KEMField::KThreeVector_<true> const&) const
****************[KSSTEP WARNING MESSAGE] Failed to execute step <1501> (GSL error: ellint.c:542: domain error (1))

while electrons passing through the hole activate the ksterm_max_z termination. In fact, if I open the root file I find b'gsl_error' and b'term_max_z'. Instead, if I use the anode without a hole like the cathode, I don't get this error, but b'term_death_surface'.

I started to suppose that could be a problem related to the attribute radial_mesh_count of the cylinder_tube_space but it doesn't change and I've already defined the axial_mesh and electrostatic_dirichlet.

The kemfield I'm using is the same as the DipoleTrapSimulation.xml example.

To obtain the correct value for x_loc[2], the length of the edge along n2 of the triangle needs to be used instead of the height b.

GoogleTest fails to compile on recent clang versions (see #85 ). GoogleTest currently considers to add a new dependency to the central Google base library "abseil" ( google/googletest#2883 ). Since our fork of GoogleTest is many years out of date and integrating a new version would be a significant effort anyways, it seems reasonable to move to the dependency-less single-header testing library doctest:
https://github.com/doctest/doctest

Regarding the selection of the physical constants epoch, we do not presently have a known way of doing the flag selection from P8 through the #ifndef..#endif logic in prebuilt images (the combined build crashes, even with cmake flags specified). As a temporary workaround we have hard-wired the 2006 constants in our local fork of Kass. Would it be possible to somehow alter the #ifndef..#endif logic, or remove it and hard-wire the 2021 constants? We can then update to the 2021 constants on the P8 side, although possibly not quite instantaneously. Alternatively, we can explore the cmake flag usage further, which might also be useful. Maybe that should have worked in the first place.

Originally posted by @pslocum in #71 (comment)

It is currently not possible to calculate the magnetic field using the KMagnetostaticFieldmapBuilder giving a KMagneticSuperpositionField as the field. The reason behind this is that KMagnetostaticFieldmapBuilder assumes a KMagnetostaticField however KMagneticSuperpositionField is a KMagneticField and can have components that are not static.

There are several ways to make this combinable.

1. A KMagnetostaticSuperpositionField can be defined which is both a superposition and static.
2. The functionality of the KMagnetostaticFieldmapBuilder can be extended to work also for non-static fields by providing a time at which the field should be calculated.

There are multiple open FIXMEs in the code. One significant one is the new MagfieldCoils implementation: It still shows compiler warnings that may hint to relevant issues. This is hidden here: https://github.com/KATRIN-Experiment/Kassiopeia/blob/6d703553c96155730edf2d791e9e5aa60ebfdb7a/KEMField/Source/ExternalFields/MagfieldCoils/CMakeLists.txt#L42C1-L42C109

We should fix the underlying issues and remove that line.

Dear developers,
as we discussed, it would be nice if there could be a user guide about setting up the singularity with docker images (e.g. using Kassiopeia on bwUniCluster or other clusters) in the documentation.
Many thanks!

This occurred while building Kass inside of the Locust software, forked here. I was compiling from source on my mac (Mojave 10.14.6).

[  1%] Building CXX object Kommon/CMakeFiles/Kommon.dir/Gsl/Utility/KGslErrorHandler.cxx.o 
In file included from /Users/arinabtelles/locust_mc/kassiopeia/Kommon/Gsl/Utility/KGslErrorHandler.cxx:8:
In file included from /usr/local/include/boost/stacktrace.hpp:15:
In file included from /usr/local/include/boost/stacktrace/frame.hpp:20:
In file included from /usr/local/include/boost/stacktrace/safe_dump_to.hpp:217:
/usr/local/include/boost/stacktrace/detail/collect_unwind.ipp:33:2: error: "Boost.Stacktrace requires _Unwind_Backtrace function.
      Define _GNU_SOURCE macro or BOOST_STACKTRACE_GNU_SOURCE_NOT_REQUIRED if _Unwind_Backtrace is available without
      _GNU_SOURCE."
#error "Boost.Stacktrace requires _Unwind_Backtrace function. Define _GNU_SOURCE macro or BOOST_STACKTRACE_GNU_SOURCE_...
 ^
1 error generated.
make[5]: *** [Kommon/CMakeFiles/Kommon.dir/Gsl/Utility/KGslErrorHandler.cxx.o] Error 1
make[4]: *** [Kommon/CMakeFiles/Kommon.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [src/KassiopeiaExt-stamp/KassiopeiaExt-build] Error 2
make[1]: *** [CMakeFiles/KassiopeiaExt.dir/all] Error 2
make: *** [all] Error 2 

After doing some research, I was able to fix it by adding these lines right after line 102 of kassiopeia/Kommon/CMakeLists.txt:

if(UNIX OR APPLE OR MINGW)
    target_compile_definitions(Kommon PRIVATE _GNU_SOURCE)
endif()

I'm not entirely sure what the role of _GNU_SOURCE is in the build, but this seems to work. Is this a valid workaround? What is the cause of the build error? Thanks!

Compiling Kassiopeia with [email protected] and c++17 fails (possibly with -Werror -Wall) due to the deprecation of the std::iterator types in c++17. This is a fairly straighforward fix, and I can take a stab at it.

In file included from /home/wdconinc/git/Kassiopeia/KEMField/Source/Surfaces/include/KSortedSurfaceContainer.hh:4,
                 from /home/wdconinc/git/Kassiopeia/KEMField/Source/Surfaces/src/KSortedSurfaceContainer.cc:1:
/home/wdconinc/git/Kassiopeia/KEMField/Source/Surfaces/include/KSurfaceContainer.hh:55:34: error: ‘template<class _Category, class _Tp, class _Distance, class _Pointer, class _Reference> struct std::iterator’ is deprecated [-Werror=deprecated-declarations]
   55 |     class iterator : public std::iterator<std::bidirectional_iterator_tag, KSurfacePrimitive*>
      |                                  ^~~~~~~~
In file included from /usr/include/c++/12/string:45,
                 from /home/wdconinc/git/Kassiopeia/KEMField/Source/Core/include/KFundamentalTypes.hh:6,
                 from /home/wdconinc/git/Kassiopeia/KEMField/Source/Core/include/KDataComparator.hh:4,
                 from /home/wdconinc/git/Kassiopeia/KEMField/Source/Surfaces/include/KSurfaceID.hh:5,
                 from /home/wdconinc/git/Kassiopeia/KEMField/Source/Surfaces/include/KSurface.hh:4,
                 from /home/wdconinc/git/Kassiopeia/KEMField/Source/Surfaces/include/KSurfaceContainer.hh:4:
/usr/include/c++/12/bits/stl_iterator_base_types.h:127:34: note: declared here
  127 |     struct _GLIBCXX17_DEPRECATED iterator
      |                                  ^~~~~~~~
/home/wdconinc/git/Kassiopeia/KEMField/Source/Surfaces/include/KSurfaceContainer.hh:59:33: error: ‘template<class _Category, class _Tp, class _Distance, class _Pointer, class _Reference> struct std::iterator’ is deprecated [-Werror=deprecated-declarations]
   59 |         using value_type = std::iterator<std::bidirectional_iterator_tag, KSurfacePrimitive*>::value_type;
      |                                 ^~~~~~~~
/usr/include/c++/12/bits/stl_iterator_base_types.h:127:34: note: declared here
  127 |     struct _GLIBCXX17_DEPRECATED iterator
      |                                  ^~~~~~~~
/home/wdconinc/git/Kassiopeia/KEMField/Source/Surfaces/include/KSurfaceContainer.hh:60:32: error: ‘template<class _Category, class _Tp, class _Distance, class _Pointer, class _Reference> struct std::iterator’ is deprecated [-Werror=deprecated-declarations]
   60 |         using reference = std::iterator<std::bidirectional_iterator_tag, KSurfacePrimitive*>::reference;
      |                                ^~~~~~~~
/usr/include/c++/12/bits/stl_iterator_base_types.h:127:34: note: declared here
  127 |     struct _GLIBCXX17_DEPRECATED iterator
      |                                  ^~~~~~~~
/home/wdconinc/git/Kassiopeia/KEMField/Source/Surfaces/include/KSurfaceContainer.hh:61:30: error: ‘template<class _Category, class _Tp, class _Distance, class _Pointer, class _Reference> struct std::iterator’ is deprecated [-Werror=deprecated-declarations]
   61 |         using pointer = std::iterator<std::bidirectional_iterator_tag, KSurfacePrimitive*>::pointer;
      |                              ^~~~~~~~
/usr/include/c++/12/bits/stl_iterator_base_types.h:127:34: note: declared here
  127 |     struct _GLIBCXX17_DEPRECATED iterator
      |                                  ^~~~~~~~

Currently, using Clang, compilation can fail due to an issue in GoogleTest: https://github.com/2xB/Kassiopeia/actions/runs/6926925797/job/18839860351

Therefore, GoogleTest should be updated.

Here is the corresponding part of the log:

In file included from /__w/Kassiopeia/Kassiopeia/UnitTest/GoogleTest/src/gtest_main.cc:32:
/__w/Kassiopeia/Kassiopeia/UnitTest/GoogleTest/include/gtest/gtest.h:10720:8: error: definition of implicit copy constructor for 'ValueArray2<bool, bool>' is deprecated because it has a user-declared copy assignment operator [-Werror,-Wdeprecated-copy]
  void operator=(const ValueArray2& other) = delete;
       ^
/__w/Kassiopeia/Kassiopeia/UnitTest/GoogleTest/include/gtest/gtest.h:15920:10: note: in implicit copy constructor for 'testing::internal::ValueArray2<bool, bool>' first required here
  return internal::ValueArray2<T1, T2>(v1, v2);
         ^
/__w/Kassiopeia/Kassiopeia/UnitTest/GoogleTest/include/gtest/gtest.h:16787:10: note: in instantiation of function template specialization 'testing::Values<bool, bool>' requested here
  return Values(false, true);
         ^

Currently magnetostatic problems are either solved using zonal harmonics (if the geometry is cylinder symmetric) or has to be solved using numerical integration of the Biot-Savart law (for all non cylinder symmetric setups). For sufficient complex current / wire distributions the numerical integration of the Biot-Savart law is a major bottleneck at run time as for each particle step the magnetic field has to be reevaluated including the numerical integration over all wires.

For electrostatic fields the FastMultipole method was implemented that allows to precompute boundary charges on a surface and using a tree representation for fast evaluation at run time. The method is based on the fact that the volume of interest is charge free and thus the E field is divergent and curl free and thus can be described by a potential that has to fulfill the Laplace equation.

For magnetic fields we usually are also interested in the current free region (we are not tracking particles through wires) and thus the magnetic field is divergent and curl free and can also be described by a potential that has to fulfill the Laplace equation.

Thus we can make use of the same mathematical description as in the case of electromagnetic problems which are described by a set of surface charges sigma_i on an enclosing surface. For electrostatic fields the surface charges have to be derived from Direchlet and Neuman boundary conditions. The surface charges are given by sigma(r') = - eps_0 normal(surface) * grad(potential(r')) .
We can make use of -grad(potential(r')) = B(r') and thus can directly calculate sigma(r') = const * normal(surface) * B(r'). In this case we can calculate B(r') using the Biot-Savart law at initialization time to get the surface charges and the FastMultipole representation. This has a speed up because 1. we have to evaluate B(r') only at a surface and not for the full volume, 2. we only do it at initialization time once and not at every particle step and 3. we can save the representation for other executions.

Implementation: We need a new class for magnetostatic problems what calculates "pseudo" surface charges using the Biot-Savart integration (which is already implemented). Based on the "pseudo" surface charges we generate the tree representation of the FastMultipole method (already implemented) and at runtime we use the FastMultipole method (already implemented) also for magnetic fields. Thus implementation is basically the work of writing wrapper functions to already existing tools.

In KasperDefaults.cmake we find two places where installation directories are dealt with. The first block is at lines 49-57:

    set_path(INCLUDE_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/include" "Install directory for headers")
    set_path(LIB_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/lib" "Install directory for libraries")
    set_path(BIN_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/bin" "Install directory for binaries")
    set_path(CONFIG_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/config" "Install directory for config files")
    set_path(DATA_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/data" "Install directory for data files")
    set_path(SCRATCH_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/scratch" "Directory for temporary files")
    set_path(OUTPUT_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/output" "Directory for output files")
    set_path(CACHE_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/cache" "Directory for cache files")
    set_path(LOG_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/log" "Directory for log files")

The second block is at lines 175-183:

    set( ${PROJECT_NAME}_INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_INCLUDEDIR} )
    set( ${PROJECT_NAME}_LIB_INSTALL_DIR ${CMAKE_INSTALL_LIBDIR} )
    set( ${PROJECT_NAME}_BIN_INSTALL_DIR ${CMAKE_INSTALL_BINDIR} )
    set( ${PROJECT_NAME}_CONFIG_INSTALL_DIR ${CONFIG_INSTALL_DIR}/${PATH} )
    set( ${PROJECT_NAME}_DATA_INSTALL_DIR ${DATA_INSTALL_DIR}/${PATH} )
    set( ${PROJECT_NAME}_SCRATCH_INSTALL_DIR ${SCRATCH_INSTALL_DIR}/${PATH} )
    set( ${PROJECT_NAME}_OUTPUT_INSTALL_DIR ${OUTPUT_INSTALL_DIR}/${PATH} )
    set( ${PROJECT_NAME}_LOG_INSTALL_DIR ${LOG_INSTALL_DIR}/${PATH} )
    set( ${PROJECT_NAME}_CACHE_INSTALL_DIR ${CACHE_INSTALL_DIR}/${PATH} )

In the first block we create [type]_INSTALL_DIR for all nine types (includes, libs, etc).

In the second block, however, things are not consistent. Includes, libs, and bins are re-defined based on the CMAKE_INSTALL_[TYPE]DIR variables (which were defined using the GNUInstallDirs module back at line 11). The other six types are defined by adding the PATH variable (a macro argument) to the corresponding [type]_INSTALL_DIR variable.

As a consequence, the way that the installation directories are controlled is inconsistent and undocumented. And the variables INCLUDE_INSTALL_DIR, LIB_INSTALL_DIR, and BIN_INSTALL_DIR are unused (and made it more difficult to debug things before I figured out what's really going on).

It would be great if the system for controlling the directories were consistent, or at least well documented and free of unused variables.

Currently there exist multiple public places of user documentation:

• On the "gh-pages" branch
• On the "main" branch in the Kassiopeia/Documentation folder
• In the main README

As far as I can tell, the Doxygen-based documentation is worse than browsing the source at the moment, so we can also get rid of it and potentially do it again from scratch in the future. We should however keep the logos somewhere. So I suggest removing:

• Documentation/{Reference,CMakeLists.txt}
• {KEMField,KGeoBag,Kommon}/Documentation/{Reference,CMakeLists.txt}

I think we should move everything to the "main" branch in the "Documentation" folder since there people expect to find documentation and if people look for documentation for an old version of Kassiopeia, there they will look first.

Btw. there exists KEMField/Documentation/manual/manual.pdf which may make sense to link in the documentation as something like "KEMField Developer's Guide". Maybe it can also be compiled to Markdown using Pandoc to integrate it into the main documentation. But I think that's a challenge to solve after the above.

If this is agreed on, here are suggested tasks:

• Forward https://katrin-experiment.github.io to https://katrin-experiment.github.io/Kassiopeia for now
• (Potentially Remove Doxygen-based documentation)
• Combine gh-pages and main:Kassiopeia/Documentation/Reference: #79
• Bring resulting documentation to a reasonably named subdirectory of main:Documentation: #80
• Build GitHub Pages page via Action from main:Documentation: #80
• Remove gh-pages branch -- last commit: 501d247
• Reference or integrate main:KEMField/Documentation/manual/manual.pdf in the public documentation

Adding the line:

<component_member name="final_pid" field="pid" parent="component_track_final_particle"/>

to config/Kassiopeia/Examples/DipoleTrapSimulation.xml with VTK support produces the correct output ROOT file (with final_pid field), but the KSVTKTrackTerminatorPainter produces the following backtrace:

[KSREADER ERROR MESSAGE] could not analyze branch with label <final_pid> and type <long long>
[KSREADER ERROR MESSAGE] shutting down...
[KSREADER ERROR MESSAGE] stack trace:
[KSREADER ERROR MESSAGE]     katrin::KMessage::Stacktrace(std::ostream&) in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f3840278cf6]
[KSREADER ERROR MESSAGE]     katrin::KMessage::Shutdown() in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f384027a33b]
[KSREADER ERROR MESSAGE]     katrin::KMessage::Flush() in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f384027ba48]
[KSREADER ERROR MESSAGE]     Kassiopeia::KSReadObjectROOT::KSReadObjectROOT(TTree*, TTree*, TTree*) in /usr/local/Kassiopeia/3.7.2/lib/libKassiopeiaReaders.so [0x7f38421ac2a6]
[KSREADER ERROR MESSAGE]     Kassiopeia::KSReadIteratorROOT::KSReadIteratorROOT(TFile*, TTree*, TTree*) in /usr/local/Kassiopeia/3.7.2/lib/libKassiopeiaReaders.so [0x7f38421a904f]
[KSREADER ERROR MESSAGE]     Kassiopeia::KSReadTrackROOT::KSReadTrackROOT(TFile*) in /usr/local/Kassiopeia/3.7.2/lib/libKassiopeiaReaders.so [0x7f38421aa8e0]
[KSREADER ERROR MESSAGE]     Kassiopeia::KSReadFileROOT::OpenFile(katrin::KRootFile*) in /usr/local/Kassiopeia/3.7.2/lib/libKassiopeiaReaders.so [0x7f38421b665c]
[KSREADER ERROR MESSAGE]     Kassiopeia::KSVTKTrackTerminatorPainter::Render() in /usr/local/Kassiopeia/3.7.2/lib/libKassiopeiaVisualization.so [0x7f38491e5f0c]
[KSREADER ERROR MESSAGE]     katrin::KVTKWindow::Render() in /usr/local/Kassiopeia/3.7.2/lib/libKommonVtk.so [0x7f384198d93a]
[KSREADER ERROR MESSAGE]     katrin::KComplexElement<katrin::KVTKWindow>::End() in /usr/local/Kassiopeia/3.7.2/lib/libKommonVtk.so [0x7f3841992585]
[KSREADER ERROR MESSAGE]     katrin::KElementBase::ProcessToken(katrin::KTypedToken<katrin::KEndElement>*) in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f384025a656]
[KSREADER ERROR MESSAGE]     katrin::KPrintProcessor::ProcessToken(katrin::KTypedToken<katrin::KEndElement>*) in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f3840254f65]
[KSREADER ERROR MESSAGE]     katrin::KConditionProcessor::ProcessToken(katrin::KTypedToken<katrin::KEndElement>*) in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f3840251f35]
[KSREADER ERROR MESSAGE]     katrin::KLoopProcessor::ProcessToken(katrin::KTypedToken<katrin::KEndElement>*) in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f384024f33d]
[KSREADER ERROR MESSAGE]     katrin::KIncludeProcessor::ProcessToken(katrin::KTypedToken<katrin::KEndElement>*) in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f384024a5c5]
[KSREADER ERROR MESSAGE]     katrin::KXMLTokenizer::ParseElementEndName() in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f384023538a]
[KSREADER ERROR MESSAGE]     katrin::KXMLTokenizer::ProcessFile(katrin::KTextFile*) in /usr/local/Kassiopeia/3.7.2/lib/libKommon.so [0x7f384023795a]
[KSREADER ERROR MESSAGE]     0x000055E0246279C0 in Kassiopeia [0x55e0246279c0]
[KSREADER ERROR MESSAGE]     __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6 [0x7f383de740b3]
[KSREADER ERROR MESSAGE]     0x000055E024627DBE in Kassiopeia [0x55e024627dbe]

As suspected solution may lie in adding the following to KSReadObjectROOT (and some associated support):

        if (tType == string("long long")) {
            fData->SetBranchAddress(tLabel.c_str(), Add<KSLongLong>(tLabel).Pointer());
            continue;
        }

I'll try to put a PR together.

Currently we have a lot of documentation in https://github.com/KATRIN-Experiment/Kassiopeia/tree/main/Kassiopeia/XML/Complete . That is not easily findable through our web documentation at https://katrin-experiment.github.io/Kassiopeia/ , which should be fixed.

The shell scripts kasperenv.sh and create_kasper_user_directory.sh have as top line #!/bin/sh but assume that that points to bash. This is not the case on Ubuntu (regardless of the wisdom of that choice, it's a major distribution). Resulting bashisms are presents in the following script lines (some fail execution, some just result in confusing output).

In kasperenv.sh

export PATH=${KASPER_INSTALL_BIN}:${PATH//${OLD_PATH}/} could be export PATH=${KASPER_INSTALL_BIN}:$(echo $PATH | sed 's/${OLD_PATH}//g')

echo -e should be printf

function is redundant when followed by _kafit_krypton_auto()

COMPREPLY=( array is not POSIX compliant and may need to be split off into a separate script with [ ! -z "${BASH}" ] && . kasper-krypton.bash.

In create_kasper_user_directory.sh

source $T_KASPERSYS/bin/kasperenv.sh should be . $T_KASPERSYS/bin/kasperenv.sh

echo "#!/bin/sh" > $T_KASPERSYS/bin/kasperenv.sh prevents appending in case of multiple calls to create_kasper_user_directory.sh

All but the COMREPLY bash-completion targets are easy enough to fix. The bash-completion target needs guidance from devs.

I've identified what I think are two problems related to the use of the FindBoost.cmake module in Kassiopeia.

First problem

The first involves the particular FindBoost.cmake script that comes with Kassiopeia (Kommon/cmake/FindBoost.cmake). When I run CMake and that version of the script is used, the variables Boost_LIBRARIES, Boost_INCLUDE_DIRS, and Boost_LIBRARY_DIRS are empty (though Boost_FOUND is TRUE, so the configuration succeeds). When I print out those variables, here's what it looks like:

-- Kasper module enabled: Kassiopeia v3.6.0
-- Found Boost 1.70.0 at /usr/local/p8/common/v0.9.0/lib/cmake/Boost-1.70.0
--   Requested configuration: QUIET REQUIRED COMPONENTS filesystem
-- Found boost_headers 1.70.0 at /usr/local/p8/common/v0.9.0/lib/cmake/boost_headers-1.70.0
-- Found boost_filesystem 1.70.0 at /usr/local/p8/common/v0.9.0/lib/cmake/boost_filesystem-1.70.0
--   libboost_filesystem.a
-- Adding boost_filesystem dependencies: headers
-- %%%%%%% Boost_LIBRARIES: 
-- %%%%%%% Boost_FOUND: 1
-- %%%%%%% Boost_INCLUDE_DIRS: 
-- %%%%%%% Boost_LIBRARY_DIRS: 

When I force CMake to use the default FindBoost.cmake that comes with CMake, then those variables are filled as expected (almost; see below). I believe this means there's a problem with the FindBoost.cmake that comes with Kassiopeia.

It seems like this could be solved by either relying on the standard FindBoost.cmake, or updating/replacing the one that already comes with Kassiopeia.

Second problem

The second problem has to do with the results of running FindBoost.cmake, as it's used in the Kassiopeia module. FindBoost.cmake is used at least twice: once in the main CMakeLists.txt, and once in Applications/Other/CMakeLists.txt. The first time it is just looking for the filesystem component, and the second time it's looking for program_options. When CMake runs, the first time it runs Boost_LIBRARIES is Boost::filesystem. The second time it runs, Boost_LIBRARIES is still Boost::filesystem. It seems that that variable doesn't get changed the second time around. Here I print out several variables when CMake runs:

-- Kasper module enabled: Kassiopeia v3.6.0
-- Found Boost 1.70.0 at /usr/local/p8/common/v0.9.0/lib/cmake/Boost-1.70.0
--   Requested configuration: QUIET REQUIRED COMPONENTS filesystem
-- Found boost_headers 1.70.0 at /usr/local/p8/common/v0.9.0/lib/cmake/boost_headers-1.70.0
-- Found boost_filesystem 1.70.0 at /usr/local/p8/common/v0.9.0/lib/cmake/boost_filesystem-1.70.0
--   libboost_filesystem.a
-- Adding boost_filesystem dependencies: headers
-- %%%%%%% Boost_LIBRARIES: Boost::filesystem
-- %%%%%%% Boost_FOUND: TRUE
-- %%%%%%% Boost_INCLUDE_DIRS: /usr/local/p8/common/v0.9.0/include
-- %%%%%%% Boost_LIBRARY_DIRS: /usr/local/p8/common/v0.9.0/lib
-- %%%%%% doing boost find_package -- 1.44.0 -- REQUIRED -- program_options
-- Found Boost 1.70.0 at /usr/local/p8/common/v0.9.0/lib/cmake/Boost-1.70.0
--   Requested configuration: QUIET REQUIRED COMPONENTS program_options
-- Found boost_program_options 1.70.0 at /usr/local/p8/common/v0.9.0/lib/cmake/boost_program_options-1.70.0
--   libboost_program_options.a
-- Adding boost_program_options dependencies: headers
-- %%%%%% libs found: Boost::filesystem
-- %%%%%%% Boost_LIBRARIES: Boost::filesystem
-- %%%%%%% Boost_FOUND: TRUE
-- %%%%%%% Boost_INCLUDE_DIRS: /usr/local/p8/common/v0.9.0/include
-- %%%%%%% Boost_LIBRARY_DIRS: /usr/local/p8/common/v0.9.0/lib

As a result, TrackCompare.cc (from Applications/Other) does not build, since it requires Boost::program_options, and the libraries variable wasn't updated to include that.

It seems like this could be solved by making a single request to find_package( Boost ...) with everything that's needed for the Kassiopeia module.

System information

I'm building in this docker container: project8/p8compute_dependencies:v0.9.0, which is based on CentOS 7. Boost is installed in a custom location (prefix: /usr/local/lib/p8/common/).

Kassiopeia docker container

I just tested the build in the Kassiopeia dockerfile, and it disagrees with both of my above tests: it finds boost with the provided FindBoost.cmake, and it finds the appropriate library with the second call to find_package( Boost . . .). So I'm not sure what to make of that at this point.

The issue

When compiling Kassiopeia with OpenCL enabled, currently the resulting code is bound to the given OpenCL devices during compile time. This is the only reason we can't provide Docker images with OpenCL enabled and why one can't compile Kassiopeia with OpenCL on one system and run it on another system (a difficulty for some HPC systems).

The background

Currently, when compiling, first https://github.com/KATRIN-Experiment/Kassiopeia/blob/main/KEMField/Source/Plugins/OpenCL/Core/src/GenerateOpenCLHeader.cc is compiled by cmake, which generates a platform-dependent header file called kEMField_opencl_defines.h that itself is included in OpenCL (.cl) code. That by itself could all happen at runtime since OpenCL code is compiled at runtime. But then the same header file is also used indirectly by many C++ source files (through KOpenCLInterface.hh through KOpenCLHeaderWrapper.hh). That's the issue.

This dependency is used to know during compile time whether double precision is available on the OpenCL hardware and therefore the C++ interface can use double or float precision for buffers as well. This can be seen by grepping for CL_TYPE in C++ header and source files.

There is no need for this decision between float and double happening during compile time. It happening during compile time just means one can't change the OpenCL platform later. I therefore think it would be best to avoid all occurrences of CL_TYPE in C++ code and always cast to double or use dynamic types instead.

In KSRootBuilder.h the file KEMToolbox.h is included. However, that latter file is not used and isn't included in the CMake installation. It should be removed as an include in KSRootBuilder.h. This doesn't make much of a difference in the normal build, but I was building it in a somewhat unusual way and it became a problem.

In our application (beam transport for a tabletop electron accelerator) we are interested in simulating the magnetic field due to a square coil.
I think this should be possible with an extruded_poly_loop_surface and the integrating_field_solver. However, when I attempt to apply the magnetic field to the extruded_poly_loop_surface, I get a "WARNING:electromagnet field solver <electromagnet_field> has zero surface or space elements."
I substituted another surface (the cylinder_surface used in examples) for the extruded_poly_loop_surface, and I didn't get the same warning, so I'm assuming this is an issue with support for extruded_poly_loop_surface as an electromagnet. Is adding this feature a possibility? Or could you please direct me to another solution to the problem?

I had to make three changes to the CMake files, all related to Boost, to get Kassiopeia to build in the Project 8 Docker container. I will import the changes in a single PR shortly.

1. In Kommon/CMakeLists.txt I moved the add_subdirectory() call for Core to after the Boost inclusion.
2. I had to explicitly turn on BUILD_SHARED_LIBS so that the correct version of the Boost libraries would be used. If it was not explicitly on, then CMake would pick out the static libraries.
3. I adapted the finding of the Boost libraries to work with either the variable-based or target-based CMake installation of Boost.

Pulling and starting a bash shell in the katrinexperiment/kassiopeia docker image works without problems. Once in the shell the kasperenv.sh is executed automatically. If I than invoke Kassiopeia ./config/Kassiopeia/Examples/DipoleTrapSimulation.xml or simply just invoking Kassiopeia I get the error message Kassopeia: error while loading shared libraries: libCore.so.6.20: cannot open shared object file: No such file or directory. A check with ldd bin/Kassiopeia shows that there are a lot of shared libraries which can not be found. We found similar shared libraries here: /usr/lib64/root/libCore.so.6.18. It seems that all missing libraries are in the /usr/lib64/root folder and have the extension *.so.6.18 instead of *.so.6.20. I have the same problem with docker container :3.7.1 and :3.7.2.

When running Kassiopeia inside a thread called by the Locust software it works well on the first call, but crashes on the second call. There is a message from KGCore about some geometric shapes that already exist. This is happening after allowing the first Kassiopeia thread to "join" the main thread. The messages are below. I have tried to delete these objects explicitly but am not sure where is the best place to do it. Any suggestions would be appreciated. Thanks.

[KSMAIN NORMAL MESSAGE] ... finished
[KSMAIN NORMAL MESSAGE] starting ...
[KGCORE WARNING MESSAGE] multiple spaces registered for path <upstream_bathtub_coil_space>
[INITIALIZATION ERROR MESSAGE] element could not process attribute

In mapped fields (e.g. KMagnetostaticFieldmap) the values of the field and gradient can be calculated from the values of the field and gradient at the grid points, respectively. The gradient, in particular, seems needed for some adiabatic trajectory calculations. The gradient could also be calculated from the values of the field at the grid points (probably to less than the equivalent order, e.g. bilinear gradient for trilinear field, bicubic for tricubic field, or so), but this is not currently implemented.

Use case: We are interested in long-duration equilibrium simulations with adiabatic trajectories in a field configuration for which we only have a mapped description (due to the presence of a ferromagnetic yoke). We are also limited to using maps of the magnetic field, without any gradient information present. Two questions arise:

• Can we calculate the field gradients from the mapped field values?
• Will adiabaticity be maintained at all when using interpolated fields and gradients?
• If not, can the interpolated field gradient be used to 'improve' adiabaticity?

As you know, I'm happy to implement stuff, but in this case I'm not sure it's going to be a solution to the use case we're encountering. Thoughts?

I just pulled v3.7.2 and tried a build on my mac (Mojave, compiler info below) and ran into this error:

In file included from /Users/obla999/Software/Kassiopeia/Kassiopeia/Kommon/Core/Utility/KMessage.cxx:9:
In file included from /usr/local/include/boost/stacktrace.hpp:15:
In file included from /usr/local/include/boost/stacktrace/frame.hpp:20:
In file included from /usr/local/include/boost/stacktrace/safe_dump_to.hpp:217:
/usr/local/include/boost/stacktrace/detail/collect_unwind.ipp:33:2: error: "Boost.Stacktrace requires
      `_Unwind_Backtrace` function. Define `_GNU_SOURCE` macro or `BOOST_STACKTRACE_GNU_SOURCE_NOT_REQUIRED` if
      _Unwind_Backtrace is available without `_GNU_SOURCE`."
#error "Boost.Stacktrace requires `_Unwind_Backtrace` function. Define `_GNU_SOURCE` macro or `BOOST_STACKTR...
 ^
1 error generated.

Compiler info reported by CMake:

-- The C compiler identification is AppleClang 11.0.0.11000033
-- The CXX compiler identification is AppleClang 11.0.0.11000033

When using surfaces in multiple axial_mesh components, it is possible to get a segmentation fault from

TODO:

• Understand why this causes a segmentation fault in the first place.
• As discussed with @richeldichel , one should get an error when adding the same surface to two meshes since overlaying meshes don't make sense.

The classes KSWriteASCII, KSWriteVTK, KSWriteROOT, and KSWriteHDF5 all attempt to use the variable fName, which is a private member of KNamed. Instead they should be using the public access function KNamed::GetName() or fName could be made protected.

Greetings

I am new at using or learning Kassiopeia. I have recently installed Kassiopeia 3.5.0 on Ubuntu 16.04 LTS and I have trouble rendering complex geometries in both GeoViewer and MeshViewer. The "katrin visualization" tool renders blank canvas. The simple geometries a rendered without any problems.

Upon a preliminary investigation it appears to me that geometries constructed with what looks to me like "ROOT syntax" or mathematical operations are the ones that fail to render.

For Example: The port_housing_surface with the following line of code does not render

<circular_port x="-1./sqrt(2.)" y="-1./sqrt(2.)" z="-.5" radius="0.053"/>

This suggest to me that there may be something wrong with my Kassiopeia or ROOT configuration. I might be wrong.

I then also tried to run DipoleTrapSimulation.xml and attempted to view the .vtp output in ParaView without any success. Upon investigation I noticed there was a mathematical operation in the XML as well which supports my novice hunch.

What am I doing wrong? Is there a procedure I missed during installation or configuration to allow the application to process XML input files with embedded mathematics syntax?

I followed installation procedures listed here -> https://github.com/KATRIN-Experiment/Kassiopeia

My gROOT -> GetVersion( ) result is "6.13/03"

Kindly assist

Regards

For our application (BL3 at NIST) we are drawn to Kassiopeia because it allows 'easy' re-calculation of our various electrostatic field configurations, while our magnetic configuration is constant but affected by ferromagnetic elements. We are therefore using the KEMField magnetic_fieldmap functionality with COMSOL maps as input (through intermediate vti files).

There is one issue with this field map approach. We have multiple (n) magnetic field maps, each defined in a separate rectangular region of space. We use a magnetic_superposition_field to add them all together. However, this means that for every step we get n-1 warnings about points outside the map range of validity

[KEMFIELD NORMAL MESSAGE] WARNING: could not compute magnetic field at sample point 
<KPosition>
    <0>(double)-0.00917457<\0>
    <1>(double)0.135839<\1>
    <2>(double)1.29193<\2>
<\KPosition>

For now we just disable this warning in the code. A next improvement would be to be able to control the verbosity of the KEMField output, which may be in the works.

Fundamentally, there may be another solution needed here. I'm thinking of implementing the following:

• include a magnetic_fieldmap field outside_bounds_action which can be any logging type (normal, warning, error), default would be normal,
• include a magnetic_superposition_field field require_all which can true or false, default to true.

Thoughts?

I can't seem to update this respository. The error says:
remote: Permission to project8/Kassiopeia.git denied to pslocum.