Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

No Einstein Toolkit Meeting
by Frank Loeffler 18 Dec '16

18 Dec '16

Hi, There will *not* be an Einstein Toolkit meeting next (coming) Monday. The next meeting will be on Mon Jan 9th, 2017, at the usual time: 9:30am US central time). Frank Loeffler

1 0

Fwd: Installing on OSX10.12
by Guy Pitman 16 Dec '16

16 Dec '16

Hi, I am a new user trying to install the simplified demo on a Mac running OSX10.12 (Sierra) I followed the instructions on https://docs.einsteintoolkit.org/et-docs/Simplified_Tutorial_for_New_Users <https://docs.einsteintoolkit.org/et-docs/Simplified_Tutorial_for_New_Users> and followed the instructions, but when I run the command ./simfactory/bin/sim build --mdbkey make 'make -j4' --thornlist=manifest/einsteintoolkit.th <http://einsteintoolkit.th/> I at first get CST error 1: -> Configuration script for thorn PTHREADS returned exit code 1 Error message: 'Did not find PTHREADS’ I am not sure where to set the PTHREADS_DIR or what to set it to- I also tried editing einsteintoolkit.th <http://einsteintoolkit.th/> and disabling pthreads and Watchdog but then I get a error unknown type name 'CCTK_REAL8' Can anyone help? Many thanks Guy

2 1

New Einstein Toolkit Release (Payne-Gaposchkin)
by Frank Loeffler 16 Dec '16

16 Dec '16

We are pleased to announce the fourteenth release (code name "Payne-Gaposchkin") of the Einstein Toolkit, an open, community developed software infrastructure for relativistic astrophysics. The highlights of this release are: * The Llama multi-patch infrastructure, which has been publicly available for some time already, is now part of the Einstein Toolkit. An example in the Einstein Toolkit Gallery shows how to run Llama with a simple wave equation. * There is a new example in the Einstein Toolkit Gallery demonstrating how to evolve a binary black hole system and reproduce a waveform consistent with GW150914, the first gravitational wave event detected by LIGO. In addition, bug fixes accumulated since the previous release in May 2016 have been included. The Einstein Toolkit is a collection of software components and tools for simulating and analyzing general relativistic astrophysical systems that builds on numerous software efforts in the numerical relativity community including CactusEinstein, the Carpet AMR infrastructure and the relativistic magneto-hydrodynamics code GRHydro. For parts of the toolkit, the Cactus Framework is used as the underlying computational infrastructure providing large-scale parallelization, general computational components, and a model for collaborative, portable code development. The toolkit includes modules to build complete codes for simulating black hole spacetimes as well as systems governed by relativistic magneto-hydrodynamics. The Einstein Toolkit uses a distributed software model and its different modules are developed, distributed, and supported either by the core team of Einstein Toolkit Maintainers, or by individual groups. Where modules are provided by external groups, the Einstein Toolkit Maintainers provide quality control for modules for inclusion in the toolkit and help coordinate support. The Einstein Toolkit Maintainers currently involve postdocs and faculty from six different institutions, and host weekly meetings that are open for anyone to join in. Guiding principles for the design and implementation of the toolkit include: open, community-driven software development; well thought out and stable interfaces; separation of physics software from computational science infrastructure; provision of complete working production code; training and education for a new generation of researchers. For more information about using or contributing to the Einstein Toolkit, or to join the Einstein Toolkit Consortium, please visit our web pages at http://einsteintoolkit.org. The Einstein Toolkit is primarily supported by NSF 1550551/1550461/1550436/1550514 (Einstein Toolkit Community Integration and Data Exploration). The Einstein Toolkit contains about 200 regression test cases. On a large portion of the tested machines, almost all of these test suites pass, using both MPI and OpenMP parallelization. === Larger changes since last release === * Cactus Flesh - Update linker flags to allow linking using newer versions of 'ar' - Add '.' to perl @INC directory to allow build using newer versions of Perl - Provide Cactus version as CACTUS capability to thorns - Allow aligning interior (instead of just origin) of grid functions - Output build timing information in VERBOSE mode * Formaline - Attempt to use fast methods where possible (hardlinks are available) - Only update files in thorns that changed -> should make it noticeably faster on most systems * Simfactory - use of environment variables CACTUS_NUM_PROCS and CACTUS_NUM_THREADS in runscript of all machines. Update your private entries accordingly. - Updates to several machines (too many to list) * Multipole - Add possibility to have separate output directory * ExternalLibraries - Version updates if built from scratch: OpenMPI, OpenBLAS * New thorns or tools - Llama: - multi-patch infrastructure for the Einstein Toolkit - has been publicly available for some time already, but is now part of the Einstein Toolkit === Upcoming changes for the next releases The Tmunu parameter support_old_CalcTmunu_mechanism, will be removed after this release. If you rely on this, your code is probably unnecessarily slow. Let us know if the removal would create a problem for you. Most of the Fortran code in GRHydro was already replaced by more modern, and much easier to maintain C++ code. Up to now, both versions are compiled, and can be chosen at start-time. For a few releases the C++ versions are the default. After this release, the Fortran versions will be removed. Let us know if the removal would create a problem for you. === How to upgrade from Brahe (ET_2016_05) === To upgrade from the previous release, use GetComponents with the new thornlist to check out the new version. See the [http://einsteintoolkit.org/download Download] page on the Einstein Toolkit website for download instructions. === Machine notes === Supported (tested) machines include: - Default Debian, Ubuntu, Fedora, CentOS, and MacOS installations - Bethe - Bluewaters - Comet (#) - Draco (#) - Edison (#) - Galileo - Gulob (#) - Gordon - Hydra (#) - Minerva - Queenbee 2 - Shelob - SuperMic (#) - Supermike II - Stampede (CPU) (*#) - Wheeler - Zwicky * Stampede: defs.local.ini needs to have sourcebasedir = $WORK and basedir = $SCRATCH/simulations configured for this machine. You need to determine $WORK and $SCRATCH by logging in to the machine. A new configuration for KNL nodes is being worked on, but not yet included in the release (but compilation works and tests mostly pass). # ML_ADMConstraints: There seems to be a problem regarding calculating the constraints from the BSSN quantities. The exact problem is not known yet, but indications point towards a compiler problem (Intel in all cases). In all cases the metric data (evolved with ML_BSSN) is identical to the test data (to round-off error) and only the ML_ADMConstraints data differ significantly from the test data. If output statements of relevant quantities are inserted into the code, the differences disappear One consistent symptom is failing of the Dissipation and RotatingSymmetry testsuites (as they include output of the constraints using ML_ADMConstraints). Investigations on this matter will continue, new findings, together with workarounds/solutions will be announced on the users mailing list, and will be back-ported into the release branch. Updates can be found in ticket #1995: https://trac.einsteintoolkit.org/ticket/1995 All repositories participating in this release carry a branch ET_2016_11 marking this release. These release branches will be updated if severe errors are found. The "Payne-Gaposchkin" Release Team on behalf of the Einstein Toolkit Consortium (2016-12-16) Steven R. Brandt Peter Diener Roland Haas Ian Hinder Frank Löffler Erik Schnetter Barry Wardell December 16th, 2016

1 0

Release-blocking (?) problem in Formaline (with patch)
by Erik Schnetter 16 Dec '16

16 Dec '16

I just found a bug in Formaline where it can hang indefinitely. The problem is in a line cat /dev/null $(filter-out '$(TARBALL_DIR)/config-Cactus.files', $?) && \ where "cat" might be called without any arguments, and it the waits forever. The solution is to change the line to cat /dev/null $(filter-out '$(TARBALL_DIR)/config-Cactus.files', $?) && \ I'll file a proper bug report later, but I hope this correction can go into the release. -erik -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

max number of processes on TACC Stampede login nodes
by Roland Haas 16 Dec '16

16 Dec '16

