Users November 2010

users@lists.einsteintoolkit.org

14 participants
37 discussions

Einstein Toolkit Release
by Frank Loeffler 23 Nov '10

23 Nov '10

We are pleased to announce the second release (code name "Chandrasekhar") of the Einstein Toolkit, an open, community developed software infrastructure for relativistic astrophysics. This release is mainly a maintenance release incorporating fixes accumulated since the previous release in June 2010, as well as additional test suites. 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 on the public version of the Whisky hydrodynamics code (now modified and called 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 hydrodynamics. Current development in the consortium is targeted at providing additional infrastructure for general relativistic magnetohydrodynamics. 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 five 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 detailed release announcement can be found here: <http://einsteintoolkit.org/toolkit/releases/ET_2010_11_announcement.php>. The Einstein Toolkit is primarily supported by NSF 0903973/0903782/0904015 (CIGR), and also by NSF 0701566/0855892 (XiRel), 0721915 (Alpaca), 0905046/0941653 (PetaCactus) and 0710874 (LONI Grid). The "Chandrasekhar" Release Team on behalf of the Einstein Toolkit Consortium (2010-11-23)

1 0

Meeting minutes
by Roland Haas 23 Nov '10

23 Nov '10

Meeting minutes: Present were: Peter, Bruno, Erik, Christian, Tanja, Roland, Ian, Eloisa Cactus release (Chandrasekhar): * all branches and tags for the release have been created (both svn and git) * need final re-run of the teststuites for all systems * Ian will contact the LORENE authors to ask which papers to cite * will add Christian to release team in release anouncement EOS interface: * old EOS_Base interface has been removed from development version GRHydro, should we also remove Ian Hawke's general EOS interface? Removing EOS_Base support requires users to re-write their parameter files (same for the general EOS but it might be used by fewer users). 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.

1 1

Release: http vs. https in the manifest?
by Erik Schnetter 22 Nov '10

22 Nov '10

Ian Hinder just pointed out to me that our Einstein Toolkit thorn list as well as our beginners' tutorial use https for anonymous access to various svn repositories. This often leads to problems when certificates are either not installed correctly, or when the local svn installation cannot verify the certificates because the certificate is too new. We discussed this before, and decided that the best way to avoid this problem is to use plain http for anonymous checkout. Since all code is public this does not seem to be a security issue. However, our thorn list still uses https in many cases. I have just updated our thorn list to use http instead of https for anonymous access, essentially adding an AUTH_URL for every URL, and modifying the URL to use http instead of https. Only SimFactory and LSUThorns cannot be accessed via plain http. Should we make this modification before the release? I have tested the resulting thorn list, and find no problems with it; if anything, the checkout is now faster. This does not make any changes to the content of our software, but only changes the way in which the repositories are accessed. I would vote in favour, since (a) we decided to do this some time ago, and (b) testing this is easy. I attach the new einsteintoolkit.th for your convenience. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

3 3

Meeting Reminder / Release
by Frank Loeffler 21 Nov '10

21 Nov '10

Hi, First of all, this is a reminder of tomorrows meeting, Monday November 22nd, 10am central USA time. Instructions can, as always, be found here: http://einsteintoolkit.org/info/support/ The main topic will be the release. The current state is described below. Other than that we should (after the release) try to get all those waiting patches applied, but with as less pain as possible. It would especially be nice to summarize and review the changes in the GRHydro branch before merging. Also, EOS_Omni should, again after review, be included in the development ET version. This especially will need some testsuite magic, when the older EOS interfaces will be removed. Before all that can happen however, there is the still pending release. The current state can be seen on our wiki page: http://docs.einsteintoolkit.org/et-docs/Release_Details In case this is not clear to everyone: we are in 'deep freeze'. Nothing at all should be changed without agreement by either Erik Schnetter or me, with the exception of the few development branches. We didn't manage to fix the two main outstanding testsuite issues, but as far as I can tell we managed to convince ourselves that they are not serious enough to further hold up this release. At the same time I would like to make both (GRHydro/ppm and AHFinderDirect/Interpolator) blocker for the next release. Either we fix the testsuites, or the code. We should not release yet another time with both problems. Opinions? The release branches have been created, and the corresponding thornlist was adapted and tested. The release texts are written (see links on wiki), and the citation list is done (please everyone have a look and comment, we should not forget something here): http://einsteintoolkit.org/info/citing/ I don't see something holding up the release, and would like to use the phone call for the last and final 'go' from everyone. What still needs to be done: - check documentation once again - especially links containing the ET version: they should be updated to the new version -> ET web page, tutorials, wiki - send the release announcement (texts are already on the wiki) -> users(a)einsteintoolkit.org, {news|users}(a)cactuscode.org, Kristen Sunde <ksunde(a)cct.lsu.edu> for AllCCT, http://hyperspace.aei.mpg.de/, http://astro-sim.org/ News-item on the cactuscode.org web page anything else? - anything else? However, I will personally not be able to make the call this week. Erik Schnetter will chair the call instead. Frank Loeffler

1 0

move of perl development version
by Frank Loeffler 20 Nov '10

20 Nov '10

Hi, In order to get an easy new release of the ET, I rearranged the simfactory repository a (little) bit: Past state (only listing the perl version): Version 1: in / Version 2: in /trunk Version 2 was a copy of version 1 at a certain point, but never got updated. Everyone checking out / on the other hand got everything, including all branches - which made this quite big. Current state (again, only listing perl): Version 1: in /trunk The old /trunk version got deleted and the old version in / got moved to /trunk, which leaves it's history intact. So, what happens now if a checkout of the old perl-simfactory (/) is updated: - All (unchanged, versioned) files directly in simfactory/ will be gone (e.g. not udp.pm, which isn't versioned). - The files you are looking for are now in simfactory/trunk, so in order to get your checkout working again, do: - save udb.pm (and any other locally changed/created files, check with 'svn status') - rename the old 'simfactory' directory (move to backup, delete later) - do a new checkout: svn co https://svn.cct.lsu.edu/repos/numrel/simfactory/trunk \ simfactory - move all saved files to their old location in the new checkout The usual 'switch relocate' will probably not work / be more complicated than this, especially with local changes. Frank Loeffler

