include Regge-Wheeler-Zerilli gauge self-force code in ET

[Samuel Cupp]

The RWZ self-force code extends Peter Diener’s 1D self-force code to be able to evolve the gravitational self-force in the Regge-Wheeler-Zerilli gauge using master functions. The code is currently capable of handling circular orbits and will be extended to eccentric orbits and inspirals in the future.

It also includes observers for metric reconstruction, energy and angular momentum flux, and strain output.

The pull request for the new code can be found at https://bitbucket.org/peterdiener/selfforce-1d/pull-requests/2.

[Roland Haas]

Is there a volunteer to review it?

[Roland Haas]

@Peter Diener will review.

[Roland Haas]

Draft review guidelines are at https://docs.einsteintoolkit.org/et-docs/How_to_Review_a_new_component

[Roland Haas]

@Samuel Cupp has there been progress on this?

[Samuel Cupp]

I’ve mentioned the review to @Peter Diener 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.

[Roland Haas]

@Peter Diener confirms “no harm” in http://lists.einsteintoolkit.org/pipermail/users/2022-August/008670.html

[Roland Haas]

@Samuel Cupp now that Peter has given the “no harm” go ahead, please integrate the code into the “master” branch or otherwise provide updated checkout information so that the RWZM version can be tested and downloaded by interested parties.

[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.

[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.

[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.

[Samuel Cupp]

Tests were added, along with errors (with messages) for invalid choices of lmin and lmax.

[Roland Haas]

@Peter Diener could you state (for the record) that the review concluded, please?

[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.

[Samuel Cupp]

This was merged in and included in the 2022_11 release, but never resolved.