#2858: Compiling CarpetX: issues with PDESolvers
Reporter: Alejandra Gonzalez
Status: open
Milestone:
Version:
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
Very good. Thank you. Most easily may be as a pull request, but it is also ok to just attach them to this ticket \(or create a new one\) and I’ll make a commit for you out of them.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2858/compiling-carpetx…
#2882: Running BBH with CarpetX with CPUs: High memory consumption and low performance
Reporter: Alejandra Gonzalez
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: CarpetX
Comment (by Liwei Ji):
I’m not surprised with this speed without subcycling.
You can do the following to improve a bit
1. Turn off calc\_ADMRHS\_vars, it’s not required for BBH simulations.
2. Use 2 OMP instead of 7. It’s the best number for me. You should try different OMP yourself.
3. You can also play a bit with the par `max_tile_size_x` while keeping `max_tile_size_y/z` small. I didn’t see big speed difference for myself, but you can still try.
For the memory issue, if you are using Z4c from the development branch of my fork, it has 5 copies of state vector for the purpose of subcycling. You can use the main branch instead.
@{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} could you take a look at the `run_cactus.sh` and see if there anything suspicions?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2882/running-bbh-with-…
#2858: Compiling CarpetX: issues with PDESolvers
Reporter: Alejandra Gonzalez
Status: open
Milestone:
Version:
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Alejandra Gonzalez):
Hi Roland, yes this is solved and I’m happy to share the files for Marenostrum 5 to simfactory.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2858/compiling-carpetx…
#2883: ExternalLibraries fail to build with cmake 4.0
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
Specifically this happens with NSIMD on OpenSuSE Tumbleweed:
```
NSIMD: Configuring...
CMake Error at CMakeLists.txt:23 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
```
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2883/externallibraries…
#2858: Compiling CarpetX: issues with PDESolvers
Reporter: Alejandra Gonzalez
Status: open
Milestone:
Version:
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
@{557058:89ccef74-e8aa-4588-b99a-e0583a11e890} can this ticket be closed ? Since you seem to be able to at least compile now?
Also: would you consider contributing your working Marenostrum5 files to simfactory?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2858/compiling-carpetx…
#2171: PAPI Compile Issues with Intel 19 beta on Ubuntu 18.04
Reporter: Zach Etienne
Status: wontfix
Milestone:
Version: development version
Type: bug
Priority: minor
Component: Other
Changes (by Roland Haas):
status: wontfix (was new)
I get this error message when attempting to compile the latest ETK master (Jul 27, 2018) with the default ThornList using Intel 19.0.0.070 20180524 on Ubuntu 18.04:
PAPI: Building...
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(140): error: identifier "_Float32" is undefined
extern _Float32 strtof32 (const char *__restrict __nptr,
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(146): error: identifier "_Float64" is undefined
extern _Float64 strtof64 (const char *__restrict __nptr,
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(158): error: identifier "_Float32x" is undefined
extern _Float32x strtof32x (const char *__restrict __nptr,
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(164): error: identifier "_Float64x" is undefined
extern _Float64x strtof64x (const char *__restrict __nptr,
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(233): error: identifier "_Float32" is undefined
_Float32 __f)
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(239): error: identifier "_Float64" is undefined
_Float64 __f)
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(251): error: identifier "_Float32x" is undefined
_Float32x __f)
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(257): error: identifier "_Float64x" is undefined
_Float64x __f)
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(316): error: identifier "_Float32" is undefined
extern _Float32 strtof32_l (const char *__restrict __nptr,
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(323): error: identifier "_Float64" is undefined
extern _Float64 strtof64_l (const char *__restrict __nptr,
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(337): error: identifier "_Float32x" is undefined
extern _Float32x strtof32x_l (const char *__restrict __nptr,
^
In file included from pfmlib_common.c(32):
/usr/include/stdlib.h(344): error: identifier "_Float64x" is undefined
extern _Float64x strtof64x_l (const char *__restrict __nptr,
^
compilation aborted for pfmlib_common.c (code 2)
**Keyword:** None
Comment (by Roland Haas):
closing as no longer relevant
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2171/papi-compile-issu…
#2883: ExternalLibraries fail to build with cmake 4.0
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: EinsteinToolkit thorn
it seems that at least some of the ExternalLibraries fail to compile with cmake 4.0 claiming that cmake is too old and that at least cmake 3.5 is required .
This looks like they are doing the version check incorrectly \(since there is a bump in the major cmake version\).
A workaround is to downgrade cmake or to use the CMake thorns in ExternalLibraries and its embedded cmake.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2883/externallibraries…
#2881: Running BBH with CarpetX: Assertion `all(i >= 0 && i + order < grid.lsh)' failed
Reporter: Alejandra Gonzalez
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: CarpetX
Comment (by Liwei Ji):
Hi Alejandra, could you share the output for puncture trajectory?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2881/running-bbh-with-…
#2882: Running BBH with CarpetX with CPUs: High memory consumption and low performance
Reporter: Alejandra Gonzalez
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: CarpetX
Hello,
This ticket is due to concerns regarding the performance of CarpetX running **with CPUs** in the new machine MareNostrum 5.
The first issue I had was the memory needed to run a q=1 configuration, coming across several out-of-memory errors \(regardless of the number of nodes requested\). The standard nodes in MN5 have 2GB per core \(112 cores per node\), so I had to switch to the high memory ones to be able to make it run \(this is the line \`#SBATCH --constraint=highmem\` in the attached batch file\). Is this also the case for other machines?
The second issue is that now that is running \(`ncells=128` and 1 node\) it’s going awfully slow ~0.07 M/hr, less than I would expect from using one node. These type of binary configurations we have been running them in 2~4 nodes reaching speeds of around 4~7 M/hr with Carpet and at higher resolution.
Attached you find the parfile, batch file, and output.
attachment: q1.__0._0._0.8__0._0._0.8__e0.5.par (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…)
attachment: output.log (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…)
attachment: run_cactus.sh (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2882/running-bbh-with-…
#2881: Running BBH with CarpetX: Assertion `all(i >= 0 && i + order < grid.lsh)' failed
Reporter: Alejandra Gonzalez
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: CarpetX
Hello everyone,
Thanks to your suggestions earlier this year I have been able to compile and successfully run CarpetX with both GPUs and CPUs in the new MareNostrum 5 machine.
At the moment I’m trying to increase the mass ratio of the configurations I’m running and while jumping from q=1 to q=2 I encounter this error which I’m pretty sure you are all familiar with:
```
cactus_sim_cx: /gpfs/home/uib/uib416720/ETK2024/CarSpX/Cactus/configs/sim_cx/build/CarpetX/interpolate.cxx:277: void CarpetX::_GLOBAL__N__5cdcd65a_15_interpolate_cxx_ba36a62c_4043235::interpolator<T, order, centering>::interpolate3d(const Particles&, std::vector<T>&) const [with Particles = amrex::ArrayOfStructs<amrex::Particle<3, 2>, amrex::ArenaAllocator>; T = double; int order = 3; int centering = 0]: Assertion `all(i >= 0 && i + order < grid.lsh)' failed.
```
I have tried to increase the domain size and the grid size on all dimensions but the error keeps showing up.
Attached you can find the parfile I’m using.
Cheers,
Alejandra
attachment: q2.__0.6_0._0.__0.6_0._0.__e0.3.par (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2881/running-bbh-with-…
#2837: Building the Einstein Toolkit
Reporter: Suo-Ning Wang
Status: closed
Milestone:
Version: development version
Type: bug
Priority: major
Component: EinsteinToolkit website
Changes (by Roland Haas):
status: closed (was open)
Comment (by Roland Haas):
stale
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2837/building-the-eins…