Users May 2020

users@lists.einsteintoolkit.org

16 participants
24 discussions

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 18 May '20

18 May '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

BBH Example: Compiler issue on SimulationTools/Mathematica
by Atul Kedia 18 May '20

18 May '20

Dear all, I am testing the output figures on Binary black hole gallery examples, specifically the curvature scalars images using SimulationTools. As suggested in the page with available scripts I am using 'SimulationTools' application on Mathematica. When I try to load SimulationTools by entering the command '<< SimulationTools`' on nb or kernel I get the following error messages and would like help in fixing them: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CCompilerDriver`CreateLibrary::nocomp: A C compiler cannot be found on your system. Please consult the documentation to learn how to set up suitable compilers. Compile::nogen: A library could not be generated from the compiled function. CCompilerDriver`CreateLibrary::nocomp: A C compiler cannot be found on your system. Please consult the documentation to learn how to set up suitable compilers. Compile::nogen: A library could not be generated from the compiled function. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I have installed SimulationTools and h5mma and loading h5mma happens just fine (without any errors). Specifications: I am using Mathematica 12 on Windows 10 (not WSL). As suggested in mathematica stack exchange <https://mathematica.stackexchange.com/questions/79237/step-by-step-instruct…> I installed windows sdk <https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/> (although I did not remove visual c++ as suggested as I wasn't sure if that would break any other things.) In the ET meeting today I was suggested to use linux, WSL or a virtualbox by Roland, Bill and Steve so will be doing one of those, but would prefer a solution on windows. Could someone please help me with this? Any help is greatly appreciated. Thank you, best regards, -- Atul Kedia PhD student, Physics department, University of Notre Dame.

2 2

ETK Meeting Minutes 2020-05-14
by Hamilton, Maria 14 May '20

14 May '20

Present: Maria H., Steve B., Roland H., Zack E., Peter S., Atul K., Beyhan K., Federico C., Peter D. Yosef Z. Chair: Zach E. Minutes: Maria H. The chair Zach E. started to meeting. The main focus of the meeting was to decide what codes will be included in the next release, because Today is the feature freeze. He reported that due to Helvi's absence from the meeting, no update was available on Baikal. Steve B. presented the status of PreSync, and he reported that he is updating the documentation. He made the case that it will be good for the current grant if PreSync will be included in the current release. Zach E. requested confirmation from the reviewer that Presync runs without interfering with the old code. Steve B. argued that backward compatibility could be damaging because it sacrifices functionality. Roland H. confirmed that PreSync is safe, and a new test was introduced Yesterday for consistency check. Although he admits that PreSync would benefit from more time, he is of the opinion that it can be included in the next release, because it does not present any danger. He does not fully trust its functionality, especially the automatic synchronization, because it was not tested with BBH simulations. Zach E. and Federico C. requested more information, on known cases where PreSync failed, and how the new macros are used. Roland H. and Steve B. confirmed that PreSync is off by default and agreed to enable more flags to warn the user if PreSync is activated. Steve B. explained that the macros only provide with consistency check that the user is doing what was supposed to, and specified that there is a warn only mode that can be used to improve code. Zach E. called to vote on the inclusion of PreSync in the future release, and all voted in flavor. Zach continued the discussion with Baikal and asked for a vote, mentioning that although the reviewer was not on the call, she confirmed by email that the review is ongoing. Federico asked for clarification on the support BSSN will be supported, if Baikal will be included, and Zach confirmed that BSSN will continue to be supported, although he emphasized that Baikal gives better performance. Roland opposed the vote without confirmation from the reviewer, and required for Helvi to put an OK note in the ticket. Zach suggested two conditions that will disqualify Baikal from making into the next release (1) any new feature, and (2) incomplete review. Roland agreed with the two amendments and brought to attention that there are 2 more disqualifying conditions: lack on testing on clusters, and lack of gallery examples. Zach mentioned that the code was extensively tested by Roland on clusters by Roland, and that it does not require any gallery examples. Roland agreed, and Zach called to vote. All were in favor of including Baikal into the new release, pending the two conditions, and Zach, who abstained from vote, thanked for the support of his code. Roland brought to attention the tickets for review. Steve reported that the post-processing for the test suites were approved by Peter, however Roland had an objection, requesting the output on log files, and compatibility with SymFactory. Steve agreed to make the changes. Zach went to the next item on the agenda, namely deprecation warnings. Roland asked Peter D. about the status of the summation by partos ticket. Peter reported that by using the minimal bandwidth form, there will be minimal change to the code. After a discussion on how to report this change -- as deprecated feature or bug, decision was made to report it as deprecation and include it in the master branch after release. Zach went on the status of the gallery testsuites. He reported that TOV with BSSN and Illinois codes are OK, and that Shawn L. confirmed the BNS example. Peter S. and Atul K. talked about their progress with the BBH gallery testing and reporting on their effort to find an agreement between the ETK simulation and the measurements from the first LIGO detection. Atul uses Simulation Tools for visualization and informed that the sample data on the Gallery example works fine. Roland announced the feature freeze and requested that all the gallery examples to be re-run with the new ETK version. Steve will push today the new version of McLaughlin, and Roland mentioned that the changes affected the Kranc generator, and although none of the results should change, the check should be done. Peter S. expressed concern that the runs will be finished in time, but Rolland assuaged his worries. Zach reported that Bill G. was successful in running the Poisson gallery with the development version and is in the process of running Visit to make the plots. He will re-run after the code freeze. Zach raised a question about running a 1D wave asked by one of Feredico's students. Steve and Maria recommended to use the 3D grid with minimal number of points in the other 2 coordinates. Lastly, Zach required volunteers for chair and minute takers for the next two meeting. On may 21, Roland will be chair and Federico minute taker. On may 28, Steve will be the chair, and Roland the minute taker. After this decision was made on this regard, the meeting adjourned. I am attaching the file Bill G. provided through Zach E. take care, 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

1 0

Is there a better way to deal with grid arrays in ETK?
by 刘屿 14 May '20

14 May '20

Dear Cactus users, It is introduced in the UsersGuide of Cactus that the grid arrays can only be determined by function calls, rather than the quicker methods available for GFs. But is there a better way to deal with the grid arrays so far? I am trying to analyze some physical quantities in equatorial plane, and get the grid function in spherical coordinates by interpolation. It doesn't seem so convenient, if I define this new variable as grid arrays, Thank you best regards --------------------------- Yu Liu PhD Student Department of Astronomy Beijing Normal University

2 1

Einstein Toolkit Meeting Reminder
by users＠einsteintoolkit.org 13 May '20

13 May '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

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 11 May '20

11 May '20

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

2 1

1D wave equation
by Alessandro Ciarfella 09 May '20

09 May '20

Dear All, I'm a new user of the toolkit and I was trying to run the WaveEqn tutorial of the Einstein relativistic toolkit websitethat simulates the 3D wave equation. My question is: How can I change the program in such a way to simulate a 1D wave equation? In particular how does the wave_eqn.par file change?. Thanks in advance. Sincerely, Alessandro Ciarfella

1 0

Docker container jupyter-et
by Robert Kopp 08 May '20

08 May '20

I like Docker, although I am not yet very familiar with it. Anyhow I ran the container with the code, as follows: docker run -p 8888:8888 -it --rm ndslabs/jupyter-et:latest Then I saw: INFO (HelloWorld): Hello World! However, it failed to run the star problem. Instead, it returned the following: Error: specified parfile "par/tov_ET.par" does not exist or is not readable tried paths "/home/jovyan/Cactus/par/tov_ET.par" and "/home/jovyan/Cactus/repos/simfactory2/etc/parfiles/par/tov_ET.par", working directory is "/home/jovyan/Cactus"Aborting Simfactory. I saved the output CactusTutorial.ipynb, of course, so advice from anyone working on this project would be appreciated. I am presently using an FX-8350-based system, if this is relevant (32GB of RAM).

2 1

Instabilities with Summation by Parts 4th order operator
by Miguel Zilhão 07 May '20

07 May '20

hi all, i've been working on implementing the Summation by Parts (SBP) operators on some evolution codes i have and i was seeing some instabilities when using the 4th order accurate 2nd derivative operator. in order to try to understand the problem better, i've coded a very simple thorn that evolves the wave equation in first-order in time, second-order in space form. i can evolve the system just fine without any problems with the SBP operators of order 2, 6 and 8. with order 4, however, there are instabilities propagating from the boundary that crash the code very early on. has anyone seen something like this before? could there be a bug in the 4th order 2nd derivative SBP operators, or am i doing something wrong? i find it very strange that it only crashes with the 4th order accurate 2nd derivative SBP stencils (the code also seems to run fine with the parameter SummationByParts::sbp_2nd_deriv = no)... i've uploaded this thorn (called IST_WaveToy) here: https://github.com/mzilhao/IST_WaveToy i tried to keep everything as simple as possible. i'm attaching the thornlist used to checkout and compile the code, and in the repository i've also added the parameter files i tried with the different SBP orders (under ./par). any help or comments would be appreciated. thanks, Miguel

2 2

Meeting Minutes 2020-05-07
by Bill Gabella 07 May '20

07 May '20

Present: Roland H, Bill G, Beyhan K, Zhao Z, Federico C, Liu H, Atul K, Steve B, Peter D, Alois Peter S, Chris E, Zach E, Maria BH Chair: Roland Minutes: Bill * Questions before we start? * improve interpolation in tabulated EOS in EOS_Omni [FC] Proposed modification to the EOS_Omni thorn: I would like to discuss the possibility of including the patch to the EOS_Omni thorn proposed in the pull request that you can find at https://bitbucket.org/einsteintoolkit/einsteineos/pull-requests/6/enhanceme… and tracked in the ticket athttps://bitbucket.org/einsteintoolkit/tickets/issues/2383/enhancement-to-… . Although the modification may appear as minor, in my opinion, it could be relevant in some cases when adopting tabulated EOS (in particular in case of weak energy dependence on temperature). Best Regards, Federico Cipolletta. ** Federico: Developing code and done Spritz and GRHydro and the EOS_Omni thorn may not preform well in some cases. Using EOS, 3 Dim tables, rho, temp, and electron fluctuations. Define TOV initial data based on ICs, constant entropy or temp, for example. When starting with initial data from constant temperature obtain problems during evolution. GRHydro sim stops after about 140 iterations, temp grows too large. Parameter for t_max is in GRHydro and stops the sim. While in Spritz they get the incorrect results, temp goes too high. Added check in EOS_Omni to check temperatures, rho, y, eps, and want temp. See the tickets and pull request. Interpolate values of temperature, with Newton-Raphson, if iterations are more than a value you pass to other method Bisection. Paper in 2013 noted that if dependency of energy density on temperature is weak the Newton-Raphson can overshoot and can get out of the table ranges. Lines 547 and check line 615, on the derivative, if too high goes to Bisection method, slower but more accurate. Would like this change in a new release. Zach: Could this change cause any trouble with existing GRHydro? Positive impression. Federico: Proposed names for reviewers. Roland: Would it know if temperature is about to land outside of the valid domain of the table? FC: Line 399 (see ticket). RH: Seem to be depriving the user of an error message. Should run it by a high temperature EOS user for discussion. Peter: Do you make sure the root is properly bracketed that is needed by Bisection? Then guaranteed to find the solution. Do not see in the included code. FC: Think it is done in the earlier code. In Line 595 of Newton-Raphson, not included in the Diff shown in the ticket. * update on potential codes to be included in next release, from minutes [RH] o BaikalETK (Zach, Helvi) Zach: Have not heard from Helvi. She might be in finals, so maybe early next week. A couple of exchanges with Roland, GCC 9.3 has weird behavior, from man page or use the command line output so see optimizations for O1. Looking for the optimization for slow compiles, for the 8th order kernel, e.g. Pasted in the O1 optimizations expclicitly and it compiled fast. There is a command line flag for spitting out all the O1 optimizations. Something different from -O1 and from the documentation for O1. Paths forward, split up 8th order kernel, which is good for performance reasonse (3 parts seems optimal performance). That should be a work around for this issue. Re-organizing the equations. So weird. Looks like same problem in gcc 10.0. Peter: Why not tell cactus to compile with these flags? Zach: Could, but simfactory uses -O1, O2, etc. Roland: Cannot taek the explicit list because compiler dependent. Could take the optimization, run it through Perl script for correct options for compiler. Seems too awkward. Zach: Very slow on MacOS but still maybe 3x slower on Linux. Gcc 7.5 and 8.4 compiles times are quite fine. Roland: Would like to see a positive review even if the -O1 is so slow for some platforms, Homebrew or MacPorts, then good on the clusters, at least. Zach: Did add some code tests, and tests enabled, and both (Baikal and Baikal vacuum) passed on all the clusters. o PreSync (Steve, Roland) Roland: Seen a lot of "churn" in the last weeks. Steve: Fxiing things. Seeing if he can adjust Kranc to create correct Presync code. No good count as to how many issues/tickets for fixing it to get it in the release. Roland: Not ready today, but could still be read by release. Some as official, other parts as experimental. * tickets with bugfixes to review before freeze [RH] o no. 2381 https://bitbucket.org/einsteintoolkit/tickets/issues/2381/update-vectors-al… Roland: Support the Power9 cpus on Summit. * no. 2370 https://bitbucket.org/einsteintoolkit/tickets/issues/2370 Roland: Simple fix and will commit after this call. * * https://www.timeanddate.com/countdown/to?iso=20200514T09&p0=3704&msg=Featur… in *7* days, timeline <https://docs.einsteintoolkit.org/et-docs/Release_Details#Schedule_for_ET_20…> [RH] *!!!* * slow compile of Baikal code with gcc 9.3.0 on OSX [RH] See discussion by Zach above. o takes about 30 minutes to compile 8th order FD RHS using gcc 9.3.0 using -O1 and -march=core2 o Zach and Roland have been looking into this o slowness goes away if one uses |gcc -O1 --help=optimizers| which claims to report the options that are used by -O1 o not observed on Linux * deprecation announcement for ET_2020_05 [RH] Roland: Policy of announcing deprecation in the release BEFORE the actual deprecation. Recommends: o non-piraha parser in CST will be removed (will fail to parse READS / WRITES already) o READS / WRITES for non-existing variables will be a CST error, instead of a runtime error when the READS is encountered * http://einsteintoolkit.org/testsuite_results/index.php[RH] Roland: Ran last 4 days ago. Same as before, most are passing, as do the two Baikal tests. https://bitbucket.org/einsteintoolkit/tickets/issues?kind=bug&priority=majo… Peter: Summation by parts, will enable a new default to be minimal bandwidth, and not use the so-called optimized one. Will get information from Miguel and propose it. https://bitbucket.org/einsteintoolkit/tickets/issues?kind=bug&priority=mino… tagged for the next release other https://bitbucket.org/einsteintoolkit/tickets/issues?kind=proposal&kind=enh… flagged for the next release * gallery testing: https://bitbucket.org/einsteintoolkit/tickets/issues?kind=task&milestone=ET… Roland: Advises compiling now but again after the Feature Freeze in about 7 days! o TOV: Brock Brendal (UIUC) o BNS: Shawn Rosofsky (UIUC) o BBH: Peter Schaffarczyk (Kiel) o Poisson: Bil Gabella (Vanderbilt) o Multipatch scalar wave: Beyhan Karakaş (Ege University) unanswered question on mailing list: https://www.einsteintoolkit.org/tools/unanswered.php open tickets sorted by update time: https://bitbucket.org/einsteintoolkit/tickets/issues?status=open&status=new… tickets ready for review: https://bitbucket.org/einsteintoolkit/tickets/issues?status=new&status=open… Steve: New cactus site is https://test.cactuscode.org/ please make comments. Current site http://cactuscode.org/ . And this move is clearly decoupled from the new release. We can do it whenever. New Cactus ticket https://bitbucket.org/einsteintoolkit/tickets/issues/2387/move-cactuscodeor… Atul: *BBH test*, finished the figure for position of the centers and the strain. Some scaling issue compared to LIGO version. Ian Hinder's code on Mathematica, SimulationTools helps to sort that out: https://simulationtools.org/ . Peter S. will work on that. Working on Kerr Ricci scalars using Mathematica and Atul is missing a few C compilers that he needs...on his version of Mathematica on Windows. Third set of images on apparent horizons, made with VisIT. Issue page on GitHub, Roland recalls that there is a statement that you are using the intercompiler (?) to compile things. Should send a message to Users list on Einstein toolkit and on the Simulation Tools GitHub issues page, BitBucket https://bitbucket.org/simulationtools/simulationtools/issues . Atul is working on Windows with Mathematica and Steve recommends using the Linux on Windows. * Anything else: ** Beyhan: Getting errors with core collapse control thorn in the source code, he thinks. Roland: Sounds like something is missing. Version from SVN, could be old. Post a ticket if you still have problems. ** Bill: Is anyone running VisIT in a container? Seems not---will find a way to run it. Roland: *Vote next week for Feature Freeze.* Take a look at the new codes being included. -- ===================================== 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 May 2020