Trac

trac@lists.einsteintoolkit.org

8708 discussions

#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

#2634: CCTK_BUILTIN_EXPECT is not documented
by Swapnil Shankar 23 Aug '22

23 Aug '22

#2634: CCTK_BUILTIN_EXPECT is not documented Reporter: Swapnil Shankar Status: new Milestone: Version: Type: enhancement Priority: minor Component: CCTK\_BUILTIN\_EXPECT is not documented in Cactus Reference Manual or Cactus Users' Guide. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2634/cctk_builtin_expe…

1 0

#2633: SummationByPart's Diff_gv aliased function does ont document which part of the grid the computed derivative is valid
by Roland Haas 19 Aug '22

19 Aug '22

#2633: SummationByPart's Diff_gv aliased function does ont document which part of the grid the computed derivative is valid Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Changes (by Roland Haas): responsible: [] (was ) assignee: Peter Diener (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2633/summationbyparts-…

1 0

#2633: SummationByPart's Diff_gv aliased function does ont document which part of the grid the computed derivative is valid
by Roland Haas 19 Aug '22

19 Aug '22

#2633: SummationByPart's Diff_gv aliased function does ont document which part of the grid the computed derivative is valid Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Looking at the code in SummationByParts ```fortran case (0) direction if ( bb(1) == 0 ) then il = 1 + gsize else ol = offset(1) !$omp parallel workshare dvar(1+ol,:,:) = ( q(1,1) * var(1+ol,:,:) + q(2,1) * var(2+ol,:,:) ) * idel dvar(2+ol,:,:) = ( q(1,2) * var(1+ol,:,:) + q(3,2) * var(3+ol,:,:) ) * idel !$omp end parallel workshare il = 3 + ol end if ``` seems to indicate that for non-boundary ends of a grid component $`bb == 0`$ derivatives are computed only in the interior $from `il = 1+gsize`$ while for boundary ends some $larger$ area is valid. This does not seem to be documented though, at least I could not find it in either documentation.tex nor interface.ccl. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2633/summationbyparts-…

1 0

#2632: SummationByPart assumes `cctk_lsh == cctk_ash`
by Roland Haas 19 Aug '22

19 Aug '22

#2632: SummationByPart assumes `cctk_lsh == cctk_ash` Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: SummationByParts sets `ni = cctk_lsh[0]` but then uses this $in Fortran code$ to size the array in memory: ```fortran CCTK_REAL, dimension(ni,nj,nk), intent(IN) :: var ``` which will fail when `cctk_lsh != cctk_ash` that is when padding is used. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2632/summationbypart-a…

1 0

#2631: Meudon_BinNS fails if initial_dtshift or initial_dtlapse is set to an unexpected value
by Roland Haas 19 Aug '22

19 Aug '22

#2631: Meudon_BinNS fails if initial_dtshift or initial_dtlapse is set to an unexpected value Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): There’s also a bug in that setting `dtalp` requires computing spatial derivatives $via SummationByParts `Diff_Gv` aliased function$ so that it can only be computed in the interior, but no SYNC or boundary condition is applied. The easiest fix to this $since boundary conditions applied to initial data are tricky$ would likely be to compute `alp` on a grid larger than the Cactus grid so that `dx_alp` can be computed on the whole Cactus grid. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2631/meudon_binns-fail…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac