Users September 2020

users@lists.einsteintoolkit.org

18 participants
19 discussions

Stuck compiling dh.cc
by Chris Stevens 29 Sep '20

29 Sep '20

Hi everyone, I've managed to get this compiling and have just completed the example BBH run simulating the system of the first detection, however now that I have left it for a few weeks and come back, naturally nothing works. The error I now have is with MPI_UB and dh.cc when building through simfactory. I get the following output: In file included from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dist.hh:12, from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/vect.hh:13, from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/bbox.hh:11, from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:10: /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc: In function ‘ompi_datatype_t* mpi_datatype(const dh::light_dboxes&)’: /opt/openmpi4/include/mpi.h:337:63: error: expected ‘}’ before ‘;’ token #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(symbol, new_symbol) 0; static_assert(0, #symbol " was removed in MPI-3.0. Use " #new_symbol " instead.") ^ /opt/openmpi4/include/mpi.h:1131:24: note: in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ # define MPI_UB THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_UB, MPI_Type_create_resized); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2195:23: note: in expansion of macro ‘MPI_UB’ {1, sizeof s, MPI_UB, "MPI_UB", "MPI_UB"}}; ^~~~~~ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2195:9: note: to match this ‘{’ {1, sizeof s, MPI_UB, "MPI_UB", "MPI_UB"}}; ^ In file included from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dist.hh:12, from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/vect.hh:13, from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/bbox.hh:11, from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:10: /opt/openmpi4/include/mpi.h:337:63: error: expected ‘}’ before ‘;’ token #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(symbol, new_symbol) 0; static_assert(0, #symbol " was removed in MPI-3.0. Use " #new_symbol " instead.") ^ /opt/openmpi4/include/mpi.h:1131:24: note: in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ # define MPI_UB THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_UB, MPI_Type_create_resized); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2195:23: note: in expansion of macro ‘MPI_UB’ {1, sizeof s, MPI_UB, "MPI_UB", "MPI_UB"}}; ^~~~~~ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2188:46: note: to match this ‘{’ dist::mpi_struct_descr_t const descr[] = { ^ In file included from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dist.hh:12, from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/vect.hh:13, from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/bbox.hh:11, from /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:10: /opt/openmpi4/include/mpi.h:337:79: error: static assertion failed: MPI_UB was removed in MPI-3.0. Use MPI_Type_create_resized instead. #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(symbol, new_symbol) 0; static_assert(0, #symbol " was removed in MPI-3.0. Use " #new_symbol " instead.") ^ /opt/openmpi4/include/mpi.h:1131:24: note: in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ # define MPI_UB THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_UB, MPI_Type_create_resized); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2195:23: note: in expansion of macro ‘MPI_UB’ {1, sizeof s, MPI_UB, "MPI_UB", "MPI_UB"}}; ^~~~~~ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2195:29: error: expected primary-expression before ‘,’ token {1, sizeof s, MPI_UB, "MPI_UB", "MPI_UB"}}; ^ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2188:36: warning: unused variable ‘descr’ [-Wunused-variable] dist::mpi_struct_descr_t const descr[] = { ^~~~~ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2177:23: warning: unused variable ‘newtype’ [-Wunused-variable] static MPI_Datatype newtype; ^~~~~~~ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2195:50: warning: no return statement in function returning non-void [-Wreturn-type] {1, sizeof s, MPI_UB, "MPI_UB", "MPI_UB"}}; ^ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc: At global scope: /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2197:5: error: ‘newtype’ does not name a type; did you mean ‘iswctype’? newtype = dist::create_mpi_datatype(sizeof descr / sizeof descr[0], descr, ^~~~~~~ iswctype /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2208:5: error: ‘initialised’ does not name a type; did you mean ‘MPI_Initialized’? initialised = true; ^~~~~~~~~~~ MPI_Initialized /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2209:3: error: expected declaration before ‘}’ token } ^ /maybehome/cstevens/Cactus/arrangements/Carpet/CarpetLib/src/dh.cc:2177:23: warning: ‘newtype’ defined but not used [-Wunused-variable] static MPI_Datatype newtype; ^~~~~~~ make[3]: *** [/maybehome/cstevens/Cactus/configs/CTGD_Testing/config-data/make.config.rules:281: dh.cc.o] Error 1 make[2]: *** [/maybehome/cstevens/Cactus/lib/make/make.thornlib:113: make.checked] Error 2 make[1]: *** [/maybehome/cstevens/Cactus/lib/make/make.configuration:181: /maybehome/cstevens/Cactus/configs/CTGD_Testing/lib/libthorn_CarpetLib.a] Error 2 make: *** [Makefile:260: CTGD_Testing] Error 2 I did find the following thread: http://lists.einsteintoolkit.org/pipermail/users/2018-October/006566.html and I've done a clean compilation but same deal. I'm using OpenMPI 4.0.5 and gcc/g++ etc 8.3.1. I've confirmed which mpicc etc points to the right place, and what I think the relevant lines in the option list file are: CPPFLAGS = -DOMPI_SKIP_MPICXX FPPFLAGS = -traditional CFLAGS = -g3 -std=gnu11 -Wunused-variable CXXFLAGS = -g3 -std=gnu++11 -Wunused-variable F77FLAGS = -g3 -fcray-pointer -ffixed-line-length-none F90FLAGS = -g3 -fcray-pointer -ffixed-line-length-none# -Wextra -Wimplicit-interface#-fallow-argument-mismatch MPI_DIR = /opt/openmpi4/ MPI_LIB_DIRS = /opt/openmpi4/lib MPI_INC_DIRS = /opt/openmpi4/include MPI_LIBS = mpi open-rte open-pal I have added CPP = ... CXX = ... etc which point to the appropriate places. I also have cstevens@skynet:~/Cactus$ mpic++ --showme g++ -I/opt/openmpi4/include -pthread -Wl,-rpath -Wl,/opt/openmpi4/lib -Wl,--enable-new-dtags -L/opt/openmpi4/lib -lmpi Any help would be greatly appreciated. Thanks, Chris -- Dr Chris Stevens Postdoctoral Fellow Rm 310A Department of Mathematics and Statistics University of Otago Ph: +64 3 479 4567 http://www.chrisdoesmaths.com http://gravity.otago.ac.nz

