Trac August 2022

trac@lists.einsteintoolkit.org

1 participants
121 discussions

#2630: WaveMoL example computes energy from unsynchronized grid variables
by Roland Haas 16 Aug '22

16 Aug '22

#2630: WaveMoL example computes energy from unsynchronized grid variables Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: The WaveMoL example in CactusExamples computes the wave energy as `E = phi_t**2 + phi_i*phi_i` over the whole grid. However it does so on `MoL_PostStep` and ends up doing so before it applies boundary conditions and `SYNC` to the evolved variables \(`phi`, `phi_t` and `phi_i`\). Pull request [https://bitbucket.org/cactuscode/cactusexamples/pull-requests/3/wavemol-com… addresses this. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2630/wavemol-example-c…

1 0

#2549: inlcude FLRWSolver in ET
by Roland Haas 15 Aug '22

15 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 Roland Haas): Chi Tian agreed to provide science level input if needed. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

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

12 Aug '22

#2629: MoL_PseudoEvolution vs ANALYSIS Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: Changes (by Gabriele Bozzola): Consider a thorn like `NPScalars` in the canuda arrangement. `NPScalars` computes the Newman-Penrose grid functions in the `CCTK_ANALYSIS` bin. The operation requires taking derivatives. Similarly, `LeanBSSNMoL` computes the constraints in the same bin \(this will likely be a regression I introduced in commit 80b6b1b\). My understanding is now that `CCTK_ANALYSIS` is not the right place where to do this because of interpolation/prolongation/notsurewhat. Is the fix to simply replace `CCTK_ANALYSIS` with `MoL_PseudoEvolution`? I would like to make sure that this is the case considering also parameters like `compute_every`. Since these are expensive diagnostics, it is best to compute them only when they are output. Do I get the correct constraints/scalars if I compute and output them only when all the refinement levels are synced? ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2629/mol_pseudoevoluti…

1 0

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

12 Aug '22

#2629: MoL_PseudoEvolution vs ANALYSIS Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: Changes (by Gabriele Bozzola): Consider a thorn like `NPScalars` in the canuda arrangement. `NPScalars` computes the Newman-Penrose grid functions in the `CCTK_ANALYSIS` bin. The operation requires taking derivative. Similarly, `LeanBSSNMoL` computes the constraints in the same bin \(this will likely be a regression I introduced in commit 80b6b1b\). My understanding is now that `CCTK_ANALYSIS` is not the right place where to do this because of interpolation/prolongation/notsurewhat. Is the fix to simply replace `CCTK_ANALYSIS` with `MoL_PseudoEvolution`? I would like to make sure that this is the case considering also parameters like `compute_every`. Since these are expensive diagnostics, it is best to compute them only when they are output. Do I get the correct constraints/scalars if I compute and output them only when all the refinement levels are synced? ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2629/mol_pseudoevoluti…

1 0

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

12 Aug '22

#2629: MoL_PseudoEvolution vs ANALYSIS Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: major Component: Consider a thorn like `NPScalars` in the canuda arrangement. `NPScalars` computes the Newman-Penrose grid functions in the `CCTK_ANALYSIS` bin. The operation requires taking derivative. Similarly, `LeanBSSNMoL` computes the constraints in the same bin \(this will likely be a regression I introduced in commit 80b6b1b\). My understanding is now that `CCTK_ANALYSIS` is not the right place where to do this because of interpolation/prolongation/notsurewhat. Is the fix to simply replace `CCTK_ANALYSIS` with `MoL_PseudoEvolution`? I would like to make sure that this is the considering also parameters like `compute_every`. Since these are expensive diagnostics, it is best to compute them only when they are output. Do I get the correct constraints/scalars if I compute and output them only when all the refinement levels are synced? ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2629/mol_pseudoevoluti…

1 0

#2628: ADMBase, HydroBase, etc should not set up initial data
by Roland Haas 12 Aug '22

12 Aug '22

#2628: ADMBase, HydroBase, etc should not set up initial data Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Roland Haas): Yup, WONTFIX. The \*Base variables also declare the parameters that control what is set as ID an those parameter have to have value. Someone then has to act on that parameter value and it the thorn that introduced the value is \(naturally\) the only one guaranteed to be around. The other issue is that the \*Base thorns not setting ID can lead to situations of not setting ID at all \(namely if no ID thorn is activated\). Really the ID thorns are the ones that must look at the `intiail_foo` parameters and then set their ID. The \*Base thorns already do look at those parameters and only set the data to vacuum / Minkowski if the parameter values tell them to do so. How many timelevels are needed for a variable is actually something that is usually determined by a combination of the evolution thorn, Carpet and the time stepper. Keep in mind that multiple `STORAGE: foo[n]` statements for the same `foo` in mulitple thorns is valid, the largest `n` is what gets used. Namely `STORAGE` allocates _at least_ `n` levels of storage, not _exactly_. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2628/admbase-hydrobase…

