Trac September 2022

trac@lists.einsteintoolkit.org

1 participants
67 discussions

#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

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

08 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): Ok, so I think we are done, but let me know if you need me to do anything else. -- 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 Taishi Ikeda 08 Sep '22

08 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 Taishi Ikeda): I do not know there is an available Mathematica code for it. But. then, we can forget my this comment. Now, I am thinking the calculations of eigen frequency is user’s responsibility…. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2616: Add NRPyEllipticET to the Einstein Toolkit
by Cheng-Hsin Cheng 07 Sep '22

07 Sep '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Cheng-Hsin Cheng): Hi all, I finished checking NRPyEllipticET and I have some questions and comments about the code. To keep it brief I am leaving out the “conformally\_flat\_BBH” when referring to the file names in the src folder. --- In NRPyEllipticET folder * Please add a `README` in the Cactus format with the author, maintainer, license, and brief description. * `interface.ccl` * `uuGF`: Please add a description for it. Although it might be familiar for someone who has used TwoPunctures, a new user might not know what is the purpose of it. * `param.ccl`: * `info_output_freq`: I think a better description would be e.g. "Print progress of relaxation time evolution every info\_output\_freq iterations" * `N2`: allows a "forbidden value" of -1 to make sure it is set explicitly in the parfile, but the default is set to 16 rather than -1. Was the value of -1 to be removed \(since N0 and N1 don't have a forbidden value like N2\)? * `initialize_offdiagonal_metric_to_zero`: This looks to be unused in the code. Should it be removed from the param.ccl? --- C source files * `Hyberbolic_Relaxation.c` * Using CCTK\_ERROR \(or CCTK\_INFO\) to error out might be preferable to using printf and calling exit\(1\). * Instead of hard-coding the value for integration\_radius, could you add it as a thorn parameter? * `conformally_flat_BBH_driver_bcstruct.c` * Line 23: It took me a while to understand what the comment meant. I think it might be clearer to rewrite as "in the case that a boundary point is..." * Lines 59-61 are commented out. I don't know if `set_bcstruct` handles grids without the outer boundary, but if it doesn't, should this be left uncommented? * `set_bcstruct.c` * I really like how at the top there is a brief outline of the routine's \(in addition to the comments within the body\). It could be useful to add them for other longer routines, e.g. `Hyperbolic_Relaxation()` or `InitializeADMBase()` * `find_timestep.c` * The argument "CFL\_FACTOR" isn't used in the function, moreover the variable is already defined in param.ccl, so is this required or can it be removed? * `wavespeed_gf_all_points.c` * There is duplicate code from `find_timestep.c` to compute ds\_dirn0, ds\_dir1, ds\_dir2. Is it possible to implement this only once, e.g. write a separate function to compute min\(ds\_dirn0, ds\_dir1, ds\_dir2\) for a single grid point, and then call it from both `find_timestep.c` and `wavespeed_gf_all_points.c`? * `residual_all_points.c` * The variables "f0\_of\_xx0" and so on are used in computing the residual, but they are defined with "\_\_attribute\_\_ \(\(unused\)\)" in the headers in "rfm\_files". * `L2_norm_of_gf.c` * What is the radius "r"? Could it be possible \(and would it be a problem\) for the extent of r to be under integration\_radius, so that the integration is not performed over the whole the radius? * Files in the folder `conformally_flat_BBH/rfm_files/` * What is the purpose of the empty files with names ending in “read2”? * Unused files: Should they be left out of the thorn? * `apply_bcs_curvilinear_radiation.c` * `set_Cparameters-nopointer.h` * `set_Cparameters-SIMD.h` * `xx_to_Cart.c` ‌ -- 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 Giuseppe Ficarra 07 Sep '22

07 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): Do you know how can I create such a list? Is there any Mathematica package that computes the eigenfrequencies? If this doesn’t take too much, I can try to make the list. Besides, the routine only implements the l = m = 1 mode, so this would only loop on the spin values. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

#2549: inlcude FLRWSolver in ET
by Hayley Macpherson 07 Sep '22

07 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 Hayley Macpherson): Chi - thanks for your review! I’ve addressed your comments, see below: 1\. Thanks for this, you’re right there was a minus sign missing which I’ve now fixed 2\. I’ve changed the name of this variable from kvalue → kdiag\_bg, since it represents the diagonal value of the extrinsic curvature K\_ij for the background \(not the trace\) 3\. Yes, you are correct that this choice of gauge means that for the background we have alpha → a and therefore coordinate time can be more or less interpreted as conformal time. I don’t think this choice of evolving lapse will give numerical errors \(which I don’t see, as far as I can tell\), because the actual time evolution is dependent on the time step in terms of coordinate time, dt, which is set via the grid spacing and the chosen Courant factor. This time step does not change as the lapse evolves, and I don’t think the lapse will have an impact here. I could be wrong, so @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} please correct me if so! Thanks again for your time and for helping with this on such short notice! -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

#2549: inlcude FLRWSolver in ET
by Hayley Macpherson 07 Sep '22

07 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 Hayley Macpherson): @{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} thanks for your review! I have addressed all of the issues and comments you have raised, and pushed the changes to the repo. In addition to the changes to address your issues/comments, I have also re-named the source files and routines themselves to be more consistent with ET standards. Here I’ll explain what I’ve done: * Issue 1: removed these statements from param.ccl as they were unused anyway * Issue 2: Roland said he would have a look into this, so I’ll leave this be for now * Issue 3: added a test.ccl file * Issue 4: removed doc/cactus.sty * Issue 5: thanks for this! I’ve made a new routine FLRW\_ParamCheck and scheduled it at ParamCheck as you suggested, and removed this code from the ID routines * Issue 6/Comment 2: I’ve added a comment on the example powerspectrum file in the documentation, and added a new section explaining each of the files in the tools/ directory. * Issue 7: I removed doc/tutorial/ and moved the README.tutorial file to tools/ * Comment 3: I removed configs/ from the public repo and will consider contributing these to simfactory at some point * Issue 8: re-named the test par to FLRW\_singlemode\_test.par since the main differences are the resolution and simplified initial parameters * Issue 9: thanks for pointing this out. I’ve added a call to CCTK\_WARN after checking if the supplied file exists, with a useful error explaining next steps for the user * Issue 10: removed the restart par file from par/ * Issue 11/Comment 4: thanks for this - I realised random.F90 was a lot more complicated than it needed to be. It already uses the intrinsic fortran PRNG, but had some added complexity in generating a seed if it wasn’t given. In FLRWSolver, there will always be a random seed. I removed random.F90 and replaced it with a new, much simpler routine in FLRW\_InitTools which directly calls the Fortran intrinsic PRNG and casts this into random numbers following a normal distribution * Issue 12: Mescaline is my private post-processing code, so I’ve removed this comment Thanks again for your help and effort on this! Let me know if there’s anything else or if you have questions about my changes. ‌ -- 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 Taishi Ikeda 05 Sep '22

05 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 Taishi Ikeda): > I agree with this comment, but in param.ccl there is a reference value for wR and wI for a specific case \(dimensionless spin 0.99 and mass parameter 0.42\). Moreover the paper on which the routine is based is cited in the README. My question is: do I need to add an explicit comment inside the source code about this? I think it is not necessary to add comment in the source code. My point is preparing list of the eigenvalue with different spin parameter as separated text file….. But, the calculation of the eigen frequency may be just user’s responsibility. If you think so, please forget my this comment. -- 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 05 Sep '22

05 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, 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. I agree with this comment, but in param.ccl there is a reference value for wR and wI for a specific case \(dimensionless spin 0.99 and mass parameter 0.42\). Moreover the paper on which the routine is based is cited more than once in the README. My question is: do I need to add an explicit comment inside the source code about this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2022