Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Cheng-Hsin Cheng 22 Mar '23

22 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 Cheng-Hsin Cheng): Yes, I will remove NPScalars\_SF from the PR on the manifest. About the REPO\_BRANCH, is it possible for us to use a separate branch from master for our proposal for the next release? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Samuel Cupp 22 Mar '23

22 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 Samuel Cupp): Ok. Thank you for the update. If you don’t mind, can you also update the PR on the manifest? I believe there are also some commits to merge in as well. If you are ready, you can also merge TwoPunctures\_BBHSF into master and remove the REPO\_BRANCH line from the PR. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Cheng-Hsin Cheng 22 Mar '23

22 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 Cheng-Hsin Cheng): @{557058:088051f9-5b94-4b5e-bfbe-71137030b9c1} @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} Apologies for the lack of updates on NPScalars\_SF. But Helvi and Giuseppe and I were only discussing today about withdrawing it from inclusion into the next ETK release, and instead to update the original NPScalars thorn in the future to support other matter terms including scalar fields. From what I understand, Miguel thinks this would be a better decision for the code too. So we would like to retract NPScalars\_SF from the next release, and Peter is off the hook from reviewing it. Dropping NPScalars\_SF will affect the parameter files in TwoPunctures\_BBHSF which are using it, so we will also update the parameter files there to use the original NPScalars. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Samuel Cupp 22 Mar '23

22 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 Samuel Cupp): Leo and I had already received an email regarding TwoPunctures\_BBHSF, but @{5a39478ed96dcc384266ff71} has finished his review, so all that remains is completing the review for NPScalars\_SF. Whenever @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} has an update, please let us know. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#1946: sim setup should create a section for the current machine
by Roland Haas 22 Mar '23

22 Mar '23

#1946: sim setup should create a section for the current machine Reporter: Roland Haas Status: open Milestone: Version: development version Type: enhancement Priority: minor Component: SimFactory Comment (by Roland Haas): @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} also came across this issue of `sourcebasedir` not being set when running `sim setup-silent` on known machines and in a directory different from what simfactory has in its machine database \(private communication\). This ticket may serve as a catchall to collect discussion and possible patches. The issue does not occur in the “official” workflow \(see SF paper: [https://arxiv.org/pdf/1008.4571](https://arxiv.org/pdf/1008.4571) page 4, “A. Managing Source Code“\), which would avoid ever running `sim setup` on the cluster \(and never run `GetComponents` there either\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1946/sim-setup-should-…

1 0

#2696: Update kuibit to 1.4.0
by Roland Haas 21 Mar '23

21 Mar '23

#2696: Update kuibit to 1.4.0 Reporter: Gabriele Bozzola Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Nice. Thank you. I can see this is going to be a continuous struggle with versions of Python / numpy / whatnot. Hiding Python 3.8 in the GNU modules is a mean trick by TACC. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2696/update-kuibit-to-…

1 0

#2696: Update kuibit to 1.4.0
by Gabriele Bozzola 21 Mar '23

21 Mar '23

#2696: Update kuibit to 1.4.0 Reporter: Gabriele Bozzola Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Gabriele Bozzola): I managed to add compatibility for Python 3.7 with no inconvenience for users. The next version of NumPy will drop support for Python 3.8 as well \(but it will be required for Python 3.12\), so I don’t know for how long I can hold on supporting 3.7 while also supporting newer versions. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2696/update-kuibit-to-…

1 0

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Peter Diener 20 Mar '23

20 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 Peter Diener): NPScalars\_SF does no harm. It compiled out of the box and didn’t cause any tests that passed before to fail. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#1805: triggers statement does not include reductions output
by Roland Haas 20 Mar '23

20 Mar '23

#1805: triggers statement does not include reductions output Reporter: Wolfgang Kastaun Status: new Milestone: Version: ET_2014_05 Type: bug Priority: minor Component: Other Comment (by Roland Haas): I note that computing variables whose reductions are being computed \(for output or otherwise\) only every once in a while and not at every timestep is very firmly in the “[give you rope to hang yourself with, and then some more](https://motd.ambians.com/quotes.php/name/linux_computers/toc_id/1-1-4… territory. Technically should be supported though \(and I thought there are the required `CCTJ_TriggerFoo` calls in `CarpetIOScalar`\). The only way to get away with it somewhat safely is to compute \(and output\) only every coarse step \(if not computing every single step of course\). Everything else stands a danger of using stale / invalid data on past timelevels if and when interpolation in time happens. This also implies \(well mostly\) that the computed quantity must be computable in a pointwise manner, not involving any stencil operations \(to avoid having to restrict and prolongate\) to avoid different results obtained when computing every step and output every coarse or computing and outputting every coarse. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1805/triggers-statemen…

1 0

#2600: `CCTK_CENTERING_GF` is applied to grid scalars
by Roland Haas 20 Mar '23

20 Mar '23

#2600: `CCTK_CENTERING_GF` is applied to grid scalars Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: minor Component: Comment (by Roland Haas): @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} any news on this? Or have you already addressed this in the code and the issue can be closed? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2600/cctk_centering_gf…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac