Trac

trac@lists.einsteintoolkit.org

8708 discussions

#1775: Add Boost to ET
by Erik Schnetter 28 Mar '23

28 Mar '23

#1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Erik Schnetter): In CarpetX, we are using some algorithms for non-linear root-finding in con2prim. However, they don’t work on GPUs, and we might want to re-implement them anyway for this reason. I think that RePrimAnd also uses Boost, probably for filesystem operations $?$. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et

1 0

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Giuseppe Ficarra 27 Mar '23

27 Mar '23

#2697: Include BBH+scalar field initial data code from Canuda in ET Reporter: Cheng-Hsin Cheng Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Giuseppe Ficarra): Hi all, after deciding to withdraw NPScalars\_SF from the proposal, I have removed any reference of it from both test and example parameter files of TwoPunctures\_BBHSF. @{61aebb649615eb006f882fe9} do you want to have a look at this? Essentially I removed it completely from the test parameter file $and updated the output$ and I replaced it with the original NPScalars $which is already in the ETK$ in the example parameter files. Please use the new branch for the proposal [https://bitbucket.org/canuda/scalar/src/proposal\_ET\_2023\_05/](https://bi… to checkout the updated version of the code. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#1775: Add Boost to ET
by Zach Etienne 24 Mar '23

24 Mar '23

#1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Zach Etienne): I really dislike dependency bloat, as they add more points of failure during compilation and slow compilations greatly. $I’m cringing at the thought of compiling Boost in serial…$ Returning to Frank’s question: What parts of Boost are needed? Can we just use those? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et

1 0

#1881: Unclear error message for parameter file error
by Steven R. Brandt 24 Mar '23

24 Mar '23

#1881: Unclear error message for parameter file error Reporter: Erik Schnetter Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Steven R. Brandt): The problem is, the grammar does not currently see the par file in terms of lines. It treats whitespace much the same as C does. We could revise it to make whitespace important, but this seems of dubious value at best. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1881/unclear-error-mes…

1 0

#1775: Add Boost to ET
by Roland Haas 24 Mar '23

24 Mar '23

#1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): David Radice has a Boost thorn: [https://github.com/dradice/Boost](https://github.com/dradice/Boost) which we use for CarpetX. It is very slow to compile $compiles serially right now, and in CST which is not thorn-parallel either$. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et

1 0

#697: Repository and thorn names cannot be different
by Roland Haas 24 Mar '23

24 Mar '23

#697: Repository and thorn names cannot be different Reporter: Erik Schnetter Status: new Milestone: Version: Type: bug Priority: minor Component: GetComponents Changes (by Roland Haas): responsible: (was []) assignee: (was Eric Seidel) I am accessing some thorns stored in git repositories at bitbucket.org, which insists that all repository names are all lower case. I don't know how to specify this in GetComponents. When I say ``` !TARGET = $ARR !TYPE = git !URL = git@bitbucket.org:user/thorn.git !AUTH_URL = git@bitbucket.org:user/thorn.git !CHECKOUT = Arrangement/Thorn ``` then GetComponents does not create a symbolic link from Thorn to ../../repos/thorn, but to ../../repos/thorn/Arrangement/Thorn instead. How do I avoid this? **Keyword:** ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/697/repository-and-tho…

1 0

#2692: Inclusion of FUKA importer thorns
by tootle 24 Mar '23

24 Mar '23

#2692: Inclusion of FUKA importer thorns Reporter: tootle Status: new Milestone: ET_2023_05 Version: ET_2023_05 Type: proposal Priority: major Component: EinsteinToolkit thorn Comment (by tootle): @{557058:55837d30-c210-4b67-899f-972675258158} Thank you for your comment. Indeed, I’m aware of your work and have looked at the new RePrimAnd library a bit, however, I haven’t worked with the new thorn nor looked at what would be needed to interface the Fuka thorns with another EOS framework. The `kadath_pizza` thorn is quite trivial, but plays a necessary role. For simulations that utilize a tabulated equation of state, the initial temperature and Ye need to be initialized prior to the ID\_CONVERT stages. For our internal codes, the EOS manager initializes these values for us based on the extracted cold beta equilibrium slice, however, this was not the case when I was trying to run some comparison tests with WhiskyTHC. Instead of making the importer thorn more bloated I decided to write `kadath_pizza` to keep this functionality isolated and modular since interfaces differ between EOS frameworks. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

