Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Visualization of AHFinderDirect horizons
by Michael Clark 13 Nov '15

13 Nov '15

Hello, We're looking for a way to visualize the horizons from AHF as snapshots in time, preferably in lockstep with data generated from CarpetIOHDF5. We've been using VisIt to create plots and images of data generated by CarpetIOHDF5. We considered using the xdmf script mentioned in https://trac.einsteintoolkit.org/ticket/1828 but this seemed to trace out the apparent horizons over all time and did not appear suitable to creating a snapshot at a particular iteration. Is there a known solution for this? Perhaps using CarpetIOHDF5 with some of the AHF variables to generate a some sort of region in VisIt corresponding to the apparent horizon? Thanks, Michael Clark

3 3

New Einstein Toolkit Release (Somerville)
by Frank Loeffler 12 Nov '15

12 Nov '15

We are pleased to announce the twelfth release (code name "Somerville") of the Einstein Toolkit, an open, community developed software infrastructure for relativistic astrophysics. This release includes, among other things, improvements to the Cactus flesh, re-writes of the space-time solver McLachlan, a new GRMHD evolver (IllinoisGRMHD), and a multi-grid elliptic solver working in Carpet (CTThorns). In addition, bug fixes accumulated since the previous release in May 2015 have been included. For more detailed information about the "Somerville" release please read the long release announcement on the Einstein Toolkit web pages: http://einsteintoolkit.org/about/releases/ET_2015_11_announcement.php. 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. 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 1212401/1212426/1212433/1212460 (Einstein Toolkit), and also by 0905046/0941653 (PetaCactus) and 0710874 (LONI Grid). 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. The changes between this and the previous release include: === Larger changes since last release === * Almost all repositories moved from the Einstein Toolkit subversion server to bitbucket, with the ExternalLibraries being the only exception. Taking this move as opportunity, some already existing thorns were moved to more appropriate arrangements. * Cactus Flesh - While not a particular user-visible change, the Cactus version number was bumped to 4.3.0, as a new version of Cactus was released at the same time as this Einstein Toolkit release. - Thorns can specify versions for capabilities they provide, and thorns using them can depend on specific versions of those. - pthread support got moved into a thorn (ExternalLibraries/pthreads) * McLachlan - re-write of the BSSN thorns: some parameter names changed. Backwards compatible parameter names exist, but the old are deprecated now. Please switch to the new, more consistent, parameter names. * New thorns or tools - IllinoisGRMHD (and connected thorns): a new GRMHD code within the Einstein Toolkit. This isn't a drop-in replacement for GRHydro (as a lot of the functionality, and parameters are different), but should be seen as alternative. They are placed in the WVUThorns arrangement. - CTThorns: Elliptic solver for Cactus/Carpet. This is a multi-grid solver, and so far has mostly been used for cosmology-type simulations. - AH2xdmf.py script (new utility within the AHFinderDirect thorn): reads ASCII AHFinderDirect output files and combines data into hdf5 file that can easily be visualized as time-series within tools like VisIt - PITTNullCode/SphericalHarmonicReconGen: generic version of SphericalHarmonicRecon === How to upgrade from Hilbert (ET_2015_05) === To upgrade from the previous release, use GetComponents with the new thornlist to check out the new version. Switching to the new branch is not possible for most repositories due to repository moves. See the [http://einsteintoolkit.org/download Download] page on the Einstein Toolkit website for download instructions. === Remaining issues with this release === * Certain machines need to be configured specially in Simfactory because the remote directories cannot be determined automatically just from the user name. See the Machine notes below. * Recovering with Carpet: Carpet stores metadata (such as the simulation time) only for Carpet::max_timelevels time levels, although it is possible to allocate more time levels. These additional time levels then cannot be recovered; the symptom is an assertion failure during recovery. The solution is to either increase Carpet::max_timelevels, or to decrease the number of active time levels. === Machine notes === Supported (tested) machines include: - Default Debian, Ubuntu, Fedora and MacOS installations - Bethe - Bluewaters * - Carver - Comet - Datura - Edison - Fermi - Galileo - Gordon - Gullimin - Hopper - Nvidia - Philip - Queenbee 2 - Shelob - Supermike II - Stampede (CPU) * - Zwicky A * means that a small number of tests fail on that machine. Almost all tests pass on the other machines. * 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. All repositories participating in this release carry a branch ET_2015_11 marking this release. These release branches will be updated if severe errors are found. The "Somerville" Release Team on behalf of the Einstein Toolkit Consortium (2015-11-11) Steven R. Brandt Peter Diener Roland Haas Ian Hinder Frank Löffler Bruno C. Mundim Erik Schnetter Barry Wardell November 12, 2015

1 0

New Cactus Computational Toolkit Release (4.3.0)
by Frank Loeffler 12 Nov '15

12 Nov '15

We are pleased to announce the 4.3.0 release of the Cactus Computational Toolkit, an open source problem solving environment designed for scientists and engineers. This release includes, among other things, improvements to the Cactus flesh (see below for details), new utility thorns, and changed and additions to the external library thorns. In addition, bug fixes accumulated since the previous release have been included. Cactus is an open source problem solving environment designed for scientists and engineers. Its modular structure easily enables parallel computation across different architectures and collaborative code development between different groups. Cactus originated in the academic research community, where it was developed and used over many years by a large international collaboration of physicists and computational scientists. Cactus runs on many architectures. Applications, developed on standard workstations or laptops, can be seamlessly run on clusters or supercomputers. Cactus provides easy access to many cutting edge software technologies being developed in the academic research community. The Cactus user community has created and is maintaining toolkits for several research fields. The Einstein Toolkit addresses computational relativistic astrophysics, supporting simulations of black holes, neutron stars, and related systems. For more information about using or contributing to the Cactus Computational Toolkit, please visit our web pages at http://cactuscode.org. The changes between this and the previous release include: === Larger changes since last release === * Almost all repositories moved from the Cactus subversion server to bitbucket, with the ExternalLibraries being the only exception. Taking this move as opportunity, some already existing thorns were moved to more appropriate arrangements. * Cactus Flesh - While not a particular user-visible change, the Cactus version number was bumped to 4.3.0. - Thorns can specify versions for capabilities they provide, and thorns using them can depend on specific versions of those. - pthread support got moved into a thorn (ExternalLibraries/pthreads) - added support for an unlimited number of timelevels - Change default output filename format from implementation::groupname to implementation-groupname (parameter IOUtil::out_group_separator). - Piraha replaced parts of the old Cactus parser (but that should not be a user visible change). - Cactus complex number arithmetic functions are deprecated - Prevent Cactus from choking on very large parameter files - support linux-gnueabi architecture (e.g. Raspberry Pi) - check that providing function name is different from aliased function name - Drop explicit support for Fortran 77 in Cactus - Require C99 support - make: Don't require configuration name when only one is present * External Libraries: - Delay build of external libraries so they can be 'made' in parallel. - HDF5: Enable fortran interface by default, disable C++ interface by default. * New Components - CactusNumerical/LocalInterp2: a C++ drop-in replacement for LocalInterp - CactusNumerical/TestLocalInterp2: containing tests for LocalInterp2 - CactusNumerical/SummationByParts - CactusUtils/SystemTopology - CactusUtils/MemSpeed - CactusUtils/NaNCatcher - CactusUtils/SystemStatistics - ExternalLibraries/PAPI - ExternalLibraries/libncurses - ExternalLibraries/libreadline - ExternalLibraries/pthreads === How to upgrade from 4.2.0 === To upgrade from the previous release, use GetComponents with the new thornlist to check out the new version. Switching to the new branch is not possible for most repositories due to repository moves. See the [http://cactuscode.org/download/ Download] page on the Cactus website for download instructions. === Remaining issues with this release === * Certain machines need to be configured specially in Simfactory because the remote directories cannot be determined automatically just from the user name. See the Machine notes below. === Machine notes === Supported (tested through the Einstein Toolkit) machines include: - Default Debian, Ubuntu, Fedora and MacOS installations - Bethe - Bluewaters - Carver - Comet - Datura - Edison - Fermi - Galileo - Gordon - Gullimin - Hopper - Nvidia - Philip - Queenbee 2 - Shelob - Supermike II - Stampede (CPU) - 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. All repositories participating in this release carry a branch Cactus_4.3.0 marking this release. These release branches will be updated if severe errors are found. The 4.3.0 Release Team (2015-11-11) Steven R. Brandt Peter Diener Roland Haas Ian Hinder Frank Löffler Bruno C. Mundim Erik Schnetter Barry Wardell November 11, 2015

1 0

SC15
by Erik Schnetter 12 Nov '15

12 Nov '15

I'll be at SC15. Drop me a note if you're going to be there as well, a coffee or a cold beverage is always a good idea. If you're interested in compilers and LLVM, then < http://llvm-hpc2-workshop.github.io> might be interesting. -erik -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

release branches created
by Frank Loeffler 11 Nov '15

11 Nov '15

Hi, Note: This is not a release announcement, but a status of work-in-progress. The release branches have been created, and the current release thornlist can be found here: https://bitbucket.org/einsteintoolkit/manifest/raw/ac121c1c49464f0a145339cd… Please use this for release testing from now on. Frank

1 1

intel compiler flags?
by Jonah Miller 11 Nov '15

11 Nov '15

Hello, I am working on developing a modified stencil for the Einstein Toolkit and I am discovering that regression tests pass when I use the GNU compilers but fail when I use the Intel compilers, even with gentle optimization settings such as -O1. I suspect over-zealous optimization. Has anyone encountered this sort of problem before? And if so, does anybody know a good combination of flags that makes the intel compiler more cautious, without sacrificing too much speed? (For example, disabling fast math, which seems to be set to active by default.) Thank you in advance for your help! Best, Jonah Miller

4 4

maximum memory allowed for testsuites
by Frank Loeffler 09 Nov '15

09 Nov '15

Hi, We should put a limit on how much memory a testsuite is allowed to use. Currently two testsuites fail in a 1GB (RAM) bare-bones virtual machine due to this: CarpetProlongateTest/test_cc_tvd_hi IllinoisGRMHD/magnetizedTOV Both tests succeed using 2GB RAM on the same VM. Frank

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 09 Nov '15

09 Nov '15

1 0

Einstein Toolkit Meeting Reminder
by Roland Haas 01 Nov '15

01 Nov '15

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 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/ I short: the number is (+1) 225-578-4942 and the conference id is 118682#. Topics will likely include the upcoming release (planned for Nov. 11th). Roland would like to discuss the possibility of intentionally breaking the old svn repositorie's trunk versions such that accidental use of old thornlists is caught more easily. Roland Haas

2 1

Exact meaning of prolongation tags
by Federico Guercilena 31 Oct '15

31 Oct '15

Hello, could anyone tell me a few details regarding the Carpet prolongation operators? It appears there's no real documentation about them. Looking at Carpet source code I can see these operators are available: none sync restrict copy Lagrange ENO ENOVOL WENO TVD Lagrange_monotone STAGGER011 STAGGER101 STAGGER110 STAGGER111 The "polynomial" ones (Lagrange, ENO, etc) appear to be self explanatory, more or less. I'm particularly interested in the exact behaviour of "none", "sync" and "copy". "none" and "sync" are the same thing apparently. I find the "restrict" operator very confusing, since these are supposed to take care of prolongation. I'm asking because in a thorn I'm working on, a certain GF has prolongation set to "None". This resulted in buffer zones on finer grids not to be initialized (full of NaNs) when switching on mesh refinement. Although I think I found a workaround, I'd like to take care of this by using some already provided mechanism, if available. Thank you very much, Federico Guercilena -- Federico Guercilena Institut für Theoretische Physik Johann Wolfgang Goethe-Universität Max-von-Laue-Str. 1 60438 Frankfurt am Main, Germany Telephone: +49 69 798 47887 Email: guercilena[at]th.physik.uni-frankfurt.de

4 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users