Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

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

WG: Top for next weekly meeting
by Schaffarczyk, Alois 14 Sep '20

14 Sep '20

* 3rd attempt -- Dear all, My mail from Sept. 4 attached an improved plot (hopefully) obeying all recommendations from Sept-3: 1. Used color palette "virbis" 2. NR template mass scaling was adapted to value as stated in BBH gallery URL (0.95) My mail from Sept. 3 This is our (Atul and me) wish: Add the attached figure close to the trajectory. Justification: 1. Shows almost exact agreement to former ETK version, 2. Shows almost exact agreement to NR template, 3. Leads directly to the experiment it was designed for. We ask for your kind consideration Best wishes Peter S, Kiel Germany

1 0

ReadInterpolate thorn final review
by Roland Haas 10 Sep '20

10 Sep '20

Hello all, the ReadInterpolate thorn which is a FileReader like thorn that uses InterolateLocalUniform to interpolate the data read in onto the new grid is being proposed for inclusion in the next Einstein Toolkit release ET_2020_11. It has been positively reviewed in: https://bitbucket.org/einsteintoolkit/tickets/issues/2416 and all are invited to have a look at it and all in to the next weekly Einstein Toolkit call on Thu Sept 17th 2020 to cast their vote about it being accepted into the toolkit. The thorn has been part of the master thorn list and been included in the automated tests since Fri Jul 17 2020. The ticket provides a link to the source of the thorn in its description. 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

Error in a function
by Erik Rodrígo Jiménez Vázquez 09 Sep '20

09 Sep '20

Hello everybody, I'm writing a function to set initial conditions, but I need to use an interative method and I need to operate over some arrays (grid functions) that I previously declared in the interface.ccl file. This is an example of one of the functions that I'm currently writing. #include "cctk.h" #include "cctk_Arguments.h" #include "cctk_Parameters.h" #include "ID.h" void Initial_Setup(CCTK_ARGUMENTS) { DECLARE_CCTK_ARGUMENTS; DECLARE_CCTK_PARAMETERS; int index; int i,j,k; int ierr; for (k=0; k<cctk_lsh[2]; k++) { for (j=0; j<cctk_lsh[1]; j++) { for (i=0; i<cctk_lsh[0]; i++) { index = CCTK_GFINDEX3D(cctkGH,i,j,k); phi[index] = 1.0; pi [index] = 0.0; } } } } where pi and phi are the grid functions previously defined in the interface.ccl and the header "ID.h" is where I defined the function Initial_Setup When I call the function in the main function and compile it I get error: type name is not allowed Initial_Setup(CCTK_ARGUMENTS); error: expression must have arithmetic type Initial_Setup(CCTK_ARGUMENTS); these errors are the same for the other functions. All these functions are not scheduled but the main function is. What is the problem? Any help will be apreciated. Erik

3 2

Midwest Relativity Meeting 2020, October 22-24
by Atul Kedia 08 Sep '20

08 Sep '20

Dear Relativists, The 30th annual Midwest Relativity Meeting will be hosted by the Center for Astrophysics and the Department of Physics of the University of Notre Dame from *October 22-24*, Thursday to Saturday. The Midwest Relativity Meetings aim to bring together researchers from across the Midwest and* beyond* to discuss general relativity and a broad range of topics in gravitational physics, including classical and quantum gravity, numerical relativity, relativistic astrophysics, cosmology, gravitational waves, and experimental gravity. As was in the past, talks will consist of short contributed papers in an informal atmosphere. Each participant may present a talk of ~15 minutes. Professors, post-docs, graduate students, and undergraduates working on relevant topics are encouraged to present their work. The deadline for abstract submission is *9th October*. The Blue Apple Prize will be awarded to the best graduate student speaker. Venue: Due to COVID-19 travel restrictions we will not be able to host the meeting at our beautiful campus. Rather, we will be conducting the meeting virtually. Recent experience has indicated that it is difficult to participate in full days of talks in a virtual format. Hence, we will extend the meeting over an additional day, and limit sessions to *no more than 4 hours per day* in the afternoons. Registration: To register and propose a talk, please visit the conference web site at: https://sites.google.com/nd.edu/mwrm-2020 Registration Fee: There is no registration fee. We look forward to seeing you at the 2020 Midwest Relativity Meeting. Sincerely, Atul Kedia PhD student, University of Notre Dame On behalf of the Local Organizing Committee: Grant Mathews, Lan Nguyen, Arielle Phillips, In-Saeng Suh, Atul Kedia, Miguel Correa, Luca Boccioli, Xilu Wang. Scientific Organizing Committee: Grant Mathews – U. Notre Dame David Garfinkle – Oakland Univ John Friedman – U. Wisc. Milwaukee Brett Bolen – Grand Valley State Univ. (last year’s host) Nicholas Yunes – UIUC (next year’s host)

1 0

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

07 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

PostCactus installation.
by Bilal Hameed 06 Sep '20

06 Sep '20

Dear users, I am installing "PostCactus" as $ pip install PostCactus. My python version is, *Python 2.7.17* Still, I am getting following error, Defaulting to user installation because normal site-packages is not writeable ERROR: Could not find a version that satisfies the requirement PostCactus (from versions: none) ERROR: No matching distribution found for PostCactus

2 1

Compilation error in PointerTo.F90
by Chris Stevens 05 Sep '20

05 Sep '20

Hi everyone, I am trying to get the Einstein Toolkit compiling on a new cluster, and most of the code compiles but I get the following error: COMPILING Cactus/util/PointerTo.F90 /maybehome/cstevens/Cactus_For_BBH_Production_Runs/Cactus/src/util/PointerTo.F90:23.27: address = transfer(c_loc(var), address) 1 Error: Assumed-rank argument requires an explicit interface at (1) make[3]: *** [PointerTo.F90.o] Error 1C make[2]: *** [util/make.checked] Error 2 make[1]: *** [/maybehome/cstevens/Cactus_For_BBH_Production_Runs/Cactus/configs/sim/lib/libthorn_Cactus.a] Error 2 I am using gfortran 4.8.5, perhaps this can be resolved by simply updating gcc and gfortran? The flags for Fortran are F90FLAGS = -g3 -fcray-pointer -ffixed-line-length-none Cheers, 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

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users