Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2485: include complex and real scalar evolution code from Canuda in ET
by Giuseppe Ficarra 05 Sep '22

05 Sep '22

#2485: include complex and real scalar evolution code from Canuda in ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: Comment (by Giuseppe Ficarra): ScalarEvolve: > In current version, in Scalar\_calc\_Tmunu, "compute\_fluxes==1" and "use\_jacobian=false" is not available....Should we add the comments in param file ? Do you mean “use\_jacobian = true“? If you have a look at line 254 of Scalar\_calc\_Tmunu.F90, you can see that there is an if statement that uses the combination "compute\_fluxes==1" and "use\_jacobian=false". > in schedule, flux grid function is allocated, and Scalar\_zero\_densities is called when compute\_fluxes is true. But, in Scalar\_zero\_densities, flux grid functions are initialized only when use\_jacobian is false. So, if compute\_fluxes is true and use\_jacobian is true, flux grid function is not initialized. fixed in [https://bitbucket.org/canuda/scalar/commits/cb03ec3b4d1bd2e32787ffbf2d32f4d… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2485: include complex and real scalar evolution code from Canuda in ET
by Giuseppe Ficarra 02 Sep '22

02 Sep '22

#2485: include complex and real scalar evolution code from Canuda in ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: Comment (by Giuseppe Ficarra): added test parameter files in [https://bitbucket.org/canuda/scalar/commits/87e99ae9163e3125f5a3165562beb05… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2629: MoL_PseudoEvolution vs ANALYSIS
by Gabriele Bozzola 01 Sep '22

01 Sep '22

#2629: MoL_PseudoEvolution vs ANALYSIS Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Gabriele Bozzola): Upon further reflection, and reading more carefully the previous message, my impression is that there’s no easy way to implement a `compute_every` function. I originally implemented the function following `WeylScal4`, which simply takes the modulo of the current iteration and the `compute_every` parameter. But, if I understand what is going on, this is not the correct thing to do, as I can see in my test runs \(unless `compute_every` is 1\). So, should `compute_every` be removed from the `canuda` codes and `WeylScal4` ? \(Or at least, forced to be 1 for backwards compatibility\) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2629/mol_pseudoevoluti…

1 0

#2629: MoL_PseudoEvolution vs ANALYSIS
by Gabriele Bozzola 01 Sep '22

01 Sep '22

#2629: MoL_PseudoEvolution vs ANALYSIS Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Gabriele Bozzola): It runs, but I am not sure it produces the correct results, so the PRs shouldn’t be merged at the moment. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2629/mol_pseudoevoluti…

1 0

#2485: include complex and real scalar evolution code from Canuda in ET
by Miguel Zilhão 01 Sep '22

01 Sep '22

#2485: include complex and real scalar evolution code from Canuda in ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: Comment (by Miguel Zilhão): ‌ > Also, Rout\_excision1, Rout\_excision2, Rin\_excision1, Rin\_excision2 can be outside grid loop ? fixed in [https://bitbucket.org/canuda/scalar/commits/f0e3b8f2d7c7d943f8002d1f7294404… ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2629: MoL_PseudoEvolution vs ANALYSIS
by Gabriele Bozzola 31 Aug '22

31 Aug '22

#2629: MoL_PseudoEvolution vs ANALYSIS Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Gabriele Bozzola): I guess the solution is to leave it up to the user to make sure the they set the correct value for “compute\_every”. Here’s two PR: [https://bitbucket.org/canuda/lean\_public/pull-requests/6/address-2629-amon… [https://bitbucket.org/canuda/proca/pull-requests/5/npscalars\_proca-compute… Everything compiles and runs. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2629/mol_pseudoevoluti…

1 0

#2629: MoL_PseudoEvolution vs ANALYSIS
by Roland Haas 30 Aug '22

30 Aug '22

#2629: MoL_PseudoEvolution vs ANALYSIS Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): In the call I said I knew how to do the scheduling in MoL\_PseudoEvolution. Turns out that this is not true. Here’s my current thoughts: ```text rl=0 delta_t=4.0 timefac=1 rl=1 delta_t=2.0 timefac=2 rl=2 delta_t=1.0 timefac=4 it == 0: rl=0 t_of_level=0.0 rl=1 t_of_level=0.0 rl=2 t_of_level=0.0 it == 1: rl=0 t_of_level=4.0 rl=1 t_of_level=2.0 rl=2 t_of_level=1.0 it == 2: rl=2 t_of_level=2.0 it == 3: rl=1 t_of_level=4.0 rl=2 t_of_level=3.0 it == 4: rl=2 t_of_level=4.0 if wanting to compute every Delta_t = 4.0 which is every 4 iterations, need to evaluate at: it = 0 for rl=0,1,2 and it = 1 for rl=0 it = 3 for rl=1 it = 4 for rl=2 ``` and I am not sure to to come up with an expression that involves only `iteration`, `timefac` and the `every` value that would give those iterations \(ie not referring to the unknown maximum `timefac` value in the simulation\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2629/mol_pseudoevoluti…

1 0

#2635: Remove warning in GRHydro_InitData
by Roland Haas 30 Aug '22

30 Aug '22

#2635: Remove warning in GRHydro_InitData Reporter: Zach Etienne Status: resolved Milestone: Version: Type: bug Priority: major Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2635/remove-warning-in…

1 0

#2635: Remove warning in GRHydro_InitData
by Roland Haas 30 Aug '22

30 Aug '22

#2635: Remove warning in GRHydro_InitData Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Fixed in git hash [8e3dda4](https://bitbucket.org/einsteintoolkit/einsteinevolve/commits/8e3dd… "GRHydro\_InitData: check for curvilinear grid at runtime" of [einsteinevolve](https://bitbucket.org/einsteintoolkit/einsteinevolve) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2635/remove-warning-in…

1 0

#2637: update Cactus COPYRIGHT file to LGPL
by Roland Haas 30 Aug '22

30 Aug '22

#2637: update Cactus COPYRIGHT file to LGPL Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Cactus Cactus originally used GPL with a spelled out exception that linking is exempt from the GPL copyleft, ie the same exception that LGPL used. Some time ago \(around 2015, see eg commit logs in cactus\* repos\) we switched to explicitly using LGPL and updated the README files. Cactus itself however was forgotten \(has no README file, but has COPYRIGHT\). Pull request [https://bitbucket.org/cactuscode/cactus/pull-requests/144](https://bitbucke… addresses this. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2637/update-cactus-cop…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac