[Users] Meeting Minutes 2020-06-04
Bill Gabella
b.gabella at vanderbilt.edu
Thu Jun 4 10:24:46 CDT 2020
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/NRPyPN/NRPyPN.ipynb
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&sort=-updated_on
https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open&sort=-updated_on&q=Please%20review
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 at vanderbilt.edu
(o) 615-343-2713
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1769 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20200604/dd626b08/attachment.bin
More information about the Users
mailing list