Hello all,
I am wondering if it is possible to take initial data for a single (maybe spinning) black whole in Kerr-Schild coordinates as provided by Exact or EinsteinExact (metric, curvature, lapse, shift, time derivatives of lapse and shift) and chose parameters for the "usual" 1+log and Gamma driver gauge evolution conditions so that this data is a stationary solution of the evolution equations?
Yours, Roland
Roland
This is almost possible. For puncture data, one typically evolves lapse, shift, and a quantity B (the time derivative of the shift). For Kerr-Schild data, one also needs to evolve A, the time derivative of the lapse. Otherwise, Kerr-Schild data are not stationary. (One could instead add an offset alpha_0 to the evolution equations for K, but that is quite non-standard and not implemented in McLachlan.)
Additionally, I find it convenient to smooth all quantities near the singularity, and to choose to advect both lapse and shift. I don't know whether the latter is necessary in theory, but I am always using it.
I can send a sample parameter file if that helps.
-erik
On Thu, Apr 25, 2019 at 10:38 AM Haas, Roland rhaas@illinois.edu wrote:
Hello all,
I am wondering if it is possible to take initial data for a single (maybe spinning) black whole in Kerr-Schild coordinates as provided by Exact or EinsteinExact (metric, curvature, lapse, shift, time derivatives of lapse and shift) and chose parameters for the "usual" 1+log and Gamma driver gauge evolution conditions so that this data is a stationary solution of the evolution equations?
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu . _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello Erik,
This is almost possible. For puncture data, one typically evolves lapse, shift, and a quantity B (the time derivative of the shift). For Kerr-Schild data, one also needs to evolve A, the time derivative of the lapse. Otherwise, Kerr-Schild data are not stationary. (One could instead add an offset alpha_0 to the evolution equations for K, but that is quite non-standard and not implemented in McLachlan.)
Ok so it is possible.
Additionally, I find it convenient to smooth all quantities near the singularity, and to choose to advect both lapse and shift. I don't know whether the latter is necessary in theory, but I am always using it.
Concerning the smoothing it seems that some smoothing was necessary to not crash the code (via the Exact epsilon parameter to transform r -> r+epsilon). An alternative may have been to use NoExcision to fill the interior of the AH with smooth data.
I can send a sample parameter file if that helps.
That would be great if you had something that you could send around easily.
Yours, Roland
Hi Roland,
Additionally, I find it convenient to smooth all quantities near the
singularity, and to choose to advect both lapse and shift. I don't know whether the latter is necessary in theory, but I am always using it.
Concerning the smoothing it seems that some smoothing was necessary to not crash the code (via the Exact epsilon parameter to transform r -> r+epsilon). An alternative may have been to use NoExcision to fill the interior of the AH with smooth data.
I generally suggest shifting the grid so that the closest gridpoint to the origin is (dx/2, dy/2, dz/2), where dx,dy,dz are the resolutions on the finest grid. I've used this trick many times to stabilize evolutions. Also you may want to try the ShiftedKerrSchild thorn (in the ETK), which enables a radial offset that shrinks the BH coordinate size but at the same time kills off enormous constraint violations near r=0. Unlike the existing KerrSchild thorn(s), this one uses the standard Kerr-Schild metric written in spherical coordinates and does the basis xform.
-Zach
* * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University *https://math.wvu.edu/~zetienne/ https://math.wvu.edu/~zetienne/* https://blackholesathome.net
On Thu, Apr 25, 2019 at 12:30 PM Haas, Roland rhaas@illinois.edu wrote:
Hello Erik,
This is almost possible. For puncture data, one typically evolves lapse, shift, and a quantity B (the time derivative of the shift). For Kerr-Schild data, one also needs to evolve A, the time derivative of the lapse. Otherwise, Kerr-Schild data are not stationary. (One could instead add an offset alpha_0 to the evolution equations for K, but that is quite non-standard and not implemented in McLachlan.)
Ok so it is possible.
Additionally, I find it convenient to smooth all quantities near the singularity, and to choose to advect both lapse and shift. I don't know whether the latter is necessary in theory, but I am always using it.
Concerning the smoothing it seems that some smoothing was necessary to not crash the code (via the Exact epsilon parameter to transform r -> r+epsilon). An alternative may have been to use NoExcision to fill the interior of the AH with smooth data.
I can send a sample parameter file if that helps.
That would be great if you had something that you could send around easily.
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu . _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello Zach,
I generally suggest shifting the grid so that the closest gridpoint to the origin is (dx/2, dy/2, dz/2), where dx,dy,dz are the resolutions on the finest grid. I've used this trick many times to stabilize evolutions. Also you may want to try the ShiftedKerrSchild thorn (in the ETK), which enables a radial offset that shrinks the BH coordinate size but at the same time kills off enormous constraint violations near r=0. Unlike the existing KerrSchild thorn(s), this one uses the standard Kerr-Schild metric written in spherical coordinates and does the basis xform.
Right, I had completely forgotten about that one. Thank you. So ShifterKerrSchild is actually different from Exact with its Kerr_KerrSchild__epsilon parameter (ie it would do proper coordinate transformation r -> r+r0 rather than just add r0 in some of the 1/r terms)?
Note that the goal is use it only as ID and not to reset the metric at each time so I will have to modify ShifterKerrSchild a bit.
Yours, Roland
Roland
Here is an old parameter file that I'm sure used to work at some point. I think we cleaned up McLachlan parameters a few years ago, so this parameter file might output warnings or errors (with suggestions for correcting them, if all goes as intended).
-erik
On Thu, Apr 25, 2019 at 12:57 PM Haas, Roland rhaas@illinois.edu wrote:
Hello Zach,
I generally suggest shifting the grid so that the closest gridpoint to the origin is (dx/2, dy/2, dz/2), where dx,dy,dz are the resolutions on the finest grid. I've used this trick many times to stabilize evolutions. Also you may want to try the ShiftedKerrSchild thorn (in the ETK), which enables a radial offset that shrinks the BH coordinate size but at the same time kills off enormous constraint violations near r=0. Unlike the existing KerrSchild thorn(s), this one uses the standard Kerr-Schild metric written in spherical coordinates and does the basis xform.
Right, I had completely forgotten about that one. Thank you. So ShifterKerrSchild is actually different from Exact with its Kerr_KerrSchild__epsilon parameter (ie it would do proper coordinate transformation r -> r+r0 rather than just add r0 in some of the 1/r terms)?
Note that the goal is use it only as ID and not to reset the metric at each time so I will have to modify ShifterKerrSchild a bit.
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .
Hi Roland,
I generally suggest shifting the grid so that the closest gridpoint
to the origin is (dx/2, dy/2, dz/2), where dx,dy,dz are the resolutions on the finest grid. I've used this trick many times to stabilize evolutions. Also you may want to try the ShiftedKerrSchild thorn (in the ETK), which enables a radial offset that shrinks the BH coordinate size but at the same time kills off enormous constraint violations near r=0. Unlike the existing KerrSchild thorn(s), this one uses the standard Kerr-Schild metric written in spherical coordinates and does the basis xform.
Right, I had completely forgotten about that one. Thank you. So ShifterKerrSchild is actually different from Exact with its Kerr_KerrSchild__epsilon parameter (ie it would do proper coordinate transformation r -> r+r0 rather than just add r0 in some of the 1/r terms)?
KerrSchild_radial_shift sets r0.
For more documentation, my Master's student George Vopal developed as part of his Master's research project a couple of interactive NRPy+ tutorial modules on the shifted Kerr-Schild solution (even confirming constraint convergence to zero in a standalone code): Basic equations (takes a minute to load): https://mybinder.org/v2/gh/zachetienne/nrpytutorial/master?filepath=Tutorial... Numerical validation (takes a minute to load): https://mybinder.org/v2/gh/zachetienne/nrpytutorial/master?filepath=Tutorial...
Note that the goal is use it only as ID and not to reset the metric at each time so I will have to modify ShifterKerrSchild a bit.
Should be a pretty simple change.
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Haas, Roland -
Zach Etienne