Users October 2010

users@lists.einsteintoolkit.org

15 participants
33 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

[trac-noreply@einsteintoolkit.org: [Einstein Toolkit] #69: Formaline might stop build because of errors reported by tar]
by Frank Loeffler 01 Nov '10

01 Nov '10

Hi, I forward the following trac message to the users mailing list to start a discussion on this issue, but to have the issue recorded in trac at the same time. Frank ----- Forwarded message from Einstein Toolkit <trac-noreply(a)einsteintoolkit.org> ----- #69: Formaline might stop build because of errors reported by tar --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2010_11 Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- Beginning with version 1.16 of gnu tar: <quote> After creating an archive, tar exits with code 1 if some files were changed while being read. Previous versions exited with code 2 (fatal error), and only if some files were truncated while being archived. </quote> Even reading a file (as is done when compiling it in parallel) will change it in tar's view, because this changes the atime of the file. There does not seem to be an option which turns this new behavior off. Instead it is recommended to check the exit code of tar which is 0: if everything went ok 1: if files changed while being read/written 2: if some other error occurs. This means that Formaline should treat an exit code of 1 in tar as 'ok', while currently it aborts the build. However, this is safely true only for gnu tar. For example the version of tar on the 'pelican' system states: <quote> 0 Successful completion. >0 An error occurred. </quote> This is too vague to decide if ignoring an exit code of 1 can also here be ignored. File changes are a kind of error - of a kind one might be able to ignore. The documentation of this old version of tar doesn't mention which values are actually used for which errors though. Somewhere else I found [http://aplawrence.com/Bofcusm/2073.html this]: <quote> 0 - success 1 - bad directory tree, failed to extract a requested file, input file same as output file, failed to open input file, could not create link, link table malloc failure 2 - internationalization error that should never occur, checksum error 5 - checksum error 9 (EBADF) - error reading /etc/default/tar, misplaced end of volume </quote> So, it is probably not safe to assume that an exit value of 1 always means 'success' for any version of tar, in the case of Formaline. How should we proceed with Formaline? The current state is not desirable. As far as I can see we have two options: 1) Assume that an exit value of 1 to be a 'success'. I do have a patch for this. 2) Test for gnu tar and only then assume 1) Opinions? ----- End forwarded message -----

2 5

Reminder weekly call, Monday Nov 1st
by Frank Loeffler 01 Nov '10

01 Nov '10

Hi, The next weekly Einstein Toolkit telecon will be today: Monday, Nov 1st, 10am central US time. The main topic will be the preparation of the new ET release. It's main blocker is the current testsuite status: - You can find information about how to run the testsuites in a more or less automatic way on the web page [2], where you can also find the current status [3]. - I can see four main points which need to be addressed: - IDScalarWaveElliptic/test_waveell and WaveBinarySource/test_binary_1 seem to fail on every platform. - Some GRHydro testsuites seem to fail with a gcc compiler, pointing to ppm. - A lot of testsuites fail on multiple processors, especially from AHFinderDirect. - We don't yet have current results from a nice collection of machines. Of course we will also discuss everything which came up since last time if it's not releated to the release. As usual, find the instructions for the call on the ET web pages [1]. Frank Loeffler [1] http://einsteintoolkit.org/info/support/ [2] http://einsteintoolkit.org/release-info/ [3] http://einsteintoolkit.org/release-info/parse_testsuite_results.php

1 1

[cott@tapir.caltech.edu: [Commits] [svn:einsteintoolkit] GRHydro/branches/hot_and_MHD_temp_dev/ (Rev. 165)]
by Christian D. Ott 31 Oct '10

31 Oct '10

Hi All, after talking with Frank, I have just created a temporary branch of GRHydro for finite-T and MHD development while trunk is being readied for release. Please do any development work in branch hot_and_MHD_temp_dev. We'll merge this branch with trunk once the release has happened. Best, - Christian ----- Forwarded message from cott(a)tapir.caltech.edu ----- To: commits(a)einsteintoolkit.org From: cott(a)tapir.caltech.edu Date: Sun, 31 Oct 2010 16:04:51 GMT Subject: [Commits] [svn:einsteintoolkit] GRHydro/branches/hot_and_MHD_temp_dev/ (Rev. 165) User: cott Date: 2010/10/31 11:04 AM Added: /branches/hot_and_MHD_temp_dev/ Log: * create a temporary branch "hot_and_MHD_temp_dev" for development while trunk is being readied for release _______________________________________________ Commits mailing list Commits(a)einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/commits ----- End forwarded message -----

1 0

Testsuite status page and scripts
by Frank Loeffler 30 Oct '10

30 Oct '10

Hi, I created a (still) short page, linking two scripts which help downloading, compiling and running the testsuites and (also only shortly) explain where to upload the log files to. http://einsteintoolkit.org/release-info/ Frank Loeffler

2 2

Re: [Users] [Commits] [svn:einsteintoolkit] www/release-info/ (Rev. 346)
by Bruno C. Mundim 29 Oct '10

29 Oct '10

Shouldn't we keep the logs for each release? or at least for the previous one? Thanks, Bruno. knarf(a)cct.lsu.edu wrote: > User: knarf > Date: 2010/10/29 09:21 AM > > Added: > /release-info/ > bright.png, dark.png > > Modified: > /release-info/ > numrel__1.log, numrel__2.log, parse_testsuite_results.cgi, philip__1.log, philip__2.log > > Log: > new results, parse new output > > File Changes: > > Directory: /release-info/ > ========================= > > File [added]: bright.png > Delta lines: <Unavailable> > > File [added]: dark.png > Delta lines: <Unavailable> > > File [modified]: numrel__1.log > Delta lines: <Unavailable> > > File [modified]: numrel__2.log > Delta lines: <Unavailable> > > File [modified]: parse_testsuite_results.cgi > Delta lines: <Unavailable> > > File [modified]: philip__1.log > Delta lines: <Unavailable> > > File [modified]: philip__2.log > Delta lines: <Unavailable> > > _______________________________________________ > Commits mailing list > Commits(a)einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/commits

2 3

HydroBase: temperature_evolution_method
by Christian D. Ott 28 Oct '10

28 Oct '10

Hi, I would like to introduce a parameter temperature_evolution_method to HydroBase. Patch is attached. Okay to commit? - Christian

2 1

WeylScal4 testsuite
by Ian Hinder 28 Oct '10

28 Oct '10

Hi, I would like to remove thorn LocalReduce from the ActiveThorns line of the WeylScal4 test suites. It is not required and the tests pass without it. Any objections? [We don't use LocalReduce, and the WeylScal4 test suite was not being run with our thornlist because LocalReduce was not available.] -- Ian Hinder ian.hinder(a)aei.mpg.de

2 1

[cott@tapir.caltech.edu: Re: GRHydro: explicit evolution of the electron fraction]
by Christian D. Ott 25 Oct '10

25 Oct '10

----- Forwarded message from "Christian D. Ott" <cott(a)tapir.caltech.edu> ----- Date: Mon, 25 Oct 2010 12:43:00 -0700 From: "Christian D. Ott" <cott(a)tapir.caltech.edu> To: Frank Loeffler <knarf(a)cct.lsu.edu> Subject: Re: [Users] GRHydro: explicit evolution of the electron fraction Hi Frank, On Mon, Oct 25, 2010 at 02:35:27PM -0500, Frank Loeffler wrote: > > I don't object, assuming that this can be disabled, and is by default. > > As to the timing: please wait with this change until after the > next release of the ET (which should happen soonish)? MHD is currently under heavy development. Is this really the time for a release? Sorry that I could not join today's call. I was on an airplane. - Christian ----- End forwarded message -----

2 2

GRHydro: explicit evolution of the electron fraction
by Christian D. Ott 25 Oct '10

25 Oct '10

Hi, in the process of making GRHydro work out of the box with microphysical EOS, I would like to introduce the electron fraction Y_e (a HydroBase variable) as a variable that is explicitly evolved via a conserved variable consY_e = dens * Y_e by GRHydro (by setting Y_e_evolution_method = "GRHydro"). Previously, Y_e was evolved as the first of the advected scalar tracers. This is currently broken, since Y_e in HydroBase and the first tracer are not mapped to on another. The tracer variables will (in the future) be needed to consistently evolve mass fractions of various elements (for use in a low-density EOS and in a nuclear reaction network) that must sum up to one without Y_e. Moreover, in nuclear statistical equilibrium, Y_e is the only compositional variable needed. Hence, it makes sense to promote Y_e to special status. Please speak up if you have objections. - Christian

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users October 2010