Hello all, TACC's stampede login nodes have a (rather conservative) maximum number of allowed processes per user of 150: rhaas@login3:~/tmp$ ulimit -a | grep processes max user processes (-u) 150 which is reached (in my case) when compiling with the default -j settings in simfactory on stampede (somewhere in PeTSc). Naturally this is not fully reproducible since it depends on exactly how the parallel build proceeds. Does anyone know of a good way to limit to total number of processes that make will produce (rather than the total number of parallel *recipes* that execute)? There is a -l option to limit the number of processes if the load gets too high. Right now I re-compiled using -j 4 instead of -j 8 which seems to have worked so far. 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://keys.gnupg.net.

3 2

meeting minutes for 2016-12-12
by Roland Haas 15 Dec '16

15 Dec '16

Present: Frank, Roland, Steve, Ian, Yosef, Peter Release: * Frank needs (at least) write access to Llama to create the release branches * other release branches and tags were created Failing ML using tests: * Peter will provide more details * right now it seems as if it really is the constraints that are triggering * initial data and metric data seems fine Jenkins test systems: * currently have some tests failing and would like to reduce that number to zero * currently no backups in place, need to do backups inside of the VM 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://keys.gnupg.net.

3 6

Mini-Workshop on FunHPC in Cactus (today 12:00 EST)
by Erik Schnetter 14 Dec '16

14 Dec '16

This afternoon, we will have a remote mini-workshop on FunHPC. I will describe how I began to use FunHPC instead of OpenMP with Kranc-generated code. Note that we will meet at 12:00 EST, 3 hours later than last week. I will post details at <https://docs.einsteintoolkit.org/et-docs/Remote_Mini- Workshop_Series>. The Google Hangouts link will be https://hangouts.google.com/call/ jjkffrrvmnbhrooiyjxhfeb2ume , same as last week. I apologize for the late notice and the lack of content on the wiki; I was unexpectedly busy in the past two days. -erik -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 12 Dec '16

12 Dec '16

Hi Please consider joining the weekly Einstein Toolkit phone call at 9:30 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/community/support/ We use a Google hangout, with an URL announced on this list before the meeting. Frank Loeffler

2 2

MoL_InitialCopy
by Steven R. Brandt 08 Dec '16

08 Dec '16

So I'm curious about why Cactus/MoL does things the way it does. For the sake of this example, consider that we are evolving the variable B and we compute B_RHS during the evolution. First, we fill in initial data. B = something. Second, at the start of the iteration loop, we rotate time levels. B --> B_p, B --> invalid Third, MoL_InitialCopy copies the previous time level to the current. B_p --> B Fourth, we evolve. B_RHS = Foo(B) MoL_InitialCopy seems to be a wasted step. It would not be needed if (1) time levels were rotated at the end of the iteration loop, or (2) we computed B_RHS = Foo(B_p) Am I missing something? Why do we do things that way? --Steve

3 2

Fwd: commit/SimFactory2: rhaas80: Ubuntu: disable finite-math-only
by Erik Schnetter 07 Dec '16

07 Dec '16

Cactus offers functions "CCTK_isnan" etc. that always do what the name suggests, so that compilers can optimize "isnan" away if they want. -erik ---------- Forwarded message ---------- From: Bitbucket <commits-noreply(a)bitbucket.org> Date: Wed, Dec 7, 2016 at 5:05 PM Subject: commit/SimFactory2: rhaas80: Ubuntu: disable finite-math-only To: commits(a)cactuscode.org 1 new commit in SimFactory2: https://bitbucket.org/simfactory/simfactory2/commits/cb947f7282c4/ Changeset: cb947f7282c4 Branch: master User: rhaas80 Date: 2016-12-06 19:37:49+00:00 Summary: Ubuntu: disable finite-math-only this turns isnan() into a no-op Affected #: 1 file Repository URL: https://bitbucket.org/simfactory/simfactory2/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. _______________________________________________ Commits mailing list Commits(a)cactuscode.org http://cactuscode.org/mailman/listinfo/commits -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users