Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

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

Meeting Minutes
by Roland Haas 30 Sep '13

30 Sep '13

Present: Frank, Roland, Zach, Peter, Ian, Steve, Matt, Tanja Zach's UIUC code based MHD code: * code is ready, needs some minor cleanup * send email to Zach if you'd like a tarball * Zach will put into svn repository once he has access to the ET svn servers Next release: * Please have a look at the tickets marked for the next releas [1] * in particular the ones that were also present at the last release * next release is planned for November Test failures: * one test (TOVSolver/tov_carpet) failing since Roland's electric fence commits. Roland cannot reproduce this either on his workstation nor running manually within the jenkins VM. Will try to mimic more closely what Jenkins does. Ian will trigger a full rebuild. Jenkins: * currently have 3 build slaves: UCD, PI, Caltech * currently runs incremental builds since full builds take too long (~1hr) Yours, Roland [1] https://trac.einsteintoolkit.org/query?status=accepted&status=assigned&stat…

1 0

hwloc inside virtual machine
by Roland Haas 30 Sep '13

30 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I run a virtual machine (one of the slaves for Jenkins though I think it is hardly every used) inside of VirtualBox. I allocated 4 cores (and 4GB of RAM) for it. The host is a Intel(R) Core(TM) i7-2600 CPU which supports symmetric multithreading (ht in cpuinfo). hwloc detects this also inside the the virtual machine and thus sets the default number of threads to 4, however other places in the code disagree and I get a warning that more threads than physical SMT units are used: INFO (hwloc): Extracting CPU/cache/memory properties: There are 1 PUs per core (aka hardware SMT threads) There are 2 threads per core (aka SMT threads used) WARNING: This is larger than the number of hardware SMT threads VirtualBox apparently does not fully support this and indeed I end up with 8 concurrent threads which make the test unbearably slow (I had thought the ML tests were stuck). Explicitly setting OMP_NUM_THREADS=2 fixes the problem for me. If possible it would be nice though if hwloc detected this situation and did not start as many threads (useful eg for new users who use the ET virtual machine to try out Cactus). I attach the log file output. 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.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJI+CEACgkQTiFSTN7SboXvmgCgnpGcPH/2AIUxxB5lFUr9ZjO7 0oAAn04un6Kg41XAW5QXLkak/xBWVxxP =Xlnk -----END PGP SIGNATURE-----

3 2

Einstein Toolkit Meeting Reminder
by Frank Loeffler 29 Sep '13

29 Sep '13

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users