Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

4th order finite differencing in Exact
by Erik Schnetter 23 Nov '10

23 Nov '10

I have just committed the patch that implements 4th order finite differencing in Exact. Thorn Exact uses finite differencing to calculate the extrinsic curvature. This feature (which is disabled by default) can lead to a much more accurate extrinsic curvature. We can now think about enabling this by default; at the moment I cannot see any ill effect from this. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

ReflectionSymmetry, tensor tags, ML_BSSN, etc.
by John Baker 23 Nov '10

23 Nov '10

Hi, We've run into some problems recently with our evolution code, which boil done to the fact that we'd developed the code to support the sort of reflection symmetry defined in cartgrid3d, but recently started working with other thorns which are expecting the use of ReflectionSymmetry to define reflection symmetries. I assume that the motivation for this transition was to support more general grids, multipatch codes, etc, but I haven't found any documentation for the ReflectionSymmetry thorn, or any explanation of its use. One likely problem we are having is that we haven't applied any tensor-related tags in our interface.ccl, and rumor has it around here that ReflectionSymmetry relies on these tags. Presumably there are other EinsteinToolkit thorns which rely on tensor tags as well. I did find one document giving some explanation of tensor tags http://cactuscode.org/documentation/CoreDoc.pdf (thanks Erik). Erik outlines a number of potential tags there, but I would like to know which of these are required to support interaction which the various thorns in the toolkit? Looking at various other interface.ccl files, there didn't seem to be a high degree of consistency about which tags are set. Some also naively appear to be set incorrectly, in ML_BSSN. For instance: CCTK_REAL ML_trace_curv type=GF timelevels=3 tags='tensortypealias="Scalar" tensorweight=1.0000000000000000000' { trK } "ML_trace_curv" Which seems to declare the trK to be a tensor density. If this is indeed wrong, and no one has noticed, then I infer that tensorweight may not really be used by anything important. If anyone can clarify these issues for me I would appreciate it. Thanks, John.

3 5

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users