1 0

Keeping example parameter files up to date
by Erik Schnetter 20 Nov '10

20 Nov '10

While we are testing the test cases before the release, it occurs to me that we should also keep the example parameter files up to date. I have no good idea for doing so, but e.g. trying to start a Cactus run and seeing whether it passes parameter checking could be a first step. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

McLachlan test suite failures
by Ian Hinder 17 Nov '10

17 Nov '10

Hi, I have solved the mystery of why the McLachlan test suites were failing on Kraken. The root cause of the problem was, again, the fact that the Exact thorn which sets up the gauge wave initial data calculates the extrinsic curvature imprecisely. The way the Exact thorn works is that the 4-metric is given in the code and is then finite differenced with a 2nd order accurate centered difference to compute the extrinsic curvature. It does not use the analytic derivatives. In order to make this accurate, a small step size, eps = 1e-6, is chosen for the finite differencing. Unfortunately, this small value means that g(t+eps) and g(t-eps) are very similar to each other, and when they are subtracted from each other, the least significant bits in g become very significant in K. As Peter pointed out, this can be many orders of magnitude. So an error of 1e-15 caused by roundoff differences due to compilers, math libraries, etc in g can lead to an error of 1e-11 in K. This is exactly what was happening with the McLachlan test suite. kxx on the initial data, which has a maximum value of ~ 0.2, had differences between the test suite result and Kraken of O(1e-11). This led to a similar difference in the BSSN RHS computation, and from iteration 0 to iteration 1, the difference in gxx jumped 4 orders of magnitude. To avoid this problem, Erik wrote a patch to implement fourth order accurate finite differencing in Exact. The idea is that you can get the same truncation error in the computation of K by using a higher order scheme with a larger step size. Since you are subtracting numbers which are not so similar to each other, the cancellation above does not occur, and roundoff errors are not amplified. I have tested the patch with the gauge wave initial data by computing kxx with order = 4 and eps = 1e-1, 1e-2, 1e-3 and 1e-4. The convergence with eps is 4th order, and a Richardson extrapolation reveals that the 1e-4 result has an error which is O(1e-15); i.e. using order = 4 and eps = 1e-4 for this initial data yields a result for kxx which is correct up to roundoff error. I attach a plot of the difference in gxx beween using order = 2, eps = 1e-6 and using order = 4, eps = 1e-4 between my laptop and Kraken. We see that after the initial data, the difference jumps from 1e-15 to 1e-12 with order = 2, eps = 1e-6, whereas with order = 4, eps = 1e-4, the difference remains small. Since we are close to a release, Erik doesn't want to commit his patch at this point. We understand why the McLachlan tests fail on kraken, and I have verified that with the patch, they can be made to pass. After the release, we will commit Erik's patch and modify the test suites to use it. We are not sure how to proceed in general with Exact. It is not clear that a single value of eps is suitable for all of the models in Exact. The current patch could be improved to perform a Richardson extrapolation to estimate the error, but it is then not clear how to reliably calculate the relative error that we need to minimise. -- Ian Hinder ian.hinder(a)aei.mpg.de

2 1

Meeting minutes
by Roland Haas 17 Nov '10

17 Nov '10

Meeting minutes: Present were: Frank, Roland, Bruno, Christian, Ian, Erik Testsuites * AHFinderDirect/AEILocalInterp: Carpet/mercurial with full grid gives identical results on 1 or 2 processors, PUGH with bitant grid does not. This points to PUGHInterp to be th culprit. However Ian sees differences when using Multipole and Carpet as well (for 32 processors). This points to the symmetry handling in AEILocalInterp being the culprit. * we will use an EVO meeting to coordinate fixing this bug (see Frank's email from earlier today) * PPM related failures: might be that tolerance of testsuites is too low * will release no later than Friday even if these two bugs remain since they were already present in the current release * ML failures: seem to be tolerance related, raising the tolerance should fix this Citations * will sent email to users and Cactus mailing lists to get input from thorn authors as to which papers to cite * will prepare html version of bibtex file for website 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.

4 3

Improve finite differencing in Exact
by Erik Schnetter 16 Nov '10

16 Nov '10

The enclosed patch improves the finite differencing that is used in Exact to calculate the extrinsic curvature. These finite differences are independent of the Cactus grid spacing. This is prompted by a remark by Peter Diener that the current finite differencing accuracy for the extrinsic curvature from thorn Exact is only about nine digits. It introduces new parameters "exact_order" and "exact_eps" that choose the order (2nd or 4th) and stencil size (default 1e-6). It also introduces new functions Exact__metric_deriv and Exact__metric_deriv2 that evaluate these finite differences. Some finite differencing terms for the spatial derivative of the shift have to be rewritten, which may lead to differences on the order of the finite differencing accuracy. The code could be rewritten to evaluate each stencil point only once in all calls to the new finite differencing operators. This would reduce the number of evaluations. Since thorn Exact is often very fast, this does not seem necessary at this point. Unfortunately, this patch causes five of the AHFinderDirect test cases to fail. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

2 2

[evosupport@vrvs.org: EVO Booking : ET bug squash party from Mon, 15 Nov 10 10:00 -0600 (CST)]
by Frank Loeffler 15 Nov '10

15 Nov '10

Let's use EVO to coordinate fixing bugs in the upcoming ET release. Frank ----- Forwarded message from evosupport(a)vrvs.org ----- DATE: Mon, 15 Nov 10 10:02:18 -0600 From: evosupport(a)vrvs.org To: knarf(a)cct.lsu.edu Subject: EVO Booking : ET bug squash party from Mon, 15 Nov 10 10:00 -0600 (CST) Content-Type: multipart/mixed; boundary="_EV0_iCal_Attachment_1289836800000_" Hello Frank L?ffler, You have BOOKED a meeting in EVO (http://evo.caltech.edu). Title: ET bug squash party Description: Community: Universe Meeting Access Information: - Meeting URL http://evo.caltech.edu/evoNext/koala.jnlp?meeting=M2MvMB2v2lDeDn9v9nDM92 - Phone Bridge ID: 255 5678 Central Standard Time (-0600) Start 2010-11-15 10:00 End 2010-11-16 23:30 Japan Standard Time (+0900) Start 2010-11-16 01:00 End 2010-11-17 14:30 Central European Time (+0100) Start 2010-11-15 17:00 End 2010-11-17 06:30 Eastern Standard Time (-0500) Start 2010-11-15 11:00 End 2010-11-17 00:30 Pacific Standard Time (-0800) Start 2010-11-15 08:00 End 2010-11-16 21:30 EVO Phone Bridge Telephone Numbers: --------------- - USA (Caltech, Pasadena, CA) +1 626 395 2112 - Switzerland (CERN, Geneva) +41 22 76 71400 - Slovakia (UPJS, Kosice) +421 55 234 2420 - Italy (INFN, several cities) http://server10.infn.it/video/index.php?page=telephone_numbers Enter '4000' to access the EVO bridge - Germany (DESY, Hamburg) +49 40 8998 1340 - USA (BNL, Upton, NY) +1 631 344 6100 - United Kingdom (University of Manchester) +44 161 306 6802 - Australia (ARCS) +61 Adelaide 08 8463 1011 Brisbane 07 3139 0705 Canberra 02 6112 8742 Hobart 03 623 70281 Melbourne 03 8685 8362 Perth 08 6461 6718 Sydney 02 8212 4591 - Netherlands (Nikhef, Amsterdam) +31 20 7165293 Dial '2' at the prompt - Canada (TRIUMF, Vancouver) +1 604 222 7700 - Czech Republic (CESNET, Prague) +420 95 007 2386 - USA (MIT, Cambridge, MA) +1 617 715 4691 - France (RAP, Paris) +33 144 27 81 50 --------------- If you would like to add a telephone bridge at your institute, please contact EVO at evocontact(a)vrvs.org BEGIN:VCALENDAR VERSION:2.0 PRODID:-//evo.caltech.edu/NONSGML EVO V1.0//EN METHOD:PUBLISH BEGIN:VEVENT CREATED:20101115T160218Z UID:20101115T160000Z-42802-255567-@evo.caltech.edu SUMMARY:ET bug squash party DESCRIPTION:Meeting Access Information:\n- Meeting URL\nhttp://evo.caltech.edu/evoNext/koala.jnlp?meeting=M2MvMB2v2lDeDn9v9nDM… \n- Phone Bridge\nID: 255 5678\n\nEVO Phone Bridge Info: http://evo.caltech.edu/evoGate/telephone.jsp URL:http://evo.caltech.edu/evoNext/koala.jnlp?meeting=M2MvMB2v2lDeDn9v9nDM92 LOCATION:Universe Community CATEGORIES:EVO Virtual Meeting CLASS:PUBLIC DTSTART:20101115T160000Z DTEND:20101117T053000Z DTSTAMP:20101115T160218Z END:VEVENT END:VCALENDAR ----- End forwarded message -----

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users November 2010