Trac August 2022

trac@lists.einsteintoolkit.org

1 participants
121 discussions

#2549: inlcude FLRWSolver in ET
by Zach Etienne 25 Aug '22

25 Aug '22

#2549: inlcude FLRWSolver in ET Reporter: Roland Haas Status: new Milestone: ET_2022_05 Version: development version Type: enhancement Priority: major Component: Comment (by Zach Etienne): Comment 1: I _really_ like `README.Compilation` as it contains some useful “gotchas” that folks often run into when trying to compile the Toolkit more generally. For example: ``` --> Generally, if you have a nontrivial error with a particular thorn, first try removing that thorn from the thornlist and re-compile. The code will complain if other thorns on your thornlist depend on the thorn you have just removed. You can also remove some of these if they are not important. If it turns out a thorn you really need has a dependency on that thorn, ONLY THEN spend the time debugging. ``` I feel like the contents of this file would make an excellent contribution to a wiki page. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

#2549: inlcude FLRWSolver in ET
by Zach Etienne 25 Aug '22

25 Aug '22

#2549: inlcude FLRWSolver in ET Reporter: Roland Haas Status: new Milestone: ET_2022_05 Version: development version Type: enhancement Priority: major Component: Comment (by Zach Etienne): Issue 5: I’m a bit confused as to why `check_metric()` is `something that we do at the end of each initial data routine`. All it does is: ``` if (CCTK_EQUALS (metric_type, "physical")) then ! do nothing else call CCTK_WARN (0, "Unknown value of ADMBase::metric_type -- FLRW only set-up for metric_type = physical") endif ``` This parameter cannot change while `FLRWSolver` is being run, or at all after the parfile is read in, so it only needs to be checked once. In fact I think there’s a scheduling bin for it: `ParamCheck`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

#2549: inlcude FLRWSolver in ET
by Zach Etienne 25 Aug '22

25 Aug '22

#2549: inlcude FLRWSolver in ET Reporter: Roland Haas Status: new Milestone: ET_2022_05 Version: development version Type: enhancement Priority: major Component: Comment (by Zach Etienne): Issue 4: `doc/cactus.sty` should be removed. I understand that this is a convenient location for the file when running e.g., `pdflatex documentation.tex` from within the `doc` directory, but this file already exists in the Toolkit in a standard place that is looked at when e.g., `make AllDoc` is run. It's best that this remains the situation in case we'd like to update the style file. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

#2549: inlcude FLRWSolver in ET
by Zach Etienne 25 Aug '22

25 Aug '22

#2549: inlcude FLRWSolver in ET Reporter: Roland Haas Status: new Milestone: ET_2022_05 Version: development version Type: enhancement Priority: major Component: Comment (by Zach Etienne): Issue 3: The `test/` directory contains a parameter file and sample output data, which has no problem running and seems to use little resources. Great work! What’s missing is the required `test.ccl` file that sets acceptable tolerances when running this thorn through our unit testing infrastructure. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

#2549: inlcude FLRWSolver in ET
by Zach Etienne 25 Aug '22

25 Aug '22

#2549: inlcude FLRWSolver in ET Reporter: Roland Haas Status: new Milestone: ET_2022_05 Version: development version Type: enhancement Priority: major Component: Comment (by Zach Etienne): Issue 2: Compiler warning needs to be resolved \(looks scary\): `src/powerspec_ics.F90:16: Warning: While tracing include dependencies: Include file "fftw3.f03" not found` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

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

25 Aug '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): > Is there information about external force as document ? I can not find it. As far as I see, there is no documentation at all inside the thorn, not just regarding the external forcing. The only document is the paper mentioned in the README. Should we add a short latex doc describing the general purpose of the whole arrangement? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2635: Remove warning in GRHydro_InitData
by Zach Etienne 25 Aug '22

25 Aug '22

#2635: Remove warning in GRHydro_InitData Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: An unusual warning popped up when trying to compile `GRHydro_InitData` a little while ago: `GRHydro_InitData/src/GRHydro_PoloidalMagFieldM.F90:110:2: warning: #warning "This algorithm does only work on Cartesian grids!!"` The assumption of Cartesian grids is so ingrained in Toolkit thorns that if we were consistent in this warning, most of the output from the compiler would be this warning. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2635/remove-warning-in…

1 0

#2549: inlcude FLRWSolver in ET
by Zach Etienne 25 Aug '22

25 Aug '22

#2549: inlcude FLRWSolver in ET Reporter: Roland Haas Status: new Milestone: ET_2022_05 Version: development version Type: enhancement Priority: major Component: Comment (by Zach Etienne): I’ll add comments as I have time. First off, initial data thorns should depend on \*Base thorns, and not any particular evolution thorn. I’m referring to ``` shares:GRHydro USES real rho_abs_min USES real rho_rel_min USES REAL initial_rho_abs_min USES REAL initial_rho_rel_min USES REAL initial_atmosphere_factor USES real GRHydro_rho_central ``` within `param.ccl` . It should be the initial data thorn’s responsibility to set up the atmosphere and set parameters accordingly. For me, the solver wouldn’t even get to the compile stage because I generally comment out `GRHydro` from my `ThornList` \(naturally I use `IllinoisGRMHD`\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

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

25 Aug '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): > In line 16th in param.ccl in ScalarBase, we should add absolute value for phi. I don’t quite understand this comment. Line 16th in ScalarBase/param.ccl is a comment about the definition of a potential depending on the square of the scalar field. Why do we need to include the absolute value? -- 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 25 Aug '22

25 Aug '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): > The description of parameters lEF and mEF in param.ccl is misleading. Current version supports only \(lEF,mEF\)=\(0,0\), \(1,1\), \(2,2\) and not \(1,0\),\(2,0\), \(2,1\). \(see 68th line in Scalar\_rhs\_forcing.F90\) fixed in [https://bitbucket.org/canuda/scalar/commits/2edee1a8386be2d7bee58c457c330ce… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

← Newer
1
2
3
4
5
6
7
...
13
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2022