3 2

Postdoctoral Positions in Computational Relativistic Astrophysics at Penn State
by Radice, David 29 Sep '20

29 Sep '20

The Department of Physics at The Pennsylvania State University is seeking to fill one postdoctoral scholar positions in computational relativistic astrophysics. The successful candidate will work on the development of a new numerical relativity code for neutron star mergers and supernovae in collaboration with David Radice. This position requires a Ph.D. in mathematics, physics, astronomy, or a closely related field. Applications must be submitted electronically at this url<https://psu.wd1.myworkdayjobs.com/PSU_Academic/job/University-Park-Campus/P…> and include a cover letter, a CV, and a statement of research interests. Applicants should arrange for three recommendation letters to be submitted to dur566(a)psu.edu<mailto:dur566@psu.edu> indicating the appropriate job number in the subject line. Applications received before December 1, 2020 will be given full consideration. The expected start date is September 1, 2021, although alternative start dates will also be considered. For more information, please visit https://www.gravity.psu.edu/. This is a fixed-term appointment funded for one year from date of hire with possibility of re-funding on a yearly basis for up to three years. CAMPUS SECURITY CRIME STATISTICS: For more about safety at Penn State, and to review the Annual Security Report which contains information about crime statistics and other safety and security matters, please go to http://www.police.psu.edu/clery, which will also provide you with detail on how to request a hard copy of the Annual Security Report. Penn State is an equal opportunity, affirmative action employer, and is committed to providing employment opportunities to all qualified applicants without regard to race, color, religion, age, sex, sexual orientation, gender identity, national origin, disability or protected veteran status. Questions can be directed to Dr. David Radice (dur566(a)psu.edu<mailto:dur566@psu.edu>).

1 0

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 28 Sep '20

28 Sep '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

Problem with the installation of the ET on the Marconi A3 machine
by Lorenzo Ennoggi 26 Sep '20

26 Sep '20