#2692: Inclusion of FUKA importer thorns
by Roland Haas 24 Mar '23

24 Mar '23

#2692: Inclusion of FUKA importer thorns Reporter: tootle Status: new Milestone: ET_2023_05 Version: ET_2023_05 Type: proposal Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): I see. Yes, an intermediate thorn $and ExternalLibrary$ that provides Boost would be needed $right now, for CarpetX we use David Radice’s thorn: [https://github.com/dradice/Boost](https://github.com/dradice/Boost), which provides a built in copy of Boost 1.55 or interfaces with a system installed Boost. It uses an older style of building things, than eg is used by “modern” ExternalLibraries like HDF5 or GSL, but actually that happens to work well for Boost$. Even if Boost is not part of the ET KadathThorn should declare a dependency on Boost in its `configuration.ccl` $same as the Reprimand helper thorn does$, since this way a non-system Boost can be interfaced correctly $Cactus sets the relevant `-I` and `-L` options$. CMake is a mixed bag on clusters usually. It is very much geared towards workstation setups where there is exactly one copy of a library and its `find_XXX` functions seem to not always follow a set pattern or let a user override settings $autoconf is similar,but usually at least lets one override everything with `CFLAGS` and `LDFLAGS` which CMake resists$. So I expect issues :-\) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

#2692: Inclusion of FUKA importer thorns
by Wolfgang Kastaun 24 Mar '23

24 Mar '23

#2692: Inclusion of FUKA importer thorns Reporter: tootle Status: new Milestone: ET_2023_05 Version: ET_2023_05 Type: proposal Priority: major Component: EinsteinToolkit thorn Comment (by Wolfgang Kastaun): @tootle Is the disabled kadath\_pizza part simply using the EOS framework from WhiskyTHC? Because the RePrimAnd thorn that is part of the ET includes this functionality and the interface is very similar $I was the one who wrote the “pizza” parts of WhiskyTHC$. So maybe it would make sense to just use RePrimAnd instead. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

#2692: Inclusion of FUKA importer thorns
by tootle 24 Mar '23

24 Mar '23

#2692: Inclusion of FUKA importer thorns Reporter: tootle Status: new Milestone: ET_2023_05 Version: ET_2023_05 Type: proposal Priority: major Component: EinsteinToolkit thorn Comment (by tootle): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} I had a look today and the dependencies that ptree relies within boost are too extensive to try and extract manually unfortunately. Therefore, the only option in the short term would be to include it as `DISABLED` if the ETK maintainers agree or to exclude these thorns altogether. > If the dependency persists the is should be listed in `configuration.ccl` along with `GSL` etc. This would still require there to be an intermediate thorn that `PROVIDES BOOST`. > You may also need to consider an `OPTIONAL` dependency on `CMake` in particular if you require a non-ancient `cmake`. Some of CarpetX dependencies do that $AMReX, ADIOS I think$ and can optionally use a cmake in `${CMAKE_DIR}/bin/cmake` instead of just `cmake`. I think the two of them between them now require cmake `3.23` $from around July 2022, so very very recent for HPC clusters$. This is an interesting point. In reality the current version of KADATH is based on cmake 2.8 which I’ve recently had to start manually removing old safeties that interfere with methods implemented in cmake >3.2. Specifically, base KADATH included its on modules for `find_package` for its dependencies which would override the modern default scripts. This meant that all the search routines for looking for packages in `$ENV{<PACKAGE NAME>_ROOT}` were not searched since this was not implemented until cmake 3 I believe. I know there are those that unfortunately have to deal ith systems running old libraries, but this is not something I deal with at the moment so it is difficult to test and develop against. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac