Users June 2020

users@lists.einsteintoolkit.org

12 participants
23 discussions

Meeting MInutes 06-11-2020
by Hamilton, Maria 17 Jun '20

17 Jun '20

Hello, Please see below the meeting minutes for this week. ____________ Present: Steven Brandt, Maria Hamilton, Roland Haas, Atul Kedia, Pieter Diener, Bill Gabella, Eric Schnetter, Yosef Zlochower, Liu Haoyong, Zach Etienne, Antoni Ramos Chair: Peter Minutes: Maria * Peter starts the meeting with the first item on the agenda: replacement of the cacuscode.org web page, and asked Seven to explain the situation. Steven explained that that he wants a resolution to this this issue and will keep adding it to the agenda until it is resolved, and the old web page replaced. Roland mentioned that Ian Hinder worked on a replacement for the web site, and gave the links: https://test.cactuscode.org/   https://github.com/einsteintoolkit/cactuscode.org/issues [https://avatars0.githubusercontent.com/u/6198340?s=400&v=4]<https://github.com/einsteintoolkit/cactuscode.org/issues> EinsteinToolkit/cactuscode.org<https://github.com/einsteintoolkit/cactuscode.org/issues> Holds the content of the CactusCode website. Contribute to EinsteinToolkit/cactuscode.org development by creating an account on GitHub. github.com The problem is that there are about 30 or more things that need to be fixed and he asked for volunteers to help pushing things forward. Steven asked if is absolutely necessary to address each on of them or only the essential ones. Atul Kedia was interested in the location of the the new web page, and if all the information from the old web page will be kept. Steven encouraged Atul to take a look and compare the info, warning that the new web page will not have the same functionalities, not being written in php. * Peter closed the first item and opened the second item on the agenda: virtual machines, and again, handed it over to Steven, to elaborate it. Steven explained his proposition to replace the old server to host the tutorial with a new one, because the current one is struggling, is fragile and complex. Roland wanted to make sure that the new server has the same capabilities of creating and managing individual accounts, like the Kubernetes set up. Steven assured him that JupyterHub is a better alternative to Kubernetes, and that multiple accounts can be managed. * Peter went on to the third item on the agenda, namely the gcc 10 issues and yielded to Roland to explain his work in trying to fix it. Roland related the problems with compile failure with gfortran 10 when using CCTK_PointerTo, and compiling LAPACK ExternalThorn from source tarball fails with gcc 10. He reporter that he has them almost fixed and will back port them to the current release. The problem with CCTK_Reduce is an old one, and it was reported since 2004 by Roberto de Pietri, and there is no fix. He proposed a change in the interface, namely in the Fortran function call, which will finally fix the issue. Peter commended Roland for his work, declaring that he is impressed. Roland thanked and said that he wished the compiler would not have changed, because it worked before. Zach reminded also about the compilation issue with Baikal, which is mystifying, it is not giving an error, it is just very slow. * Peter went on to the next item, namely call for reviewers for the proposed thorn additions for the next EKT release in 5 months. Zach offered to review Power, a wave-form extractor thorn, that will be polished and developed more this summer by a student under Roland's supervision. Maria tentatively offered to look into con2prim, a code developed by for a set of recovery schemes for primitive variables in GRMHD. Roland said that he will send more info about this, and that there is plenty of time for a decision to be made. * Peter continued to the next item on the agenda, namely the work on the Binary Black Hole Gallery, and asked Atul about the status of the testing. Atul explained that to his understanding there is still ork to be done, and he will look into the scripts on the simulations sent by Ian Hinder. He also mentioned that Peter S., who was not in the meeting, had problems with running on the cluster in Germany. Roland explained that the problems appeared because the cluster is very new, uses python3 and hyperthreading, and it is difficult to set up. * Peter went on to ask about the status of the binary neutron stars gallery. Roland reported that Sean R. finished the simulations and obtained agreement before merger, but the post-merger is a little different, which was expected. He will re-run the simulation on his workstation, to confirm his suspicions that it depends on the compiler. * Peter asked for chair/minute volunteers for the next two weeks. Roland expressed his hope that by July the meetings will be better attended because the new grant funds more people, and it will be easier to find volunteers. * Next, Peter went to unanswered issues and open tickets. Most were about gcc 10 which were already addressed by Roland previously. There was an issue with instability of Summation by parts, and Roland will look into it. * Peter adjourned the meeting. ____________ have a good rest of the week, Maria _______________________ Maria C. Babiuc Hamilton, Ph.D. Professor, Department of Physics College of Science, Marshall University, 1 John Marshall Drive, Huntington, WV, 25755 Room S 257, Phone: (304)696-2754

4 4

number of thesis using the Einstein Toolkit codes
by Roland Haas 16 Jun '20

16 Jun '20

Hello all, for a report to the NSF I am trying to obtain an idea of who many student thesis were using (were enabled by) the Einstein Toolkit. So if you are a student or are working with a student and have used the Einstein Toolkit as part of your thesis work in between 2019-07-01 and 2020-06-30 it would be great if you could let me know. 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 .

1 0

Einstein toolkit installation issues
by Camilo Posada 16 Jun '20

16 Jun '20

Hello, My name is Camilo Posada, and I'm currently a postdoc at the Silesian University in Opava (Czech Repubic), working on relativistic astrophysics. I have been interested in learning about the Einstein toolkit, so I decided to give it a try and install it. I have been following the instructions found in the documentation, but I am having some issues (see attached screenshot) which I have not been able to figure out. Could you please help me with this? I am running a MacBook Air, with macOS Catalina 10.15.4 Thank you in advance Kind regards, Camilo Posada, Ph.D. Institute of Physics Silesian University in Opava Bezručovo nám. 13, CZ-74601 Opava

2 5

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 15 Jun '20

15 Jun '20

Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers

1 0

Meeting Minutes 2020-06-04 [fixed links]
by Bill Gabella 12 Jun '20

12 Jun '20

[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/NR… 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 (-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=new… https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open… Next week: Chair is Peter D. and Minute taker Maria H. ---bill e.g. -- ===================================== William Gabella Research Assistant Professor Department of Physics and Astronomy Vanderbilt University Nashville, TN USA b.gabella(a)vanderbilt.edu (o) 615-343-2713

3 3

Einstein Toolkit Meeting Reminder
by users＠einsteintoolkit.org 10 Jun '20

10 Jun '20

Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers

1 0

Another needed flag for GCC 10
by Federico Maria Guercilena 09 Jun '20

09 Jun '20

Hi everyone, I'd like to report another small issue related to GCC 10, which is only partially related to the FORTRAN type mismatch issue from before. In the past few days I have managed to install GCC 10 on the Goethe cluster in Frankfurt, and I could build the ET using gfortran's "-fallow-argument-mismatch" and "-fallow-invalid-boz" flags (for good measure I also used -std=legacy, but that might not be necessary). As mentioned by Roland in a previous email, the thing builds but then fails to link. In my case (but I strongly suspect this is not just a coincidence, and applies in general), the failure manifested as a few "multiple definition" errors (in my case, multiple definitions of RESTRICTED_IOASCII_STRUCT), followed by a landslide of memory alignment warnings. The two appear unrelated, but after researching a bit, it turns out these errors are also related to new defaults in GCC 10. From GCC 10 release notes (https://gcc.gnu.org/gcc-10/changes.html): "GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking." From GCC 10 man page: "-fcommon In C code, this option controls the placement of global variables defined without an initializer, known as tentative definitions in the C standard. Tentative definitions are distinct from declarations of a variable with the "extern" keyword, which do not allocate storage. The default is -fno-common, which specifies that the compiler places uninitialized global variables in the BSS section of the object file. This inhibits the merging of tentative definitions by the linker so you get a multiple-definition error if the same variable is accidentally defined in more than one compilation unit. The -fcommon places uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object, or to a non-tentative definition. This behavior is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors." It appears that the ET is exactly the kind of code the GCC developers are thinking about in the previous sentence. In any case, setting the -fcommon option of the C compiler (plus the Fortran flags above) did the trick, and the ET builds with GCC 10. It would be nice if somehow the Cactus flesh could be updated to work without requiring this C flag. In contrast to the Fortran issue, this appears to be a backward compatible change (just some forgotten "extern" keywords??), although my knowledge of Cactus/ET internals is not extensive enough to make a definitive statement. I have not created a ticket, as enabling the -fcommon flag suffices to get the desired outcome, but I'd be happy to if you deem it necessary. Cheers, Federico Guercilena PS On my laptop, where I first encountered the issue, GCC 10 still stubbornly fails to compile LoopControl despite the -fallow-type-mismatch flag, but it is now clear that this is a quirk of my system, or maybe the Linux distribution I run, not a general issue. -- Dr. Federico Maria Guercilena Technische Universität Darmstadt Institut für Kernphysik Theoriezentrum S2|11 Schlossgartenstraße 12 64289 Darmstadt Room 302 +49 6151 16 21562 fguercilena(a)theorie.ikp.physik.tu-darmstadt.de

2 1

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 08 Jun '20

08 Jun '20

Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers

1 0

Meeting Minutes 2020-06-04 [fixed links, try no. 2]
by Bill Gabella 04 Jun '20

04 Jun '20

[fixed a couple of links, second try] 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/NR… 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 (see link below, the -fallow-argument-mismatch workaround). MH&RH-MAc Homebrew not listed because slow Baikal compile time, but does compile with gcc 9. https://lists.mpich.org/pipermail/discuss/2020-January/005863.html 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=new… https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open… Next week: Chair is Peter D. and Minute taker Maria H. ---bill e.g. -- ===================================== William Gabella Research Assistant Professor Department of Physics and Astronomy Vanderbilt University Nashville, TN USA b.gabella(a)vanderbilt.edu (o) 615-343-2713

1 0

Meeting Minutes 2020-06-04
by Bill Gabella 04 Jun '20

04 Jun '20

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/NR… 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 (-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=new… https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open… Next week: Chair is Peter D. and Minute taker Maria H. ---bill e.g. -- ===================================== William Gabella Research Assistant Professor Department of Physics and Astronomy Vanderbilt University Nashville, TN USA b.gabella(a)vanderbilt.edu (o) 615-343-2713

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users June 2020