Dear ET users' support team, I'm new to the Einstein Toolkit and I'm experiencing an issue with the installation of the 2020 ET release on the Marconi A3 machine at CINECA, Italy. I'm using the 2017 Intel family compilers and libraries, as required in the /Cactus/simfactory/mdb/optionlists/marconiA3.cfg file. The installation seems to end up successfully, but running the "HelloWorld" test simulation results in errors related to the fact that GLIBCXX_3.4.21, needed by /simulations/HelloWorld/SIMFACTORY/exe/cactus_sim, is not found. In fact, the command strings /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/inspector/lib64/libstdc++.so.6 | grep GLIBCXX gives the following output: GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_3.4.20 GLIBCXX_FORCE_NEW GLIBCXX_DEBUG_MESSAGE_LENGTH 'GLIBCXX_3.4.21' does not appear. This version of GLIBCXX is only available within the 2019 and 2020 Intel families, but these are not compatible with many of the libraries needed by the ET and available on Marconi A3. What can I do to get the ET to work? The modules I have loaded on Marconi A3 are the following: 1) profile/base 2) profile/advanced 3) profile/archive 4) gnu/6.1.0 5) cmake/3.12.0 6) intel/pe-xe-2017--binary 7) intelmpi/2017--binary 8) zlib/1.2.8--gnu--6.1.0 9) szip/2.1--gnu--6.1.0 10) hdf5/1.8.17--intel--pe-xe-2017--binary 11) papi/5.7.1 12) git/2.17 13) hwloc/1.11.3--gnu--6.1.0 14) mkl/2017--binary 15) blas/3.6.0--intel--pe-xe-2017--binary 16) lapack/3.6.1--intel--pe-xe-2017--binary 17) gsl/2.2.1--intel--pe-xe-2017--binary 18) fftw/3.3.4--intelmpi--2017--binary 19) boost/1.61.0--intelmpi--2017--binary 20) python/3.6.4 The config-info file and a snapshot of the error messages generated by running the "HelloWorld" simulation are attached to the e-mail. Thanks in advance for your support. Best regards, Lorenzo Ennoggi

1 1

Postdoctoral positions in general relativistic magneto-hydrodynamics simulations at CCRG@RIT
by Carlos Lousto 25 Sep '20

25 Sep '20

