Users October 2013

users@lists.einsteintoolkit.org

9 participants
18 discussions

remove "old" Tmunu interface
by Roland Haas 17 Oct '13

17 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, two releases ago (Oersted) we deprecated the old interface. In the last release the default was changed to no longer support the old interface. Should we (in the upcoming release) fully remove the old interface? The old interface is extremely slow (since for each grid point there is a call to CCTK_IsThornActive()) and relies on StaticConformal (which almost no other thorn supports and which will likely break in unpredictable ways). Any opinions on this? Or is this too late to remove functionality and we should instead do so immediately after the next release? 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJe7n8ACgkQTiFSTN7SboXs0ACfXWznfYN6JE9rzDEDlwKT3cn7 mGkAoLUdxexImDSoTbDWH9S39g+SPOGp =O2yX -----END PGP SIGNATURE-----

2 2

Carpet questions
by Steven R. Brandt 16 Oct '13

16 Oct '13

First: Is there a way to determine whether a given grid point (regardless of level in the refinement hierarchy) also exists on a finer grid? Second: Is there a way to disable subcycling? I.e. what I want to do is evolve all levels simultaneously with the finest grid step. Is there a way to do that? In case context helps, what I'm thinking about doing is performing a set of 1D elliptic solves (during the evolution) in Funwave across a refined mesh. I'm not sure how to sensibly do the elliptic solves with subcycling (I am aware of a paper by Praetorius on this topic, but what he proposes is quite complex). Thanks! Cheers, Steve

2 1

Cactus runs on Raspberry Pi
by Frank Loeffler 14 Oct '13

14 Oct '13

For the HTML version, see http://cactuscode.org/media/news/Raspberry/ Cactus was ported to run on Raspberry Pis. These credit-card sized computers run Raspbian, a fork of Debian, a wide-spread and supported Linux distribution. Owing to the inherent portability of Cactus, the port to Raspberry Pi was straightforward; however a few tweaks were necessary due to the uncommon architecture (an ARMv6 32 bit core), which is anticipated to be supported in the next release of Cactus. Since Raspberry Pis are inexpensive and portable hardware, they provide convenient tools for education. Though their clock rate is limited to a mere 700 MHz with a current maximum supported memory of 512 MB, they nevertheless are able to support Cactus runs for small-scale toy codes. What has been demonstrated is a build of the Gauss release of the Einstein Toolkit, successfully passing all but a few test suites (apparently connected to HDF5 recovery in Carpet) on one Raspberry Pi and a small "cluster" of two Raspberry nodes. Building is straightforward: Simfactory now contains an optionlist raspbian.cfg, which includes instructions and lists packages which reduce build-time when installed. Frank Löffler

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 13 Oct '13

13 Oct '13

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As always, we will answer questions and hear comments that come up at the meeting. I addition to that, Zach Etienne will give a short walk-through of the IllinoisGRMHD code. We will use a web-service for screen-sharing and audio. This means we will not use the regular phone line. Please find instructions below: http://horizon.tapir.caltech.edu Log in via one of the username/password combinations listed (the server is up and plays some music for testing purposes right now). Please choose a display name (free form) and any of the two passwords listed on the page. Using the moderator password will allow you to mute anyone in the call and assign the presentation ability to users (incl. yourself which is the only thing you can do as a normal user), there can be several moderators at the same time. The whole page is based on flash and some java for screen sharing. Audio can be handled via flash in which case I recommend activating echo cancellation and turning down the recording level. Echo cancelling is still not great (headset strongly encouraged). Better audio quality can be achieved by using a VoIP softphone to call in. The address is sip:72013@horizon.tapir.caltech.edu I found that for Linux both Linphone and Ekiga worked (just ignore the dialog in Linphone offering to create a SIP account, both are in Debian and I guess Ubuntu as well). For Mac OSX you can also use Linphone (type linphone in a terminal it *does* have a GUI), it's in MacPorts and worked ok for me (an alternative is Telephone which needs a SIP acount eg from ekiga.net but works very well otherwise). Windows users can download Linphone from http://www.linphone.org/eng/download/packages/linphone.html (I have not tested this). Android and iPhone version of linphone can also be found there. The android version is reported to work, iPhone I do not have experience in. Thanks to Roland Haas for this setup. Frank Loeffler

1 0

Meeting Minutes
by Roland Haas 09 Oct '13

09 Oct '13

Present: Frank, Roland, Erik, Steve, Peter, Zach, Vassilli, Matt, Philipp, Ian Run issues: Vassilli sees decrease in irreducible mass in his runs at at time after the initial junk should have passed. Increase is a bout 4-5%, suggest to check increasing resolution globally to verify if effect is physics or numerics. Examples: * Roland tried NsNs purely Cartesian run, sees NaN after about 50M, will test if NaN is also present in the original multipatch run of comparable resolution * Peter to dig up parfile and runtime/memory estimates for bbh runs IllinoisGRMHD: * Zach to give a code walkthrough next week in the ET call * will use BigBlueButton for this (http://horizon.tapir.caltech.edu for a test video), Roland will test that this works beforehand Ps4 mode decomposition: * Jim Healy sees some odd behaviour in 2,1 mode of psi4 when using Multipole thorn but not when using old GT mode decomposition thorn * mode that is expected to be zero is not and leads to BH kick * run uses rotatingsymmetry180 and reflectionsymmetry (in z direction) * no physics change in multipole since Oersted release * suggest running in full mode * will work with Jim for a while then possibly take issue to mailing list again Yours, Roland

3 7

Einstein Toolkit Meeting Reminder
by Frank Loeffler 06 Oct '13

06 Oct '13

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/ In short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. As always, we will answer questions and hear comments that come up at the meeting. Frank Löffler

1 0

Re: [Users] [Commits] [svn:einsteintoolkit] AHFinderDirect/trunk/test/ (Rev. 1577)
by Frank Loeffler 03 Oct '13

03 Oct '13

On Thu, Oct 03, 2013 at 08:52:50AM +0000, rhaas(a)tapir.caltech.edu wrote: > initialize all unused memory to zero before output Hi, If this is done by Pugh, doesn't this mask real usage of uninitialized memory, such that tools like valgrind cannot find potential problems? Wouldn't it better not to output uninitialized values, or initialize them in the user thorns, not in the driver? Frank

2 1

Release Announcement: IllinoisGRMHD Thorn
by Zach Etienne 02 Oct '13

02 Oct '13

Dear ET folks, After months of work, I am pleased to release my rewrite of the Illinois numerical relativity group's staggered A-field GRMHD thorn to the ET community. The new thorn is called IllinoisGRMHD, and yields results identical (within roundoff error) to the original GRMHD code of the Illinois group with AMR & unigrids, with bitant symmetry & without, and with single or multiple MPI processes. We used precisely these GRMHD algorithms to produce our latest GRMHD-based papers. IllinoisGRMHD is written entirely in C, except for some C++ file I/O for debugging purposes, and all loops are OpenMP-compatible. The coding standard is C99. I would like to thank Frank and the CCT folks, who have graciously agreed to host IllinoisGRMHD on the ET SVN server, as the thorn awaits maintainers' approval for incorporation into the official ET. Download IllinoisGRMHD via the following command: svn co https://svn.einsteintoolkit.org/cactus/EinsteinEvolve/IllinoisGRMHD/trunk/ Browse IllinoisGRMHD source code in your web browser via: https://svn.einsteintoolkit.org/cactus/EinsteinEvolve/IllinoisGRMHD/trunk/ ** Background ** Roughly a decade of work has gone into the original code, and nearly all of the credit for debugging that battle-hardened code goes to Stu Shapiro and other former & current members of his group, to whom I give my great thanks and send the following message: Despite weeks entirely devoted to debugging this rewritten code, I found no major bugs in the original code. ** License ** The IllinoisGRMHD thorn is hereby released under the GNU GPL v2 or higher, to maximize compatibility with the ET thorns. ** Changes from Original Code ** The IllinoisGRMHD thorn contains significantly fewer lines than the code on which it is based, for two reasons: 1) Functionality that is no longer used (mostly dead code at this point) has been removed, and 2) New data structures in the code make it more compact, reducing the total number of lines in the reconstruction & MHD RHS evaluation routines to ~1200. I hope that the data structures in the new code will make it easier to read, less intimidating for beginners, and much easier to modify & extend, to do new science. I started development of IllinoisGRMHD as a standalone code, to minimize the turnaround time in the first round of debugging and to try new ideas for enhancing the performance, as well as making the code more compact and easier to read. The standalone driver routines still exist, but bugfixes found in the "thorn version" have not yet been backported to these routines. I am happy to report that the new code is significantly faster than the original code. ** Conservative-to-Primitives Routines ** We previously released our Conservative-to-Primitives routines to the ET mailing list, based on the very nice 2D HARM primitive solver of Scott Noble et al. An updated version is included in this release. ** Future Work ** Now that the IllinoisGRMHD thorn has been released, there is still some work to do, summarized below. 1) If using AMR grids, this thorn requires support for staggered prolongation & restriction algorithms within Carpet. We open-sourced these algorithms for an old version of Carpet back in March of 2012. Since then, Carpet has moved forward and these original algorithms (which we still use in our old version of Carpet) are no longer compatible with the latest ET. Philipp Moesta informed me over the summer that he has ported these operators to a more recent Carpet, and I will be working with him in the coming weeks to incorporate these into the latest Carpet. 2) This thorn currently exists as a drop-in replacement for the original GRMHD thorn of the Illinois group. I will be working in the coming weeks to make it more like a drop-in replacement for GRHydro instead, though perhaps someday it could be incorporated into GRHydro. 3) There are several minor to-do tasks remaining in the code, marked within comments labeled "FIXME" (grep for it). 4) There exist several possible avenues for code optimization, such as some possibly extraneous SYNC's within the schedule.ccl file. 5) More and better comments that clarify what the code is doing will be incorporated. 6) I am unsure how strongly this code violates coding standards & practices. E.g., I sometimes break lines according to the width of my laptop screen. Also, I love variable & function names that explain *exactly* what they do, which for some (possibly good) reason is frowned upon by other C/C++ programmers. I personally find that long names make it easier to read & understand a code years later. 7) I apologize for the lack of full written documentation at this point, but promise that it will be forthcoming. In the meantime, I encourage you to look at the large number of comments in the code, and if you find a point of confusion, please email me, and I'll fix it! -Zach

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users October 2013