1 0

#2628: ADMBase, HydroBase, etc should not set up initial data
by Zach Etienne 12 Aug '22

12 Aug '22

#2628: ADMBase, HydroBase, etc should not set up initial data Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: Just throwing this into the wind, as I’m pretty confident it’ll be marked WONTFIX. But it is a major longstanding annoyance of mine. I love the \*Base thorns, as they enforce consistent interfaces between thorns. And we rightfully brag about this. However, giving them authority to do anything except declare gridfunctions and set the number of timelevels for each is a step too far in my opinion. Setting initial values of \*Base variables should be the purview of thorns that set up initial data, and that’s it. For example, if one wishes to set Minkowski for certain variables, that should be the purview of a Minkowski ID thorn. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2628/admbase-hydrobase…

1 0

#2485: include complex and real scalar evolution code from Canuda in ET
by 池田大志 12 Aug '22

12 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 池田大志): Hi, I checked the thorn, and I have several comments. Now, there is not test case, my comment is only about code now. Since I am checking development branch, the line and file name are based on development branch. --- In ScalarBase, * In line 16th in param.ccl in ScalarBase, we should add absolute value for phi. * 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\) * Is there information about external force as document ? I can not find it. --- In ScalarEvolve, * In ScalarEvolve, why BSSN-like variables are public ? Since same name variables are used in other thorn \(like lean\_public\) and they are just auxiliary field to calculate rhs of the equations, private is better for them. * In Scalar\_calc\_Tmunu.F90, in Scalar\_calc\_Tmunu, xx and rr should be private in OpenMP in grid loop. * 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 ? * In Scalar\_ord4\_calc\_rhs.F90, line 638th and 639th \(def sn1 and sn2\) can be outside grid loop ? or should the excision procedure be separated as independent thorn ? * Also, Rout\_excision1, Rout\_excision2, Rin\_excision1, Rin\_excision2 can be outside grid loop ? * 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. --- In ScalarInit * In ID\_SF\_BS, bh mass assumed to be one ? There is parameter m\_plus, but, it is not used appropriately.... for example, line 40th and 41th. * In ID\_SF\_BS, since wR and wI are free parameters, I recommend to add reference value as list for each spin parameter. Leaver method does not convergence for wR and wI which are not eigenvalue of the boundary value problem. * In schedule, comment in line 51th is wrong. * The description of parameter ampSF is "amplitude of Gaussian wave packet". The parameter is used in "ID\_SF\_calc\_Gaussian.c", but also "ID\_SF\_calc\_Const.c". In second case, the description for the parameter is wrong. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2503: Various small problems with FishboneMoncriefID
by Roland Haas 12 Aug '22

12 Aug '22

#2503: Various small problems with FishboneMoncriefID Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): Any progress on this? I note that Gabriele’s initial point: > The thorn defines `initial_lapse`, `initial_shift`, …, but it ignores all of them. If you activate the thorn, it will always set the initial data. was also brought up during review [https://bitbucket.org/einsteintoolkit/tickets/issues/2286/add-the-fishbone-… and should have been part of the initial inclusion review into the ET. It would be good to address bug reports \(in particular for issues that were already brought up during the inclusion review\) more quickly so that the Einstein Toolkit thorn are properly maintained. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2503/various-small-pro…

1 0

#2616: Add NRPyEllipticET to the Einstein Toolkit
by Roland Haas 11 Aug '22

11 Aug '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): I would be quite worried about having any sort extra functionality \(in particular automatisms\) that has not yet been used in publication in the new contribution. There is the worry that one may end up with a new contribution to the ET that claims to have been used in publication X only for a ET users trying to reproduce X and finding out that this is not possible due to the change. Obviously the would be quite embarrassing. While I trust the NRPyElliptic group to carefully run tests, I wonder why take the risk? Submit the version that was actually used for publication, then add the new functionality in the next release cycle. Also note that potentially giving the reviewers only a single week for the “does no harm” review is really pushing it. They may be out on a conference, vacation or unavailable for other reasons. Note that we had called for new contributions in June already \([https://docs.einsteintoolkit.org/et-docs/Meeting\_agenda#2022-06-02](https://docs.einsteintoolkit.org/et-docs/Meeting_agenda#2022-06-02)\) so starting to adapt the contribution _now_ is somewhat late in my opinion. _Before_ the June call should have been the time for adaptation. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2616/add-nrpyelliptice…

1 0

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2022