Users June 2010

users@lists.einsteintoolkit.org

19 participants
61 discussions

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

fix WeylScal4::teukolskyID testsuite
by Roland Haas 09 Sep '10

09 Sep '10

Hello all, Ian Hinder found that the testsuite teukolskyID for WeylScal4 was poisoned. It turns out I had forgotten to add MoL to the list of ActiveThorns in the testsuite. Attached please find a patch which rectifies that. Ok to apply (both development and release branch)? Expect some more patches while Tanja and I try and add some extra statements to WeylScal4 to make sure MoL is present (ie. something like inherit from MoL maybe) and adapt to a possible future change in how MoL_PseudoEvolution is scheduled. Ian also pointed out some issues with how (outer hopefully) boundaries are handled which will have to be looked at eventually. Yours, Roland

4 9

Switching HDF5 to version 1.8.5
by Erik Schnetter 29 Jun '10

29 Jun '10

I would like to move the HDF5 library version in ExternalLibraries from 1.8.4 to 1.8.5. The HDF5 release notes state "Release 1.8.5 is the latest release of HDF5 1.8. New projects are strongly encouraged to use this release as it contains many new features, file optimizations, and performance enhancements." To my knowledge, both 1.8.4 and 1.8.5 contain performance enhancements for Lustre file systems. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

Updating GSL and HDF5 options in SimFactory
by Erik Schnetter 29 Jun '10

29 Jun '10

I want to update some GSL and HDF5 configuration options in SimFactory. I think this will help provide more recent version of these libraries. In the case of HDF5, this may lead to increased performance. Currently, many machine option lists point to version of GSL, HDF5, and other libraries that I (or others) installed on these systems. Typically, this happens when we begin to use a machine for the first time, or when the current installation breaks. This also means that this library is often outdated, e.g. at version 1.8.1 for HDF5 instead of the current 1.8.5. Since HDF5 1.8.4 and 1.8.5 have Lustre performance improvements, this may lead to less efficient code, unless I (or someone else) installs a more recent version on these systems, or when we ask the system administrators to do so. To simplify the situation, I suggest that we use the ExternalLibraries versions for these libraries. This would require people to use ExternaLibraries (which is already the case for the Einstein Toolkit). It would also slow down building from scratch, since these libraries have to be built. I have just tested the corresponding changes to SimFactory on various systems. We don't need to make this change for all systems at the same time, and I only want to ask the question in principle here: are people comfortable with building libraries such as GSL and HDF5 together with Cactus, if this guarantees that more recent versions of these libraries are used? (Of course, you are free to modify your option list locally to continue to use pre-installed libraries.) -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

Listing papers on the web site?
by Erik Schnetter 28 Jun '10

28 Jun '10

Should we collect papers describing Einstein Toolkit components on the web site? I'm thinking of papers such as the one describing AHFinderDirect or TwoPunctures. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

3 2

Phone call reminder
by Frank Loeffler 28 Jun '10

28 Jun '10

Dear users, This is a reminder about our weekly, public phone call at 10am central US time, today. Instructions how to connect to the call can be found here: http://einsteintoolkit.org/info/support/ Frank Loeffler

1 0

EOS interface
by Christian D. Ott 27 Jun '10

27 Jun '10

Dear all, in the process of implementing MHD Con2Prim I got thinking about the EOS interfaces (again). I propose a drastic simplification that will reduce generality dramatically, but will increase performance and flexibility. The idea is to create (and I have coded a test implementation) a EOS master thorn called EOS_Omni that provides aliased functions for single-variable calls, e.g., EOS_Omni_press EOS_Omni_DPressByDEps ... as well as a 'full' call EOS_Omni_hydro_full that returns _at once_ all vars relevant for hydro. Calls that return a certain set of variables (e.g., those needed by Con2Prim) would also be possible. I would be happy to implement and maintain this thorn and would also be willing to provide my finite-T microphysical EOS routines as part of it. EOS_Omni, being a master thorn, would implement all sensible EOS -- poly, gamma-law, piecewise poly, hybrid, hybrid-piecewise-poly, microphysical cold, and microphysical hot EOS. It would decide which EOS to use based on an integer 'eoskey' that is passed to it. This allows, e.g., to use a different EOS for the atmosphere than for the actual fluid (something that is impossible currently!). Currently, I have coded EOS_Omni with select case statements to switch between EOS and have the EOS hardcoded. This will maximize performance and will be much faster than using the current one-thorn-per-EOS approach with a EOS_Base thorn by minimizing function calls. In addition, EOS_Omni would take as input variables all needed for a nuclear-statistical equilibrium EOS (later to be extended to non-NSE EOS that depend on individual isotope mass fractions). In case a simple EOS analytic EOS is used, the compositional (Ye) and temperature information would just be ignored. A call would look like this: void FUNCTION EOS_Omni_press(CCTK_INT IN eoskey, \ CCTK_INT IN havetemp, \ CCTK_INT IN npoints, \ CCTK_REAL IN ARRAY rho, \ CCTK_REAL INOUT ARRAY eps, \ CCTK_REAL INOUT ARRAY temp, \ CCTK_REAL IN ARRAY ye, \ CCTK_REAL OUT ARRAY press, \ CCTK_INT OUT ARRAY keyerr \ CCTK_INT OUT anyerr) eoskey -- an integer specifying which EOS to use havetemp -- for finite-T: 0, coming in with eps; 1, coming in with temp npoints -- passing n datapoints rho -- obvious eps -- obvious temp -- temperature ye -- electron fraction press -- obvious keyerr -- integer array that contains error codes in case something went wrong anyerr -- .ne. 0 if there was any error So, as you can see, this could be used for pointwise as well as GF-wide calls. And one more thing: With the proposed aliased-function-based calls, it would still be possible to have thorns implementing a single EOS (e.g. a polytrope) provide EOS_Omni_* functions -- there could, of course, be only one such thorn active at a given time. Thoughts? - Christian

1 0

References in html thorn guide missing
by Erik Schnetter 26 Jun '10

26 Jun '10

Jonathan Thornburg noticed that the bibliography references in the html version of the thorn guide are missing. For example, the AHFinderDirect description contains referneces to [?]. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

4 4

Patch: allow custom LORENE_LIBS in optionlist
by David Radice 26 Jun '10

26 Jun '10

Hello, at the moment the compilation of EinsteinToolkit with LORENE fails if LORENE is configured to use FFTW as LORENE_LIBS does not contain fftw3. The attached patch solves the problem by allowing the user to overwrite LORENE_LIBS in the optionlist file. If LORENE_LIBS is not set then the old values are used, so that this modification should not break existing configurations where fftw3 could be not available. Could you please consider applying the attached patch to the LORENE thorn in the development branch? David -- David Radice Max Planck Institute for Gravitational Physics Albert Einstein Institute Am Muehlenberg 1 D-14476 Potsdam Germany Tel : +49 331 567 7242 Fax : +49 331 567 7499 Room : 1.64 E-Mail : david.radice(a)aei.mpg.de

2 5

GetComponents: Purely local thorns
by Erik Schnetter 25 Jun '10

25 Jun '10

How do I specify in a GetComponent thorn list that a thorn is purely local and cannot be obtained from a repository? I still want to include the thorn in the thorn list so that I can use this thorn list for building. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

3 9

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users June 2010