[fixed a couple of links]
Present: Zach E, Bill G, Steve B, Roland H, Beyhan, Peter D, Peter S,
Chris E, Maria H, Alessandro, Erik S, Atul K,
Chair: Zach Minutes: Bill
* next modules proposed for inclusion [ZE]
** ReadInterpolate thorn [RH], https://github.com/rhaas80/ReadInterpolate.git
ReadInterpolate takes 3d data and re-interpolates onto any grid structure you have. Eloisa B uses it. Maybe generic use for it, suggested to list. Repo needs cleaning up...needs example param file and documentation. Takes carpet hdf5 data, input is Cartesian, and output can be Llama. Can interpolate in time, all three time levels. Cannot be terribly efficient with what Cactus wants, but uses multiple processors. Cactus recovery goes level by level, and our HDF5 do not have global indexes so must read whole file. SB-can we add global information? RH-yes, but can also be slow. There is a ticket where this was proposed. Very fragile with large binary blob, binary data blob does violate HDF5, but blob is fast. RH will dig up the ticket. ZE suggests updating the Readme for test cases. RH-look at test cases, par file writes data and other uses it. MH-what kind of interpolators? RH-anything that exists in Cactus can be used, uses its mechanisms. MH-Cauchy characteristic code does not work with Cactus / Carpet; Roland thinks not available. MH-Talking about old inline extraction feature.
** POWER waveform extractor (of its post-summer version)[MH], https://github.com/rhaas80/ReadInterpolate.git
It is a wavefrom extrapolator to Scri+ . In current form not level of quality for ETK, but RH has a summer project that should improve it. To LIGO HDF5 strain at infinity.
** con2prim methods, https://github.com/rhaas80/ReadInterpolate.git and code[RH], https://zenodo.org/record/1213306
Paper by Dan Siegel, Philipp Mosta, Et Al. https://arxiv.org/abs/1712.07538 that look at tabulated EOS and mag fields, and nice repos to download the code. Framework in Python and a C implementation. Idea to wrap it so Cactus can us all that. ZE-The HARM developers are also using this. Big development, no ETK thorn that uses this code. So do we want this as a consortium? They were okay to have this in the ETK.
** [ZE] NRPyPN we use two punctures for initial data in ETK. Looking for low ecc BBH intial data parameter solvers. Wrote one based on literature. Option in Two Punctures that you sepcify the 8 input params and outputs the initial data, P_t and P_r. If close to ecc =0, as close as Post-Newtonian allows. ES-Good enough params or need to iterate? ZE-Paper by Ramos-Buades et al. https://arxiv.org/abs/1810.00036 . They say with one iteration can drop ecc to order 1/10^3 . RH-Good to have the notebook in the utils folder for Two Punctures. ZE-Tedious, but the C version is not too hard and integrate with Two Punctures. RH-Very low eccentricity requires man iterations, a glitch shows that ecc energy goes up. Scheme gives back P_t and P_r. PN in C does iteration zero, but not later ones. RH&ZE-Iteration greater than 1 is not in NRPyPN but RH's student has been doing that. RH-I will reach out to principals and discuss this. Does two orbits and sees what to update, and then re-submits itself, and want ecc < 1e-6 . First bit is all eccentricity reduction. ZE-Found typos in the original paper. dE_GW/dt was very different than other groups use. RH-Recevied their Mathematica notebook, so hopefully better than the paper.
Some links to NRPyPN, Low-eccentricity Post-Newtonian BBH initial data parameters (for Two Punctures): https://nbviewer.jupyter.org/github/zachetienne/nrpytutorial/blob/master/NRP... https://github.com/zachetienne/nrpytutorial/tree/master/NRPyPN (source codes)
**PD-Development for SelfForce1D code, like a checkpoint restart, and other student working on equations for Teukolsky in Kerr S.T.---two REU summer students.
* BBH gallery example [AK, PS] http://einsteintoolkit.org/gallery/bbh/index.html
** These figures are a little unintuitive and confusing in the current order...(more description), we would like to (1) rearrange...and (2) write...do you object to these changes?
Thinks improvements to understandability of the graphs. Newest version and try to make the XY plots, should be quite the same and produce nice views of the horizons. And work for the GW graphics. AK-Looking at the BBH gallery and discussion of order of the Gallery page and thinking about for people starting the first time with these examples. Some graphics use Wizard, some SimulationTools, some with VisIt, and have not be able to duplicate some. Leave the animation as is...cannot regenerate yet. So re-arrange and add text. ES-Would be good to collect the scripts that generate these images. A single "Make" would be nice. RH-Do these changes. ZE&BG-Looks good. BG-Would be nice to also have the steps/scripts for each of the tools generating the graphics in case the user does not have access to them all.
RH-Look at http://einsteintoolkit.org/gallery/bns/scripts.tar.gz
* gfortran 10 failure [RH]
ZE-Major issues with gcc 10. Backport some fixes? RH-Can make everything compile with extra options to the compiler. It now checks Frotran calls and checks it twice, if one is a real array and other integer functions you get an error. It changed the way multiply defined (COMMON) data behave. In C you would use EXTERN parameters. In past, relied that linker would merge these. Options Common and Allow inconsistent parameters. Cannot put them in all the time, All Icon does not exist for all gcc configurations. Can check for this in install. This would be backported into the release. Build instructions, maybe a simfactory patch. Opeiotns only for new versions of gcc. ES-Cactus has known architectures, a flesh file. RH-Not optimistic, used if not setting options in the option list. Simfactory sets options there and known architectures not used (?). ES-It can over=ride it but we do not. Just put in the build instructions. ES-We do run configure and can over-write there. ZE-Do we give a warning about over-writing a compile flag? Is it even possible. ES-Could make a message, but users do not look at warnings, though helps with debugging. RH-Should be in autodection, should we Helpful if others try this out and see if there is another way around this. MacOS because Macports is gcc10 and some use of gcc9. Could be breaking all of MPI with gfortran. ES-Mpich says no work around, use the allow mismatch switch. https://lists.mpich.org/pipermail/discuss/2020-January/005863.html%C2%A0%C2%... (-fallow-argument-mismatch workaround) MH&RH-MAc Homebrew not listed because slow Baikal compile time, but does compile with gcc 9.
ZE-I should look at Baikal so gcc does not get into trouble with optimization turned on. ES-Try gcc -E (or something) and that can be submitted for a bug report to gcc.
** tkt 2403, https://bitbucket.org/einsteintoolkit/tickets/issues/2403
** tkt 2402, https://bitbucket.org/einsteintoolkit/tickets/issues/2402
** mailing list, http://lists.einsteintoolkit.org/pipermail/users/2020-June/007451.html
** gcc 10 porting docs, https://gcc.gnu.org/gcc-10/porting_to.html
ZE-Multipole midpoint has been released, right now goes to trapezoidal rule. Midpoint was not actually a midpoint method. Almost same as each other.
https://www.einsteintoolkit.org/tools/unanswered.php
https://bitbucket.org/einsteintoolkit/tickets/issues?status=open&status=...
https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=o...
Next week: Chair is Peter D. and Minute taker Maria H.
---bill e.g.
On 4 Jun 2020, at 16:39, Bill Gabella <b.gabella@vanderbilt.edumailto:b.gabella@vanderbilt.edu> wrote:
** [ZE] NRPyPN we use two punctures for initial data in ETK. Looking for low ecc BBH intial data parameter solvers. Wrote one based on literature. Option in Two Punctures that you sepcify the 8 input params and outputs the initial data, P_t and P_r. If close to ecc =0, as close as Post-Newtonian allows. ES-Good enough params or need to iterate? ZE-Paper by Ramos-Buades et al. https://arxiv.org/abs/1810.00036 . They say with one iteration can drop ecc to order 1/10^3 . RH-Good to have the notebook in the utils folder for Two Punctures. ZE-Tedious, but the C version is not too hard and integrate with Two Punctures. RH-Very low eccentricity requires man iterations, a glitch shows that ecc energy goes up. Scheme gives back P_t and P_r. PN in C does iteration zero, but not later ones. RH&ZE-Iteration greater than 1 is not in NRPyPN but RH's student has been doing that. RH-I will reach out to principals and discuss this. Does two orbits and sees what to update, and then re-submits itself, and want ecc < 1e-6 . First bit is all eccentricity reduction. ZE-Found typos in the original paper. dE_GW/dt was very different than other groups use. RH-Recevied their Mathematica notebook, so hopefully better than the paper.
Some links to NRPyPN, Low-eccentricity Post-Newtonian BBH initial data parameters (for Two Punctures): https://nbviewer.jupyter.org/github/zachetienne/nrpytutorial/blob/master/NRP... https://github.com/zachetienne/nrpytutorial/tree/master/NRPyPN (source codes)
Hi,
I developed an infrastructure for obtaining low-eccentricity parameters for BBH. It is implemented and freely-available in SimulationTools for Mathematica. See https://bitbucket.org/simulationtools/simulationtools/src/master/Eccentricit.... I haven't used it in a while, but can't think why it wouldn't still work. It lacks documentation - if someone is interested in using it or developing it further, I can see if I can find some time to write up some docs.
You can use it to generate an initial guess from PN (QuasiCircularParametersFromPostNewtonian[{m_, q_, chi1_, chi2_, om_}]) for any aligned-spin case (you can probably use chi_z for precessing cases). This will give you the separation, orbital angular momentum (r * py) and radial linear momentum (px). You then run a simulation with these parameters for a few orbits, and analyse the results. The method uses the time derivative of the radial separation for its eccentricity estimator. You use BinaryEccentricityFromSeparationDerivative, passing it the separation as a function of time (which you can get from ReadBinarySeparation), and a time window in which to measure the eccentricity. You can get a suitable window from EccentricityFitWindow, which calculates it using a simple heuristic from the initial orbital frequency to give two orbits. You can then use ReduceEccentricity with the results of BinaryEccentricityFromSeparationDerivative which gives you updated TwoPunctures parameters.
There are a number of higher level functions designed to fit this into an automated workflow. I was using it with SimFactory 3, which supports the idea of post-simulation scripts and "termination reasons". I had it set up so that when Cactus terminates during an eccentricity reduction run, it would run a script (https://bitbucket.org/simulationtools/simulationtools/src/master/Scripts/Ana...) which would call SimulationTools to estimate the next separation and radial momentum (I chose to keep the angular momentum L fixed, since that corresponds to fixed omega at 0 PN (maybe 1 PN?)). The post-simulation script is https://bitbucket.org/ianhinder/simfactory3/src/master/simfactory/etc/appdb/..., and it has a number of heuristics for what to do in different cases.
There are a lot of parts to this system, but it used to run extremely well, and was fully automated, and was used to produce many production simulations, including the very high spin simulations used in https://arxiv.org/abs/1810.10585, with chi_z = 0.9 and mass ratios up to 5.
It does depend on Mathematica, which is a downside, but if you have Mathematica on your cluster, you should be able to use it. Porting the algorithm and heuristics to run fully in Python would be a really nice thing for someone to do, if they have time!
If you want to use it with simfactory 2 (the ET default), you will probably need to hack your run script, or similar, to call the post-simulation script.
* BBH gallery example [AK, PS] http://einsteintoolkit.org/gallery/bbh/index.html
** These figures are a little unintuitive and confusing in the current order...(more description), we would like to (1) rearrange...and (2) write...do you object to these changes?
What is confusing, and what new order would be better?
Thinks improvements to understandability of the graphs. Newest version and try to make the XY plots, should be quite the same and produce nice views of the horizons. And work for the GW graphics. AK-Looking at the BBH gallery and discussion of order of the Gallery page and thinking about for people starting the first time with these examples. Some graphics use Wizard, some SimulationTools, some with VisIt, and have not be able to duplicate some.
What is "Wizard"?
Leave the animation as is...cannot regenerate yet.
Barry Wardell (barry.wardell@ucd.iemailto:barry.wardell@ucd.ie) made the movie; I'm not sure where the scripts for that are; maybe you could contact him?
So re-arrange and add text. ES-Would be good to collect the scripts that generate these images. A single "Make" would be nice. RH-Do these changes. ZE&BG-Looks good. BG-Would be nice to also have the steps/scripts for each of the tools generating the graphics in case the user does not have access to them all.
RH-Look at http://einsteintoolkit.org/gallery/bns/scripts.tar.gz
Look at https://bitbucket.org/einsteintoolkit/www/src/master/gallery/bbh/Makefile. 🙂 That builds all the plots I contributed. The VisIt ones and the movie were not so simple to script, but it might be possible given an investment of time. The VisIt ones were done by Eloisa Bentivenga (Eloisa.Bentivegna@ibm.commailto:Eloisa.Bentivegna@ibm.com).
-- Ian Hinder Research Software Engineer University of Manchester, UK
On 8 Jun 2020, at 14:48, Ian Hinder <ian.hinder@manchester.ac.ukmailto:ian.hinder@manchester.ac.uk> wrote:
On 4 Jun 2020, at 16:39, Bill Gabella <b.gabella@vanderbilt.edumailto:b.gabella@vanderbilt.edu> wrote:
** [ZE] NRPyPN we use two punctures for initial data in ETK. Looking for low ecc BBH intial data parameter solvers. Wrote one based on literature. Option in Two Punctures that you sepcify the 8 input params and outputs the initial data, P_t and P_r. If close to ecc =0, as close as Post-Newtonian allows. ES-Good enough params or need to iterate? ZE-Paper by Ramos-Buades et al. https://arxiv.org/abs/1810.00036 . They say with one iteration can drop ecc to order 1/10^3 . RH-Good to have the notebook in the utils folder for Two Punctures. ZE-Tedious, but the C version is not too hard and integrate with Two Punctures. RH-Very low eccentricity requires man iterations, a glitch shows that ecc energy goes up. Scheme gives back P_t and P_r. PN in C does iteration zero, but not later ones. RH&ZE-Iteration greater than 1 is not in NRPyPN but RH's student has been doing that. RH-I will reach out to principals and discuss this. Does two orbits and sees what to update, and then re-submits itself, and want ecc < 1e-6 . First bit is all eccentricity reduction. ZE-Found typos in the original paper. dE_GW/dt was very different than other groups use. RH-Recevied their Mathematica notebook, so hopefully better than the paper.
Some links to NRPyPN, Low-eccentricity Post-Newtonian BBH initial data parameters (for Two Punctures): https://nbviewer.jupyter.org/github/zachetienne/nrpytutorial/blob/master/NRP... https://github.com/zachetienne/nrpytutorial/tree/master/NRPyPN (source codes)
Hi,
I developed an infrastructure for obtaining low-eccentricity parameters for BBH. It is implemented and freely-available in SimulationTools for Mathematica. See https://bitbucket.org/simulationtools/simulationtools/src/master/Eccentricit.... I haven't used it in a while, but can't think why it wouldn't still work. It lacks documentation - if someone is interested in using it or developing it further, I can see if I can find some time to write up some docs.
You can use it to generate an initial guess from PN (QuasiCircularParametersFromPostNewtonian[{m_, q_, chi1_, chi2_, om_}]) for any aligned-spin case (you can probably use chi_z for precessing cases). This will give you the separation, orbital angular momentum (r * py) and radial linear momentum (px). You then run a simulation with these parameters for a few orbits, and analyse the results. The method uses the time derivative of the radial separation for its eccentricity estimator. You use BinaryEccentricityFromSeparationDerivative, passing it the separation as a function of time (which you can get from ReadBinarySeparation), and a time window in which to measure the eccentricity. You can get a suitable window from EccentricityFitWindow, which calculates it using a simple heuristic from the initial orbital frequency to give two orbits. You can then use ReduceEccentricity with the results of BinaryEccentricityFromSeparationDerivative which gives you updated TwoPunctures parameters.
There are a number of higher level functions designed to fit this into an automated workflow. I was using it with SimFactory 3, which supports the idea of post-simulation scripts and "termination reasons". I had it set up so that when Cactus terminates during an eccentricity reduction run, it would run a script (https://bitbucket.org/simulationtools/simulationtools/src/master/Scripts/Ana...) which would call SimulationTools to estimate the next separation and radial momentum (I chose to keep the angular momentum L fixed, since that corresponds to fixed omega at 0 PN (maybe 1 PN?)). The post-simulation script is https://bitbucket.org/ianhinder/simfactory3/src/master/simfactory/etc/appdb/..., and it has a number of heuristics for what to do in different cases.
There are a lot of parts to this system, but it used to run extremely well, and was fully automated, and was used to produce many production simulations, including the very high spin simulations used in https://arxiv.org/abs/1810.10585, with chi_z = 0.9 and mass ratios up to 5.
I forgot to mention the crucial part! For those simulations, it's very challenging to get the eccentricity down; typically I could only get it down to ~1e-3, but that is usually enough. For simple cases, like equal mass, non-spinning, if you are at a large separation (e.g. 15 orbits), the method was able to iterate the eccentricity down to something like 1e-6.
-- Ian Hinder Research Software Engineer University of Manchester, UK
Hi,
On Mon, 8 Jun 2020 at 14:48, Ian Hinder ian.hinder@manchester.ac.uk wrote:
Leave the animation as is...cannot regenerate yet.
Barry Wardell (barry.wardell@ucd.ie) made the movie; I'm not sure where the scripts for that are; maybe you could contact him?
Attached is the script I used. There were a few variations of the movie so I'm not totally sure that this script exactly matches the one on the ET website, but it should be very similar.
users@lists.einsteintoolkit.org
-
Barry Wardell -
Bill Gabella -
Ian Hinder