Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

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

Meeting minutes
by Roland Haas 25 Oct '10

25 Oct '10

Meeting minutes: Present were: Frank, Tanja, Roland, Bruno, Ian, Peter * MHD: testing is taking place, all are encouraged to try and run the hydro-tests in GRHydro using the MHD codebase and Bvec=0 * we originally wanted to release a new version of the toolkit this week. We will start the process be running the testsuites using the current codebase to see where we might have to fix things. * TS assignments (results to be posted on the website/wiki. Frank will send around a reminder email with more details): ** Ranger: Tanja ** Queenbee: Peter ** Damiana, Kraken: Ian ** Bluedrop: Bruno * no news on citation policy 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 minutes
by Roland Haas 25 Oct '10

25 Oct '10

Meeting minutes: Present were: Erik, Gabrielle, Chrisitna, Frank, Peter, Ian, Yosef, Tanja, Roland Citation policy: * see attached draft * will put list of requested citations on the wiki * will create a "cheat sheet" for maintainers for releases * will announce trac bug tracker (http://trac.einsteintoolkit.org) on the users mailing list 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

Reminder weekly call, Monday Oct 25
by Frank Loeffler 25 Oct '10

25 Oct '10

Hi, The next weekly Einstein Toolkit telecon will be today: Monday, Oct 25th, 10am central US time. We will mainly catch up with everything that has been done during the last week: - MHD progress - new EOS - ...? As usual, find the instructions for the call on the ET web pages [1]. Frank Loeffler [1] http://einsteintoolkit.org/info/support/

1 0

Re: [Users] using WeylScal4 and Multipole for WF output -- scheduling issues
by Ian Hinder 23 Oct '10

23 Oct '10

On 21 Oct 2010, at 20:58, Bernard Kelly wrote: > Hi all. > > I'm trying some GW extraction from a Carpet/McLachlan black-hole > binary evolution. I thought the combination of thorns WeylScal4 and > Multipole would give me something reasonable, but I'm having trouble > with it. > > I'm attaching a parameter file for my run. As you can see, the > extraction is supposed to be over a set of coordinate spheres at > radii 45, 50 55, 60 65, & 70. > > What I get is NaN in the WFs at all timesteps after t=0. I'm also > outputting 2D data (though not as frequently), and Psi4 seems well- > behaved. So what's going wrong? > > I have noted that though the routine "Multipole_Calc" should happen > after "calc_np" according to its schedule.ccl, it appears -before- > GROUP WeylScal4_Calculate in the run's initial printing of scheduled > routines. Could you post the schedule output? According to the copy of the code that I have from the release version, Multipole_Calc is called in ANALYSIS and WeylScal4_Calculate is called in MoL_PseudoEvolution, which is called in EVOL (and some other places). The calc_np is a relic from when both were called in ANALYSIS. > Suggestions appreciated, I tried to run your parameter file to test, but unfortunately I have some work-in-progress hacks to my local copy of WeylScal4, so it didn't run. Nevertheless, I think I know what the problem is. The spatial triad used by WeylScal4 is a coordinate triad (d/dph, d/dr, d/ dth), suitably orthonormalised. This triad is singular on the z axis, and the way it is computed there leads to a NaN. When you compute spherical harmonic modes, points on the z axis (th = 0) are multiplied by sin(th) = 0, so the value on the axis is never used, but numerically the NaN still causes problems. There are several approaches to this: 1. Replace the triad at that point with a different one. This way, Psi4 on th = 0 is still "Psi4", just with respect to a different tetrad at that point. This is probably the best approach, and I have it implemented in my local copy. I can commit this to the development version. 2. Use an open integration formula on (0,Pi) on the 2-sphere when doing the mode decomposition. This means that the point at th = 0 is not used. Multipole does not do this, but it wouldn't be too hard to modify it. 3. Do a numerical trick to make sure that the point at th = 0 doesn't have a NaN. The particular trick I usually use is to offset the coordinates used to construct the spatial triad by 10^-15 in one direction. WeylScal4::offset = 1e-15 This is what I did before I implemented the triad change on the axis. What do other people do to get around this problem? Would some more physical tetrad (e.g. quasi-Kinnersley?) help? > P.S. Is this appropriate to einsteintoolkit, or Cactus at large? I'm > using the ET_2010_06 release ... WeylScal4 and Multipole are both part of the Einstein Toolkit (in the EinsteinAnalysis arrangement), so discussion is probably best on the ET list. I have CC'd this message to that list. Other comments about your parameter file: * You have asked for the mode decomposition of Psi4r and Psi4i individually, and you have not set the spin weight parameter, so it will default to 0, which is not what you want. Try Multipole::variables = "WeylScal4::Psi4r{sw=-2 cmplx='WeylScal4::Psi4i' name='Psi4'}" instead. This tells Multipole to use spin weight -2 for Psi4, and to treat Psi4r and Psi4i as the real and imaginary parts of a complex number. This means you don't have to recombine the modes of the real and imaginary parts by hand. WeylScal4 and Multipole could be modified to work with Cactus complex grid functions, but I don't have any experience with using them, and Kranc does not currently support them. * Your time_refinement_factors parameter is quite aggressive - you are using time refinement only for finest four levels. You can probably get away with time refinement for the last 6, or more depending on your finite differencing order and value of eta. * I recommend using the parameters TimerReport::out_every = 32 TimerReport::n_top_timers = 40 which will give you a quick overview of the parts of the code which are taking the most time. Apart from those points, the parameter file looks fine. -- Ian Hinder ian.hinder(a)aei.mpg.de

4 8

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users