 |
Peano
|
|
Peano
|
Some frequently asked questions and problems are discussed below. These are descriptions from users' point of view. For FAQs which address developers of new features, please consult the respective components, packages, extensions and toolboxes.
The code generator always favours autotools. I.e. if an autotools build is present, the code generator chooses to use autotools. The environment variable PEANO_CMAKE_BUILD_DIR can be set to point to a CMake build folder. Then, the code generator will favour CMake instead of autotools. If there are multiple CMake build folders present (e.g. a GPU build and a non-GPU build), simply setting the flag PEANO_CMAKE_BUILD_DIR to one particular build folder tells the code generator which one to use. Unsetting the environment variable allows to switch back to autotools. If only one of the build systems has been configured, the code generator will choose the one present.
autoreconf --install libtoolize; aclocal; autoconf; autoheader; cp src/config.h.in .; automake --add-missing
--build=x86_64 --host=x86_64to your configure call seems to be necessary.
This error is common when using CCACHE in Docker containers on macOS due to how Docker handles file permissions in mounted volumes. CCACHE requires write access to its cache directory, but MacOS and Docker can have mismatched UID/GID (user and group IDs), especially when the cache directory is a mounted volume. This mismatch can prevent CCACHE from writing to the directory, causing "Permission Denied" errors.
This can be easily resolve by setting
-DUSE_CCACHE=OFF
in the CMake configuration.
ParticleSet.h:71:9: error: declaration of 'using SieveParticles = class toolbox::particles::SieveParticles<T>' changes meaning of 'SieveParticles' [-fpermissive]
71 | using SieveParticles = SieveParticles<T>;
This seems to be a bug in our code which the particles toolbox hosts and GCC finds. A discussion of this one can be found on Bugzilla. However, it seems that LLVM has no issue with this code and newer GCCs (e.g. from 13.3.0 onwards) have no issue with this code. '#pragma float_control(precise, off)' is illegal when except is enabledWe have seen this error with some LLVM-based compilers. Please re-translate with
-fno-exceptions. Unfortunately, this disables some error checking in the checkpoint and file output routines. If that does not help, you might want to reduce the optimisation level. On Intel, switching from -fast to -O3 does work in some cases. ./peano4/grid/GridTraversalEvent.h:161:7: warning: unknown attribute 'compress' ignored [-Wunknown-attributes]
[[clang::pack]] std::bitset<TwoPowerD> _hasBeenRefined;
Please consult your compiler options. Usually re-configuring with the flag -Wno-unknown-attributeseliminates the warnings.
My C++ version is too old Try to rerun configure with
CXXFLAGS=-std=c++20
Depending on your compiler, the flag might also be
CXXFLAGS=--std=c++20
Some compilers want you to use two hyphens, others expect one. Please note that most Clang-based compiler installations do not bring their own C++ standard library to the table. They use the pre-existing GCC STL. Now, if your Clang-based compiler - that includes NVIDIA and Intel - is built against a version of GNU whose STL is too old, you will get errors despite the std flag. In this case, you have to load a newer GCC module after you have loaded your Intel, NVIDIA or Clang module. You basically load the Clang-based compiler which will introduce a GNU STL, i.e. set the corresponding environment variables. After that, you manually load a newer GCC which redirects all of these variables.
If there are multiple gcc versions present, it is possible for CLANG to automatically select an outdated version thus creates problem when compiling. You can check what is the selection version with
clang++ -v
Use this to select the other listed options:
--gcc-install-dir=/path/to/new/gcc
tarch/multicore/multicore.cpp:13:19: error: `align_val_t` is not a member of `std`
13 | return new (std::align_val_t(Alignment)) double[size];
We have seen this error with GCC if the supported C++ generation is too old. See remarks above.`warning \#3191: scoped enumeration types are a C++11 feature`Your compiler seems not to have C++11 (or, newer) enabled by default. See remarks above.
"tarch/plotter/griddata/unstructured/vtk/VTKBinaryFileWriter.cpp", line 42: error: name followed by "::" must be a class or namespace name
if (not std::filesystem::exists(indexFileName + ".pvd"))
We have seen this error with GCC if the supported C++ generation is too old. See remarks above.error: unknown attribute 'optimize' ignored*Unfortunately, CLANG seems to pretend to be GNU on some systems and then the wrong header is included. Consult the remarks on compiler-specific settings. Ensure that the flag
CompilerCLANG is enabled and used.array 'new' cannot have initialization arguments All-time classic with many compilers: Add --std=c++23 to your CXXFLAGS and the issue should be gone.configure fails for the NVIDIA compiler For NVIDIA, we have to make CXX and CC point to the C++ compiler, as both are passed the same arguments by configure, which are actually only understood by the C++ version. So please ensure that both flags delegate to nvc++.
export NVCPP=/opt/nvidia/hpc_sdk/Linux_x86_64/2022/compilers/bin/nvc++
./configure CXX=$NVCPP CC=$NVCPP ...
Furthermore, some compute kernels are not available with the NVIDIA tools, as the compiler is pretty picky when it decides which temporary variables it might place on the call stack. This should not affect Peano 4's core, but it can affect some extensions such as ExaHyPE.
The page Vendor Software Stacks and System- and Compiler-specific Settings holds some additional, bespoke information for the NVIDIA toolchain, which might be of further help.
/nobackup/frmh84/Peano/src/libTarch_debug.a(libTarch_debug_a-Tasks.o): In function `tarch::multicore::native::spawnTask(tarch::multicore::Task*, std::set<int, std::less<int>, std::allocator<int> > const&, int const&)':
/nobackup/frmh84/Peano/src/tarch/multicore/omp/Tasks.cpp:275: undefined reference to `__kmpc_omp_taskwait_deps_51'
We have seen this with Intel compiler when you use the Clang LLVM OpenMP runtime, i.e. use -fopenmp. Switch to -fiopenmp instead.CXXFLAGS=-fsycl and the autotools try to enable the default C compiler with this flag. To fix it, set CC=icpx to the C++ compiler, too.LDFLAGS="-lhdf5_hl_cpp -lhdf5_cpp -lhdf5_hl -lhdf5 -lstdc++"This list is not comprehense and might differ on each system. The safest way to find these flags is to run the HDF5 compiler with verbose. It is actually only a wrapper around your real compiler which sets some variables, i.e. the verbose mode should give you the flags that are set, and then you can add these flags manually to your configure call. The Peano 4 applications then will pick up these flags automatically the next time you invoke the Python scripts.
/apps/developers/compilers/gcc/13.2/1/default/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../include/c++/13.2.0/chrono:2320:48: error: call to consteval function 'std::chrono::hh_mm_ss::_S_fractional_width' is not a constant expression
static constexpr unsigned fractional_width = {_S_fractional_width()};
We have seen this with too new C++ standard libs such as the version 13.2. Use an older one such as 11.2.LDFLAGS="-ltbb"and you should be fine.
undefined reference to for_stop_core
undefined reference to for_write_seq_list
This tells you that the linker failed to find the Fortran standard libraries. For the GNU compilers, you need for example the flag -lgfortran while Intel requires -lifcore within the LDFLAGS. You can add these flags manually via your Python script to the code, but I think this is a flaw. They belong into the configuration not into your Python script.
-lExaHyPE2Core2d_asserts -lToolboxLoadBalancing2d_asserts -lPeano4Core2d_asserts -lTarch_assertsSo the link order is high-level extensions, toolboxes, core, tarch. The Makefile which is generated by the Python API should follow this convention.
undefined reference to __kmpc_omp_taskwait_deps_51when compiling with OpenMP multithreading using the icpx compiler, you are probably not using the new -fiopenmp flag. Make sure to pass -fiopenmp to your configuration instead of -fopenmp.
ZET_ENABLE_PROGRAM_DEBUGGING=1Simply unset it to fix the issue.
The JIT compiler crashes due to the FPGA emulation device on our cluster (NCC). If this happens on your machine, try putting SYCL_DEVICE_FILTER=gpu before the command to run the benchmark.
import peano4 yields not found error***. You haven't set your PYTHONPATH properly. Ensure that it points to Peano's python subdirectory. So use something similar to export PYTHONPATH=~/git/Peano/pythonPeano 4 is currently transitioning to a scheme, where the Python code is held next to the C++ sources in api subdirectories. As such, it might be necessary to add the src path to the Python path, too:
export PYTHONPATH=~/git/Peano/python:~/git/Peano/src
-DTBB_USE_ASSERT -DTBB_USE_THREADING_TOOLS.Please consult the vendor-specific supercomputer/tool remarks
CXXFLAGS="... -Iyour-path/otter/include"
LIBS="... -lotter-task-graph -lotf2to your libraries. Depending on your system, you might need the explicit linking to otf2 or not.
LDFLAGS="... --Lyour-path/otter/build/lib -L/opt/otf2/lib"Once again, you might need the explicit OTF2 link or not.
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:your-path/otter/build/lib:/opt/otf2/libas the checks otherwise will fail.
export PYTHONPATH=../Peano/python:/usr/lib/python3/dist-packages
import sys
!{sys.executable} -m pip install --break-system-packages pyvista
and then you should have it within your notebook.Ensure that your main code is translated with a reasonable debug flag. The makefile has to translate your code with
-DPeanoDebug=4
to get debug info. 1 implies that you see only traces. Study tarch::logging::Log for details.
build: 2d, no mpi, C++ threading, debug level=4on the terminal. Again, has to be 1 or 4 at least.
tarch::logging::LogFilter::getInstance().addFilterListEntry(
tarch::logging::LogFilter::FilterListEntry(
tarch::logging::LogFilter::FilterListEntry::TargetInfo,
tarch::logging::LogFilter::FilterListEntry::AnyRank,
"examples::algebraicmg",
tarch::logging::LogFilter::FilterListEntry::WhiteListEntry
)
);
tarch::logging::LogFilter::getInstance().printFilterListToCout();into your code and see which entries it does enlist.
-check_mpiYou should not get any error reports. If you do, we have had serious problems as some of Peano's classes use MPI_C_BOOL or MPI_CXX_BOOL. They seem not be supported properly. Using MUST as MPI correctness checker might help you further.
1.10.0