As part of several NASA and NSF collaborative projects, RIT’s Center for Computational Relativity and Gravitation (CCRG) is currently seeking to fill one or two postdoctoral research positions with highly qualified individuals interested in pursuing research in the fields of numerical relativity, theoretical and computational astrophysics, with an emphasis on general relativistic magneto-hydrodynamics simulations. We are particularly interested in relativistic magneto-hydrodynamics simulations of accretion disks around supermassive black hole mergers, and binary neutron star coalescences from prior to merger through to the formation of disks and/or collapse of the merged remnant, the production of jets, and launching of outflows. We are also interested to perform “event-based” simulations, using parameters informed by specific LIGO/Virgo detections, and thereby permitting much closer comparison with observables, in order to interpret current and future multi-messenger observations by a wide array of current and future detectors. The group is involved in several large collaborations, including the LIGO Scientific Collaboration (LSC), The Einstein Toolkit Consortium (einsteintoolkit.org <http://einsteintoolkit.org/>) and a NASA Theoretical and Computational Astrophysics Network (TCAN) (compact-binaries.org <http://compact-binaries.org/>). CCRG researchers have access to several computing cluster facilities at national computing centers such as XSEDE and the TACC’s Frontera Supercomputer, as well as a dedicated over 3500-cores cluster and large storage pool hosted at the Center. The successful postdoctoral candidates will be Fellows of the “Frontier in Gravitational-Wave Astrophysics” (FGWA) Program hosted by CCRG (ccrg.rit.edu <http://ccrg.rit.edu/>) and our broader Institute of Astrophysics (aspire.rit.edu <http://aspire.rit.edu/>). Initially appointed for three years, the Fellows can renewable for up to five years depending on satisfactory performance and the availability of funds. Applications should consist of a cover letter, a brief statement of research interests, a curriculum vitae including publication list, and at least three letters of recommendation. All materials should be sent electronically as soon as possible to: manuela[AT]astro[dot]rit[dot]edu with a copy to ccrg-postdoc[AT]ccrg.rit.edu <http://ccrg.rit.edu/>. More information about the CCRG is available at http://ccrg.rit.edu/ <http://ccrg.rit.edu/>. And about Rochester at http://en.wikipedia.org/wiki/Rochester,_New_York <http://en.wikipedia.org/wiki/Rochester,_New_York> Please see the full advertisement at https://jobregister.aas.org/ad/7f61e5ff <https://jobregister.aas.org/ad/7f61e5ff>

1 0

Meeting Minutes 2020-09-24
by Hamilton, Maria 24 Sep '20

24 Sep '20

Present: Roland, Steve, Alois Peter, Liu, Sam, Zach, Ken, Helvi, Atul, Peter, Maria Chair: Peter Minutes: Maria Peter opened the meeting remarking that the agenda for Today is very short and asked if anybody wants to talk about things that are not currently on the agenda. There were three items added. 1. Maria mentioned failing to compile the development ETK version on OSX, while the stable version works just fine. Roland remarked that it might be a link problem and suggested compiling with j1, for a more explicit error output. 2. Zach reported new work done on the NRPy LaTeX interpreter, namely the Kronecker Delta is implemented now, which is very useful for coding the analytic metric. 3. Helvi announced that the Einstein Toolkit tutorial presented by Erik in the first week of the semester-long workshop at the ICERM was very well received and there is interest in having more tutorials like that, on a regular basis, while the workshop is running. Peter continued with the first urgent item on the agenda, namely the SPEC benchmark contribution. Steve admits that he did not do anything about it and will look into it, to see when the items are due. Helvi asked for clarifications on what exactly SPEC benchmark is, and Steve explained that it’s an acronym for Standard Performance Evaluation Corporation and there are a series of benchmarks to run based on science codes. Cactus ADM standard benchmark was given as an example. The next item on the agenda is the upcoming release planning. Roland emphasized that this is a serious issue, there are only two months until the planning release and there is not a lot of time, so things need to move along fast to get this going. First, everything that needs reviewed should be completed, then the release manager needs to be chosen, and he needs to come up with list of tasks to be executed. Roland and Steve would try to be released managers, since Yosef said no. Peter went on to the next item, the unanswered questions on the mailing list. Atul reported about the issue he is having with restarting simfactory, and the help he is getting from Erik. Helvi came up with very good suggestions that might fix the problem. Next item was open tickets, and Roland explained that there are only two big issues, related to Blas and OpenMPI, and a third one, related to the reduction interface. He and Steve will handle them. As the release date approaches, minor tickets and bug fixes will be addressed in the order of importance to the release. Lastly, Peter asked for chair and minutes taker for the next meeting. Helvi offered as chair, and Sam was encouraged to take minutes. The meeting adjourned. _______________________ 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

1 0

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 21 Sep '20

21 Sep '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

McLachlan and Cartoon2D conflicting?
by Federico Maria Guercilena 18 Sep '20

18 Sep '20

Hello everyone, I have found a very weird issue in trying to run 2D axysimmetric simulations with Cartoon2D and McLachlan, I'm really puzzled on what could be the cause and how to address it. In brief: in running a test TOV simulation with the above setup, the constraints have NaNs around the z-axis although all hydro and spacetime variables are fine, and the simulation crashes after a few iterations due to the NaNs propagating. However, this behavior is resolution-dependent (nothing strange at low resolution). Also Lean doesn't show any problems at any resolution, and the simulations run just fine in this case. More in detail, the setup that show this problem (the parfile is attached) is just a test TOV. It is a 2D axisymmetric run, using Cartoon2D. The spacetime is handled by ML_CCZ4, and I'm using David Radice's THC code for the hydro evolution (which strictly speaking is not part of the ET, but as you'll see the hydro is not at fault here). The initial data is handled by TOVSolver. When running at the resolution labelled as "mid" in the parfile, everything goes as planned, the ID is set up properly (in particular constraints violations are negligible), and the evolution proceeds nicely (the amplitude of the star oscillations seems a bit higher than it would be in a 3D simulation, but that might just be noise from the Cartoon2D boundary conditions). However when using the "high" or "fine" resolutions in the parfile (respectively 1.25 and 1.25^2=1.5625 times higher than mid), there are NaNs in the constraints, especially the Hamiltonian constraint, around the z-axis, in a sort of band (see the attached plot). The NaNs are on all reflevels, and the width of the band on the xz-plane varies, seemingly not just because the resolution varies between reflevels, but the NaNs band is sometimes a 1 or 2 points wider or narrower. Trying to evolve this data the NaNs propagate, the con2prim kills the hydro and progressively I end up with a "vacuum" simulation. ML_BSSN behaves similarly. All variables (primitives, conserved, spacetime, stress-energy tensor) are properly set as far as I can tell (no NaNs or weird values, and correct symmetry), even ADMMass::ADMMass_VolumeMass_GF. The fact that this last one is ok gave me the hunch that the problem is in the spacetime solver, and in fact switching to Lean did the trick: proper evolution at all resolutions. This also tells me the hydro code is not to blame, nor the initial data code (tried with a different, custom written one, no change). For various reasons (Lean is slower and doesn't implement CCZ4) I'd like to stick to ML_CCZ4. At first I thought that the way ML_CCZ4 handles symmetries and boundaries doesn't play well with Cartoon2D (some ordering problem), so I tried to modify its scheduler to make it as close to Lean as possible, but no change. It might be a problem with my grid, but then I don't see why Lean should work. I'm starting to think there's an issue with McLachlan internals (... the derivative stencils?), but than it should show up in 3D runs as well. In brief, I'm baffled. I'd be grateful for any insights, and of course I'll open a ticket if need be. But I'm still harboring a glimpse of hope that this is just a trivial mistake on my part... Thank you very much, Federico Guercilena PS Unrelated: in a couple of previous mails I wrote about the GCC10 issues, and how on my laptop I couldn't compile despite setting the necessary flags. That is still the case and I still have no idea why, but thanks to the latest efforts (mainly by Roland, as I understand?) the ET has been made "GCC10-proof" and that is not an issue anymore. I just wanted to say thanks. -- 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 3

Meeting Minutes 2020-09-10
by Gracia Linares, Miguel 17 Sep '20

17 Sep '20

Present: Peter D., Roland H., Miguel G., Zach E., Steve B., Alois S., Maria H., Bill G., Liu H.,Ken S., Yosef Z., Helvi W. Chair: Zach E. Minutes: Miguel G. * ReadInterpolate code inclusion https://bitbucket.org/einsteintoolkit/tickets/issues/2416 [RH] Reviewed positively by Yosef Z., should be voted next week, Roland is still working on removing one redundant parameter. * Con2Prim framework update: https://bitbucket.org/einsteintoolkit/tickets/issues/2414 [RH] * Work in progress, currently debugging, group will report once science setup is working (it is a better Con2Prim method for GRHydro and IllinoisGRMHD) It will not be included in the coming release but probably in the next. • Zach’s group is also working on a Con2Prim for Hybrid EOS like the one HARM code uses. * NRPyPN will be reviewed by Peter D. probably will not be ready for the coming release but for the next. * Status of new LaTeX interpreter for NRPy+ [ZE] Zach gave a detailed tour of LaTeX interpreter<https://nbviewer.jupyter.org/github/zachetienne/nrpytutorial/blob/feature-p…> mainly developed by Ken Sible. The user injects pure LaTeX math expressions and gets SymPy expressions that could be used with NRPy to generate highly efficient C code. Tensor support, index rising, multiple expression, operators support (interprets covariant derivatives). NRPy notation but user can take control and override NRPy quantity definitions. Will be validated with BSSN expressions. Next step GPU support. * Release manager for November ET release [RH] -The manager’s tasks include time line, find persons for the gallery examples, find open tickets critical to the release. -Steve suggest to break the Release manager tasks into pieces to reduce the manager’s work load. -Maria, Zach and Yosef volunteered to help with the release tasks. * Tickets ——— * LEAN code is looking for a reviewer. * Red hat is extending support for python2 to 2024 - NRPy and NRPyPN will support it too. * simfactory needs to be ported to python 3 but might be good to wait until the majority of clusters use python3 as default. Might be good idea to have support for the two version. * Next minute taker and call chair: 09/17/2020: Chair: Roland H. Minute taker: Steven B. 09/24/2020: Next week: Peter D. Minute taker: Maria H

2 1

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 14 Sep '20

14 Sep '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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users September 2020