Trac

trac@lists.einsteintoolkit.org

8708 discussions

#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

#2602: include Regge-Wheeler-Zerilli gauge self-force code in ET
by Samuel Cupp 10 Aug '22

10 Aug '22

#2602: include Regge-Wheeler-Zerilli gauge self-force code in ET Reporter: Samuel Cupp Status: new Milestone: ET_2022_05 Version: development version Type: enhancement Priority: major Component: Other Comment (by Samuel Cupp): I’ve mentioned the review to @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} in recent calls, but I don’t know where he’s at with the review currently. I’m traveling during our usual call time this week, but hopefully he can reply here and give us an update. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2602/include-regge-whe…

1 0

#2616: Add NRPyEllipticET to the Einstein Toolkit
by Zach Etienne 10 Aug '22

10 Aug '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Zach Etienne): I don’t think this “new” functionality qualifies as “bleeding edge”, as it was hashed out in the publication. It’s basically an empirically derived means to set a more optimal value for the damping parameter. Also I believe “soon” means “within a few days”. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2616/add-nrpyelliptice…

1 0

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

10 Aug '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): “Soon” is a vague statement. Note that the initial review of harmlessness must finish before 2022-09-01 for NrPyElliptic to be included. The reviewers will also require some time to review which the proposers should provide them with. Also note that major changes to the code may pose an issue wrt to stating that the code that is being reviewed is actually the one used in a prior publication \(ie code quality may actually go down due to newly introduced bugs and loss of correctness compared to the code used in publication\). Usually the ET does not include “bleeding edge” components but components that have proven to themselves already in real world applications \(ie used in a scientirfic publication\) and it may be desirable to postpone inclusion if that is still to be seen \(without passing judgement on the component of course\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2616/add-nrpyelliptice…

1 0

#2616: Add NRPyEllipticET to the Einstein Toolkit
by Leonardo Werneck 10 Aug '22

10 Aug '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Leonardo Werneck): Hi @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} ! Yes, I’ve already completed most of the major changes we were planning for the thorn. I’m working with Thiago Assumpção \(lead developer of NRPyElliptic\) to add an extra functionality to the thorn where the damping parameter of the hyperbolic system is computed automatically, yielding optimized relaxations for all grid resolutions \(unless the user chooses to override it\). This should be complete soon, at which point we will be in touch with the reviewers. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2616/add-nrpyelliptice…

1 0

#2616: Add NRPyEllipticET to the Einstein Toolkit
by Zach Etienne 10 Aug '22

10 Aug '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Zach Etienne): @{6228f1ddb7e7c700715a7695} has an update. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2616/add-nrpyelliptice…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac