Users July 2010

users@lists.einsteintoolkit.org

14 participants
16 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

patch for EinsteinAnalysis/AHFinderDirect
by Bruno Giacomazzo 09 Aug '10

09 Aug '10

Hi, the attached patch allows the possibility to schedule AHFinderDirect also at POSTPOSTINITIAL by adding the parameter run_at_CCTK_POSTPOSTINITIAL (default equals to false). I have used it to be sure that an AH was found after initial data computation and before the last call to the Con2Prim routine of Whisky before evolution was started (in order to have hydro variables properly excised before the beginning of the evolution). Cheers, Bruno Dr. Bruno Giacomazzo Department of Astronomy University of Maryland College Park MD 20742-2421 USA Tel. : +1 301 405 0676 Fax : +1 301 314 9067 Tel. : +1 301 286 3809 (NASA/GSFC) Fax : +1 301 286 7230 (NASA/GSFC) Cell. : +1 443 535 5846 email : bgiacoma(a)astro.umd.edu web: http://www.brunogiacomazzo.org ---------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ----------------------------------------------------------------------

2 1

Carpet developer workshop at RIT on Aug 23-25
by Bruno Coutinho Mundim 02 Aug '10

02 Aug '10

Dear Colleagues, We would like to invite you to attend a Carpet developer workshop to be hosted by the Center for Computational Relativity and Gravitation at the Rochester Institute of Technology on August 23th, 24th and 25th (2010). This workshop is aimed at experienced Carpet users that want to gain further expertise on the internal workings of the Carpet driver, and, thereby, to be able to contribute to the infrastructure development. This workshop will be led by Erik Schnetter, the main architect for the Carpet AMR infrastructure, and will count with the presence of an HPC specialist. One important goal of this workshop will be to discuss and implement ways to improve the performance for Cactus-based applications for current and future high-end petascale architectures. Due to space limitations, we encourage you to contact the organizers as soon as possible to register your presence. Sincerely, The organizers: Manuela Campanelli (manuela(a)astro.rit.edu) Bruno C. Mundim (bcmsma(a)astro.rit.edu) Erik Schnetter (schnetter(a)cct.lsu.edu)

1 1

prim2con in HydroBase_Prim2ConInitial
by Frank Loeffler 29 Jul '10

29 Jul '10

Hi, GRHydro currently does not convert the primitive variables the ID thorns populate to the conserved quantities. However, since poststep is now scheduled also for initial data, it converts the conserved quantities to the primivite ones before evolution. This means ID thorns have to setup the conserved quantities to make this work. Currently e.g. TOVSolver does this, but it really should not. HydroBase defines a group HydroBase_Prim2ConInitial exactly for this purpose: to have any evolution thorn scheduling prim2con routines it might need to use ID given in only primary variables defined in HydroBase. GRHydro does not schedule anything there. I suggest to schedule the corresponding GRHydro prim2con routines in this group. I tried this and all testsuites still pass - but ID thorns no longer have to specify the conserved quantities anymore. Are there objections? Frank

1 0

simfactory: adding new machine?
by Bernard Kelly 29 Jul '10

29 Jul '10

Hi all. I'm trying out einsteintoolkit + simfactory on a non-standard machine, and am failing rather quickly. I followed the simfactory tutorial advice: https://svn.cct.lsu.edu/repos/numrel/simfactory/tutorial/index.html ... which said to edit the section of udb.pm entitled "Customize your local machine here". Since this heading no longer appears, I imagine the tutorial is slightly out of date. Anyway, changing "Options for new machines" along these lines doesn't seem to work -- if I run ./sim, I get the following error message: ------------------------ Uncaught exception from user code: Wile setting user option [discover][nickname]="discover": Machine "discover" does not exist at udb.pm line 123. ------------------------ What's the proper method for adding a new machine? Do I actually have to add to the "mdb.pm" file? Thanks, Bernard -- ----------------------------------------------- Bernard J. Kelly NASA Goddard Space Flight Center, Code 663 8800 Greenbelt Road Greenbelt, MD 20771, U.S.A. phone: +1 (301) 286-7243 -----------------------------------------------

4 4

Meeting minutes
by Roland Haas 26 Jul '10

26 Jul '10

Meeting minutes: Present were: Frank, Roland, Gabrielle, Bruno, Ian, Eloisa * Frank reported on patches applied to the release version of the toolkit * we agreed to use EOS_Omni in the current set of initial data tests * a partial list of thorns/modules for which there are papers to be cited is: ** Kranc ** Carpet ** AHFinderDirect ** Cactus flesh ** TwoPunctures ** GRHydro (citing the Whisky paper on whiskycode.org) ** McLachlan * a draft of the citation policy has been send to the maintainers and will have to be discussed on the mailing list * Gabrielle will draft a website to list these publications We have one item for next the meeting/mailing list discussions: * decide on dates/locations for toolkit workshops/conferences 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 0

Meeting reminder
by Frank Loeffler 19 Jul '10

19 Jul '10

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

2 1

EOS_Omni
by Christian D. Ott 19 Jul '10

19 Jul '10

Dear All, you can give the new EOS for GRHydro a try by recompiling with -DUSE_EOS_OMNI in CPPFLAGS and FPPFLAGS. This makes GRHydro _independent_ of EOS_Base and all EOS thorns except EOS_Omni (dependence via aliased functions). Let's say you want to evolve a Gamma=2 polytrope with K=100 with a gamma-law. For this, you would set: ActiveThorns = "EOS_Omni" grhydro::grhydro_poly_eoskey = 1 grhydro::grhydro_eoskey = 2 eos_omni::gl_gamma = 2.0 eos_omni::gl_k = 100.0d0 eos_omni::poly_gamma = 2.0 eos_omni::poly_gamma_ini = 2.0 eos_omni::poly_k = 100.0d0 Note that gl_ controls the gamma-law settings and that poly settings are still needed (for fallback purposes in GRHydro if c2p fails). Without the preprocessor defines, the code behaves as usual and is wedded to EOS_Base and EOS_Polytrope. All test suites pass. A test suite using EOS_Omni has been added. If EOS_Omni is activated and EOS_Omni parameters are added, all standard testsuites pass. This confirms that EOS_Omni produces the same results as EOS_Base + EOS_Polytrope/EOS_Ideal_Fluid/EOS_Hybrid. Currently, finite-temperature EOS support is lacking. This requires messing with various routines in GRHydro to include temperature in calls etc. This will be the next step in the EOS_Omni development. Since EOS_Omni already provides the entire functionality of the EOS_Base interface, I would suggest to remove this old interface from the code soon (once people have tried out and are happy with EOS_Omni). Please report any problems you may find with EOS_Omni. Best, - Christian

5 10

CarpetIOHDF5: checkpoint initial data
by Baiotti Luca 19 Jul '10

19 Jul '10

Hello, I found a minor unexpected behaviour (or at least inaccurate error message) of CarpetIOHDF5. When setting among other parameters: Cactus::terminate = time Cactus::cctk_final_time = 0.0 IO::checkpoint_on_terminate= yes IO::checkpoint_ID = no the below message is printed: "INFO (CarpetIOHDF5): Termination checkpoint already dumped as last evolution checkpoint at iteration 0" but no checkpoint is dumped. I would think that the checkpoint should be dumped with this choice of parameters, but this is just my point of view. Anyway, the info message is wrong. Luca

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users July 2010