Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2602: include Regge-Wheeler-Zerilli gauge self-force code in ET
by Peter Diener 15 Sep '22

15 Sep '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 Peter Diener): Samuel has addresses all the comments raised. Now just need to generate the documentation with Ford, but that will not change any code so should be safe to do later. So in essence the review has concluded. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2602/include-regge-whe…

1 0

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

15 Sep '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): Just catching up with things \(for half a day and then I will falling behind again\), I cannot comment on the actual physics. Certainly the description of the Courant factor is correct. There are certainly bits and pieces in the ET that will make assumptions like “lapse is about 1 at large radii” but those are mostly say gravitational wave extraction which is less useful in this situation \(since it also implicitly assumes a Schwarzschild like background for the waves\). Having a large lapse should be fine, if I am not mistaken then eg Zach has a trick to smooth out initial gauge dynamics by temporarily setting a very large lapse even for black hole simulations \(though likely only near the black holes\). Anyway, the existing codes in the ET should \(fingers crossed\) all handle 0 < lapse < infty at least in cases where this makes sense. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

#2616: Add NRPyEllipticET to the Einstein Toolkit
by Roland Haas 15 Sep '22

15 Sep '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): @Cheng-Hsin Cheng, @Guiseppe Ficarra could you confirm, for the record, that the review concluded? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2616/add-nrpyelliptice…

1 0

#2485: include complex and real scalar evolution code from Canuda in ET
by Roland Haas 15 Sep '22

15 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 Roland Haas): @Taishi Ikeda could you confirm for the record that the review concluded? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2602: include Regge-Wheeler-Zerilli gauge self-force code in ET
by Roland Haas 15 Sep '22

15 Sep '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 Roland Haas): @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} could you state \(for the record\) that the review concluded, please? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2602/include-regge-whe…

1 0

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

14 Sep '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): Tests were added, along with errors \(with messages\) for invalid choices of lmin and lmax. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2602/include-regge-whe…

1 0

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

13 Sep '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’m uncommenting lines 557-580, as some of that code is necessary for the mechanisms that allow for turning on the source smoothly. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2602/include-regge-whe…

1 0

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

13 Sep '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 have pushed changes that address most of these points. I am working on test cases now and am basing them off of the scalar code tests. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2602/include-regge-whe…

1 0

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

10 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): > 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. fixed in [https://bitbucket.org/canuda/scalar/commits/ba88d9fefde4a280f9c10beb9f0fca9… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2602: include Regge-Wheeler-Zerilli gauge self-force code in ET
by Peter Diener 08 Sep '22

08 Sep '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 Peter Diener): I have carefully checked the source code and have the following comments and requests for changes at this time: module\_scalar\_rwz.f90 should be renamed to module\_rwz\_schw.f90 submodule\_scalar\_rwz\_implementation.f90 should be renamed to submodule\_rwz\_schw\_implementation.f90 In module\_scalar\_rwz.f90: Line 16: The ford link \[\[submodule\_scalar\_schw\_implementation.f90\]\] should be changed tp \[\[submodule\_rwz\_schw\_implementation.f90\]\] Line 29: Ford comment should not say scalar field and point charge but rather RWZ metric perturbations and point mass. Line 76: \[\[scal\_schw\_save\_globals\_1\]\] should be \[\[rwz\_schw\_save\_globals\_1\]\] Line 79: \[\[scal\_schw\_save\_globals\_2\]\] should be \[\[rwz\_schw\_save\_globals\_2\]\] Line 82: \[\[scal\_schw\_load\_globals\]\] should be \[\[rwz\_schw\_load\_globals\]\] Line 85: \[\[scal\_schw\_apply\_filter\]\] should be \[\[rwz\_schw\_apply\_filter\]\] Line 87: \[\[scal\_schw\_flux\]\] should be \[\[rwz\_schw\_flux\]\] Line 88: \[\[scal\_schw:flux\]\] should be \[\[rwz\_schw:flux\]\] Lines 93-98: Why 2 functions for outputting coordinates for initial data codes? Line 133: \[\[scal\_schw\]\] should be \[\[rwz\_schw\]\] Line 141: \[\[scal\_schw\]\] should be \[\[rwz\_schw\]\] Line 149: \[\[scal\_schw\]\] should be \[\[rwz\_schw\]\] Line 157: \[\[scal\_schw\]\] should be \[\[rwz\_schw\]\] Line 164: \[\[scal\_schw\_flux\]\] should be \[\[rwz\_schw\_flux\]\] Line 165: \[\[scal\_schw:flux\]\] should be \[\[rwz\_schw:flux\]\] Line 177-192: Again, as above, we two versions of the routine to write out coordinates for the initial data code. In submodule\_scalar\_rwz\_implementation.f90: Line 52: The allocation of the equation name character variable should be of length 8 rather than 18. Line 325: Why is the code for settinp up an initial Gaussian profile commented out when use\_particle is .false.? Line 352-360: As we currently only have an effective source for circular orbits, the code should abort with an error message if use\_generic\_orbit is .true. Line 403-417: As we currently only have an effective source for circular geodesic orbits, we should comment out these lines and replace it with accel= 0.0\_wp Line 497-506: All of these can be commented out until we can extract the self-force Line 535-548: All of these can be commented out until we can extract the self-force Line 557-580: All of these can be commented out until we can support generic orbits Line 661-662: Use the features of output\_base to get unique file unit numbers instead of using hardcoded 10 and 11. In subsequent lines in the loop use those unique file unit numbers. Line 702-704: Use the features of output\_base to get unique file unit numbers instead of using hardcoded 12. Line 724-725: Use the features of output\_base to get unique file unit numbers instead of using hardcoded 10 and 11. In subsequent lines in the loop use those unique file unit numbers. Line 765-767: Use the features of output\_base to get unique file unit numbers instead of using hardcoded 12. Line 1000-1003: The Ford comment still refers to the scalar case. Please change it to reflect what is done in the RWZ case. Line 1034: The expression does not take lmin into account. Is it not possible to evolve with a non-default lmin value? Does the expression assume lmin=2 In input.f90: This file does not seem to be used. Remove? In Observers/RWZFlux: I would prefer if all subroutine names start with flux\_ instead of flx\_. In Observers/RWZMetric: I would prefer if all subroutine names start with metric\_ instead of met\_. In Observers/RWZStrain: I would prefer if all subroutine names start with strain\_ instead of str\_. ‌ Once the ford comment issues have been fixed, I can then try to generate the documentation for the new routines. Finally, some test cases should be constructed and be added to the Test directory for automatic regression testing. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2602/include-regge-whe…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac