Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering
by Roland Haas 20 Feb '24

20 Feb '24

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering Reporter: tootle Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2772/issues-link-again…

1 0

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering
by Roland Haas 20 Feb '24

20 Feb '24

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering Reporter: tootle Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2772/issues-link-again…

1 0

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering
by Roland Haas 20 Feb '24

20 Feb '24

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering Reporter: tootle Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Testing this I can nudge things from $the not correct$: ``` g++ -o "/data/rhaas/postdoc/gr/cactus/ET_trunk/exe/cactus_fuka" -fopenmp -Wall -g -std=gnu++17 -O2 -fopenmp -Wall -rdynamic "/data/rhaas/postdoc/gr/cactus/ET_trunk/configs/fuka/datestamp.o" -Wl,--whole-archive -L/data/rhaas/postdoc/gr/cactus/ET_trunk/configs/fuka/lib -lthorn_ADMBase -lthorn_ADMCoupling -lthorn_ADMMacros -lthorn_AEILocalInterp -lthorn_AHFinderDirect -lthorn_BLAS -lthorn_Boost -lthorn_Boundary -lthorn_Carpet -lthorn_CarpetIOHDF5 -lthorn_CarpetIOScalar -lthorn_CarpetInterp -lthorn_CarpetLib -lthorn_CarpetMask -lthorn_CarpetReduce -lthorn_CarpetSlab -lthorn_CartGrid3D -lthorn_CoordBase -lthorn_CoordGauge -lthorn_CycleClock -lthorn_FFTW3 -lthorn_GSL -lthorn_HDF5 -lthorn_HydroBase -lthorn_IOASCII -lthorn_IOBasic -lthorn_IOUtil -lthorn_InitBase -lthorn_KadathImporter -lthorn_KadathThorn -lthorn_LAPACK -lthorn_LocalInterp2 -lthorn_LocalReduce -lthorn_LoopControl -lthorn_MPI -lthorn_MoL -lthorn_NaNChecker -lthorn_PUGH -lthorn_SpaceMask -lthorn_SphericalSurface -lthorn_StaticConformal -lthorn_SymBase -lthorn_SystemTopology -lthorn_Time -lthorn_Timers -lthorn_TmunuBase -lthorn_Vectors -lthorn_hwloc -lthorn_zlib -lthorn_Cactus -lthorn_CactusBindings -Wl,--no-whole-archive -L/data/rhaas/postdoc/gr/cactus/ET_trunk/configs/fuka/scratch/external/KadathThorn/lib -L/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -L/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/gcc/x86_64-linux-gnu/13 -Wl,-rpath,/data/rhaas/postdoc/gr/cactus/ET_trunk/configs/fuka/scratch/external/KadathThorn/lib -Wl,-rpath,/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -Wl,-rpath,/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -Wl,-rpath,/usr/lib/x86_64-linux-gnu/hdf5/openmpi -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib -Wl,-rpath,/usr/lib/gcc/x86_64-linux-gnu/13 -lkadath -lmkl_scalapack_lp64 -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lmkl_scalapack_lp64 -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lgsl -lgslcblas -lm -lfftw3 -lboost_filesystem -lboost_system -lhdf5hl_fortran -lhdf5_fortran -lhdf5_hl -lhdf5 -lmpi -lhwloc -levent_core -levent_pthreads -lm -lz -lsz -lz -lmpi_cxx -lmpi -lm -lz -lmpi_cxx -lmpi -lhwloc -lm -ludev -lpthread -lz -lm -lm -lm -lm -lm -lm -lm -lm -lcrypt -lgfortran ``` to the $more correct$: ``` g++ -o "/data/rhaas/postdoc/gr/cactus/ET_trunk/exe/cactus_fuka" -fopenmp -Wall -g -std=gnu++17 -O2 -fopenmp -Wall -rdynamic "/data/rhaas/postdoc/gr/cactus/ET_trunk/configs/fuka/datestamp.o" -Wl,--whole-archive -L/data/rhaas/postdoc/gr/cactus/ET_trunk/configs/fuka/lib -lthorn_ADMBase -lthorn_ADMCoupling -lthorn_ADMMacros -lthorn_AEILocalInterp -lthorn_AHFinderDirect -lthorn_BLAS -lthorn_Boost -lthorn_Boundary -lthorn_Carpet -lthorn_CarpetIOHDF5 -lthorn_CarpetIOScalar -lthorn_CarpetInterp -lthorn_CarpetLib -lthorn_CarpetMask -lthorn_CarpetReduce -lthorn_CarpetSlab -lthorn_CartGrid3D -lthorn_CoordBase -lthorn_CoordGauge -lthorn_CycleClock -lthorn_FFTW3 -lthorn_GSL -lthorn_HDF5 -lthorn_HydroBase -lthorn_IOASCII -lthorn_IOBasic -lthorn_IOUtil -lthorn_InitBase -lthorn_KadathImporter -lthorn_KadathThorn -lthorn_LAPACK -lthorn_LocalInterp2 -lthorn_LocalReduce -lthorn_LoopControl -lthorn_MPI -lthorn_MoL -lthorn_NaNChecker -lthorn_PUGH -lthorn_SpaceMask -lthorn_SphericalSurface -lthorn_StaticConformal -lthorn_SymBase -lthorn_SystemTopology -lthorn_Time -lthorn_Timers -lthorn_TmunuBase -lthorn_Vectors -lthorn_hwloc -lthorn_zlib -lthorn_Cactus -lthorn_CactusBindings -Wl,--no-whole-archive -L/data/rhaas/postdoc/gr/cactus/ET_trunk/configs/fuka/scratch/external/KadathThorn/lib -L/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -L/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -L/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr/lib/gcc/x86_64-linux-gnu/13 -Wl,-rpath,/data/rhaas/postdoc/gr/cactus/ET_trunk/configs/fuka/scratch/external/KadathThorn/lib -Wl,-rpath,/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -Wl,-rpath,/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -Wl,-rpath,/opt/intel/oneapi/mkl/2021.3.0/lib/intel64 -Wl,-rpath,/usr/lib/x86_64-linux-gnu/hdf5/openmpi -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib -Wl,-rpath,/usr/lib/x86_64-linux-gnu/openmpi/lib -Wl,-rpath,/usr/lib/gcc/x86_64-linux-gnu/13 -lkadath -lfftw3 -lgsl -lgslcblas -lm -lmkl_scalapack_lp64 -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lboost_filesystem -lboost_system -lmkl_scalapack_lp64 -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lmkl_scalapack_lp64 -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lgsl -lgslcblas -lm -lfftw3 -lboost_filesystem -lboost_system -lhdf5hl_fortran -lhdf5_fortran -lhdf5_hl -lhdf5 -lmpi -lhwloc -levent_core -levent_pthreads -lm -lz -lsz -lz -lmpi_cxx -lmpi -lm -lz -lmpi_cxx -lmpi -lhwloc -lm -ludev -lpthread -lz -lm -lm -lm -lm -lm -lm -lm -lm -lcrypt -lgfortran ``` Change to KadathThorn: ```diff diff --git a/src/detect.sh b/src/detect.sh index 9f80ed6..d5be1a0 100755 --- a/src/detect.sh +++ b/src/detect.sh @@ -89,9 +89,10 @@ echo "END MESSAGE" # Pass options to Cactus echo "BEGIN MAKE_DEFINITION" echo "KADATH_DIR = ${KADATH_DIR}" -echo "KADATH_INC_DIRS = ${KADATH_INC_DIRS}" -echo "KADATH_LIB_DIRS = ${KADATH_LIB_DIRS}" -echo "KADATH_LIBS = ${KADATH_LIBS}" +echo "KADATH_INC_DIRS = ${KADATH_INC_DIRS} ${FFTW3_INC_DIRS} ${GSL_INC_DIRS} ${LAPACK_INC_DIRS} ${BOOST_INC_DIRS}" +echo "KADATH_LIB_DIRS = ${KADATH_LIB_DIRS}" ${FFTW3_LIB_DIRS} ${GSL_LIB_DIRS} ${LAPACK_LIB_DIRS} ${BOOST_LIB_DIRS} +# keep the order like this, since MKL (LAPACK) can contain a (partial) FFTW3 which conflicts +echo "KADATH_LIBS = ${KADATH_LIBS} ${FFTW3_LIBS} ${GSL_LIBS} ${LAPACK_LIBS} ${BOOST_LIBS}" echo "END MAKE_DEFINITION" echo 'INCLUDE_DIRECTORY $(KADATH_INC_DIRS)' ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2772/issues-link-again…

1 0

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering
by Roland Haas 20 Feb '24

20 Feb '24

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering Reporter: tootle Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): How about adding \`$\{FFTW3\_LIBS\}\` to KadathThorn’s LIBS output in detect.sh ? Like HDF5 does: ``` HDF5_LIB_DIRS="$HDF5_LIB_DIRS $MPI_LIB_DIRS" HDF5_INC_DIRS="$HDF5_INC_DIRS $MPI_INC_DIRS" HDF5_LIBS="$HDF5_LIBS $MPI_LIBS" ``` That lets you ensure that FFTW3\_LIBS is right after Kadath’s. This should work for static linking. For dynamic linking adding it to `LD` should work. So it’s a cluster specific solution $at least for `LD`$ but so is this issue you are encountering. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2772/issues-link-again…

1 0

#2770: make ADIOS2 compile on macOS
by Roland Haas 19 Feb '24

19 Feb '24

#2770: make ADIOS2 compile on macOS Reporter: Roland Haas Status: resolved Milestone: Version: ET_2023_11 Type: bug Priority: major Component: Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2770/make-adios2-compi…

1 0

#2770: make ADIOS2 compile on macOS
by Roland Haas 19 Feb '24

19 Feb '24

#2770: make ADIOS2 compile on macOS Reporter: Roland Haas Status: open Milestone: Version: ET_2023_11 Type: bug Priority: major Component: Comment (by Roland Haas): Comments in the ET call on Feb 15th say to backport the tar file. Done in git hash [4caaaaa](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/commit… "ADIOS2: update to 2.9.2" of [ExternalLibraries-ADIOS2](https://github.com/EinsteinToolkit/ExternalLibrar… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2770/make-adios2-compi…

1 0

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering
by tootle 15 Feb '24

15 Feb '24

#2772: Issues link against Kadath thorns and Intel MKL due to link ordering Reporter: tootle Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by tootle): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} any updates on whether or not this will be possible to do? Until this is resolved there's no point in pushing further updates to the importer as MKL is prevalent on HPC systems. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2772/issues-link-again…

1 0

#2770: make ADIOS2 compile on macOS
by Roland Haas 12 Feb '24

12 Feb '24

#2770: make ADIOS2 compile on macOS Reporter: Roland Haas Status: open Milestone: Version: ET_2023_11 Type: bug Priority: major Component: Comment (by Roland Haas): This is fixed in ADIOS 2.9.2 so will not need to be fixed in master anymore. This should be backported to the release though. So there’s two options: 1\. apply the patch here to the release version $2023\_11$ only 2\. bump the release’s included tar file to 2.9.2 which fixes the issue but brings in other changes as well In SGRID #2771 I applied the patch to the release even after master received a fix to the tar file $deeming the changes in the tar file to be more extensive than a minimal fix desired for the backport$. By the same argument one would apply the patch here, but the patch here is less “nice” and changes files that I doubt are actually used on macOS $being in directories named “windows”$. Comments? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2770/make-adios2-compi…

1 0

#2771: do not use non-standard include file "endian.h" in SGRID
by Roland Haas 12 Feb '24

12 Feb '24

#2771: do not use non-standard include file "endian.h" in SGRID Reporter: Roland Haas Status: resolved Milestone: Version: ET_2023_11 Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2771/do-not-use-non-st…

1 0

#2771: do not use non-standard include file "endian.h" in SGRID
by Roland Haas 12 Feb '24

12 Feb '24

#2771: do not use non-standard include file "endian.h" in SGRID Reporter: Roland Haas Status: open Milestone: Version: ET_2023_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2771/do-not-use-non-st…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac