Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2692: Inclusion of FUKA importer thorns
by Roland Haas 04 Apr '23

04 Apr '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): 1. yes, please 2. only the `[submodule "fuka"]` block \(which is non-functional anyway\) 3. you won’t need a `ET_YYYY_MM` etc. branch in `fuka` as long as the submodule import in `KadathThorn` is a “regular” one that specifies a specific commit \(that one then needs to manually update when one wants to use a newer `fuka` version\) and is not auto-set to track a \(changing\) branch \(your’s does currently have a fixed commit\). If things are changed at `KadathThorn` is set to track a specific branch of `fuka` \(via the `git submodule set-branch` and `git update --remote` commands\) then a `ET_YYYY_MM` branch and tags of type `ET_YYYY_MM_vN` \(where N starts from 0 and increases by 1 for each point \[bugfix\] release\) are needed. These are created shortly before the release when all code is frozen \(I think about 1 week before the release\). See [https://docs.einsteintoolkit.org/et-docs/Release\_Process#Timeline\_for\_a\… and the “Release preparation II” item. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

#2692: Inclusion of FUKA importer thorns
by tootle 04 Apr '23

04 Apr '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): Hi @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} Thanks for the feedback. Since I haven’t been told directly, what was the results of the meeting? Will the FUKA thorns be included as DISABLED? If so, is the following summary accurate for the required changes for inclusion: 1\. Set the `Kadaththorn` to require BOOST 2\. Remove submodule block 3\. Generate ET release branches/tags \(ET\_2023\_05\) for fuka, kadaththorn, and kadathimporter repos \* For tags, what is used for vN? Is this comprehensive? Thanks ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

#2706: increase TwoPunctures resolution in BBH gallery example
by Roland Haas 03 Apr '23

03 Apr '23

#2706: increase TwoPunctures resolution in BBH gallery example Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit website @{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} reports that increasing TP resolution in the galley example helps reducing initial data noise in the simulations \(in a forthcoming paper\). Thus is might be good to increase the resolution and regenerate all data for the gallery page and Zenodo \(and ask Barry and Ian to update it with a new version\). Most likely this is too late for ET\_2023\_05 but could be done for ET\_2023\_11. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2706/increase-twopunct…

1 0

#2692: Inclusion of FUKA importer thorns
by Roland Haas 01 Apr '23

01 Apr '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): In the current KadathThorn, there is a `.gitmodules` file: ``` [submodule "src/fuka"] path = src/fuka url = https://bitbucket.org/fukaws/fuka/ [submodule "fuka"] branch = fuka ``` for the fuka library checked out into `src/fuka` as a git submodule. This all works and is fine. However I notice that you are also including a section: ``` [submodule "fuka"] branch = fuka ``` which will be ignored since there is no `fuka` submodule \(the submodule is `src/fuka`\). Moreover, if it was _not_ ignored, it would actually be an issue for the ET unless it is removed or fixed to a `ET_YYYY_MM` branch for each release branch and fixed to a specific git hash for each `ET_YYYY_MM_vN` release tag. Otherwise it points to the _current_ head of that branch which is not what one would want for an ET release branch or tag \(which should point to the specific, tested version that was released\). Since it is ignored anyway, it may be best to remove this section altogether to not give any false impression on what commit of `fuka` is actually checked out. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…

1 0

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Roland Haas 31 Mar '23

31 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 Roland Haas): Right now the code for TwoPunctures\_BBHSH in the ET manifest thornlist is from branch `proposal_ET_2023_05` in Canuda. While ok in principle it is a bit strange to not have this eg in either development \(since it saw changes\) or master \(which for Canuda seems to be the “trusted” branch\). If included in the ET the code is expected to be “good' and what the authors use themselves. Eg for sure for the eventual release the changes must be in an `ET_2023_05` branch which normally should be a child of the trusted branch \(`master` in this case\). Since the ET manifests `master` branch is not the “trusted good” but the “bleeding edge” branch \(for the ET\), one should be able to pick up bug fixes on ET released thorns in it without changing branches. With `proposal_ET_2023_05` does seems unlikely since I would expect bug fixes to show up either in `development` or `master`of Scalar, wouldn't they? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#2678: clean up GRHydro schedule file
by Roland Haas 30 Mar '23

30 Mar '23

#2678: clean up GRHydro schedule file Reporter: Roland Haas Status: resolved Milestone: Version: Type: enhancement Priority: trivial Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2678/clean-up-grhydro-…

1 0

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Thiago Assumpcao 29 Mar '23

29 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 Thiago Assumpcao): Hi all, I have reviewed Giuseppe’s most recent changes to TwoPunctures\_BBHSF. The code has very good documentation, is well commented and has tests together with their expect output. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#1775: Add Boost to ET
by Roland Haas 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 Roland Haas): If and when we include Boost in the ET I would strongly advertise to include the whole [thing.Ie](http://thing.Ie) there is one “Boost” thorn that provides everything. Splitting up Boost into `Boost_FileSyste` and `Boost_SpecialFunctions` etc similar to what eg Debian’s package manger does, just buys into lots of dependency issues. To me the goal of ExternalLibraries is to provide a simple, working fallback and way to for Cactus thorns to interface with the 3rd party libs. It should not become a full featured package management system since we lack resources to maintain that. If this means it is slow the relying on fallback compilation, then so be it. If it is slow all the time even when mostly not used \(OpenSSL is in that category if it compiles\) then this may be an issue. Generally I feel that expecting a 5minute compile time, without any prior experience and expecting a fully optimized build that way is not realistic for a scientific code. I certain level of experience of the user is expected, at least if they desire an “optimized” build. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et

1 0

#1775: Add Boost to ET
by Wolfgang Kastaun 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 Wolfgang Kastaun): Reprimand uses boost only internally for root-solving \(con2prim\) and ODE-solving \(TOV solver\). Both will not be replaced any time soon but those are header-only dependencies that could be distributed with reprimand. Include files exported by reprimand do not include anything from boost so this wont lead to clashes with other code doing the same. The only file operations use hdf5, nothing from boost. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et

1 0

#1881: Unclear error message for parameter file error
by Erik Schnetter 28 Mar '23

28 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 Erik Schnetter): I think that a parameter file should be interpreted in terms of lines. Humans think in terms of lines, and ignoring lines is confusing. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1881/unclear-error-mes…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac