Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Meeting reminder
by Frank Loeffler 12 Jul '10

12 Jul '10

Hi, this is a short reminder about the regular EinsteinToolkit phone call later today (at 10am CDT). Instructions how to join the call can be found here: http://einsteintoolkit.org/info/support/ Frank Loeffler

2 1

Patch: add hydro variables support for the CactusNumerical/Noise thorn
by David Radice 09 Jul '10

09 Jul '10

Dear all, in order to use the CactusNumerical/Noise thorn to perform a stress test on the hydro equations "id_noise" has to be properly scheduled with respect to HydroBase_Initial and HydroBase_Prim2ConInitial. As it is now numerical perturbation on the hydro variables could be discarded / overwritten. The attached (trivial) patch fixes the above mentioned issue and includes some small aesthetic fixes. Could you please consider applying it to the development branch of the Einstein Toolkit? Thanks, David PS: note that the hydro thorn has to schedule Prim2Con in HydroBase_Prim2ConInitial otherwise the perturbation are simply ignored/overwritten. -- 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

3 2

Einstein Toolkit Presentation at GR19
by Erik Schnetter 06 Jul '10

06 Jul '10

Dear Einstein Toolkit Users I will give a presentation on the Einstein Toolkit at the GR19 conference <http://www.gr19.com> in session B2 "Numerical Relativity and Astrophysical Applications". I will speak on Thursday at 14:30 in room 1 (the plenary room). I believe the schedule on the web site is outdated -- please look for on-site schedules that should be more accurate. Title: The Einstein Toolkit Authors: Erik Schnetter for the Einstein Toolkit Consortium We introduce the Einstein Toolkit, a collection of software components and tools for simulating and analyzing general relativistic astrophysical systems. Such systems include gravitational wave space-times, collisions of compact objects such as black holes or neutron stars, accretion onto compact objects, core collapse supernovae and Gamma-Ray Bursts. This toolkit is developed as open software for relativistic astrophysics. Our aim is to provide the core computational tools that can enable new science, broaden our community, facilitate interdisciplinary research and take advantage of emerging petascale computers and advanced cyberinfrastructure. We believe that this toolkit can also be constructively used in teaching numerical relativity courses, and can help "getting started" in numerical relativity research. The Einstein Toolkit builds on numerous software efforts in the numerical relativity community including CactusEinstein, Whisky, and Carpet. The Einstein Toolkit currently uses the Cactus Framework as the underlying computational infrastructure that provides large-scale parallelization, general computational components, and a model for collaborative, portable code development. We give a brief overview over the toolkit, its goals, and its current state, and show examples of scientific results obtained by various research groups employing this toolkit as basis of their research codes. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

Benchmark parameter files?
by Erik Schnetter 02 Jul '10

02 Jul '10

For various occasions it is nice to have HPC benchmark parameter files. This could be for comparing different TeraGrid systems, or could be for evaluating workstations or clusters that one wants to buy. It would be convenient to have a few "standard" Einstein Toolkit benchmarks available. If you have run such benchmarks in the past, would you mind sending your corresponding parameter files around, or adding them to the wiki? I'm not interested in the details, but rather in what features people considered important in such benchmarks. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

GetComponents doesn't handle repository declarations without thorns
by Erik Schnetter 01 Jul '10

01 Jul '10

I had the following lines in my thorn list: # Private thorns !TARGET = $ARR !TYPE = ignore !CHECKOUT = Note that the checkout item is empty. GetComponents reports two errors: $ utils/Scripts/GetComponents --update --root=. manifest/einsteintoolkit.th Odd number of elements in hash assignment at utils/Scripts/GetComponents line 335. Use of uninitialized value in split at utils/Scripts/GetComponents line 441. It should instead either report an error, or handle the case of a repository without thorns correctly. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

2 2

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users