Users December 2010

users@lists.einsteintoolkit.org

18 participants
20 discussions

Completing GetComponents' transition to GitHub
by Eric Seidel 28 Dec '10

28 Dec '10

Hi, with the new release of the Einstein Toolkit complete, I think we can finally complete the transition of GetComponents to GitHub. This would involve two things. 1. Applying the attached patch to the ET trunk thornlist. It would just add the GetComponents GitHub repository, and symlink GetComponents into the root of the ET source tree. There was an issue with this previously, where the symlink did not work, but that was fixed a few months ago. 2. Deleting the svn version of GetComponents in utils/Scripts. There would be no functional changes to GetComponents as the two versions are mirrored, users would simply have to call GetComponents from the root directory now. Eric

4 15

GetComponents Delay
by Eric Seidel 23 Dec '10

23 Dec '10

Hi all, I want to apologize for the delay in fixing some issues with GetComponents; I know there are several outstanding tickets that have been open for over a month. I got really busy with schoolwork and just finished my semester a couple days ago. I will now turn my attention back to GetComponents. Eric

1 0

[Patch] allow direct calls to the Periodic thorn back-bone
by David Radice 22 Dec '10

22 Dec '10

Dear Einstein Toolkit users, some time ago I wrote a patch to allow external thorns to perform direct calls to the low-level Periodic API, as I needed to apply periodic conditions only on selected grid variables. I proposed this patch to Erik, who suggested to implement some improvements and to discuss it on the mailing list. After having implemented his suggestions, somehow I forgot to post the patch also here... The way in which it works is by simply moving the "logic" (handling of errors and parameters) into Periodic_ApplyBC to make BndPeriodicVI "thorn agnostic". Best, 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 4

Enhancements to Multipole
by Ian Hinder 22 Dec '10

22 Dec '10

Hi, I have three patches to Multipole: === 1. Convert to C++ strings 2. Use IO::out_dir parameter by sharing from implementation rather than via CCTK_ParameterGet 3. Add HDF5 output support One HDF5 file per variable, and one extensible dataset per radius per mode. HDF5 is required only optionally, so this thorn can be compiled without it === The advantage of the HDF5 output is that you get only one file per variable, instead of the hundreds that you get with the previous one file per variable per mode per radius format. Instead of using ASCII output, which is unindexed and very inefficient to parse, HDF5 output is structured and a single dataset can be easily read. Analysis tools such as Python and Mathematica support reading HDF5, and the h5dump or h5totxt utility (in the h5utils package) can be used to convert the file to text for any tool which can't read HDF5. Two new parameters are introduced: output_ascii (defaults to yes), and output_hdf5 (defaults to no). Example output (modes are the same for all t in this test case; columns are t, re(var), im(var)): $ h5ls mp_harmonic.h5 l0_m0_r8.00 Dataset {11/Inf, 3} l1_m-1_r8.00 Dataset {11/Inf, 3} l1_m0_r8.00 Dataset {11/Inf, 3} l1_m1_r8.00 Dataset {11/Inf, 3} l2_m-1_r8.00 Dataset {11/Inf, 3} l2_m-2_r8.00 Dataset {11/Inf, 3} l2_m0_r8.00 Dataset {11/Inf, 3} l2_m1_r8.00 Dataset {11/Inf, 3} l2_m2_r8.00 Dataset {11/Inf, 3} $ h5totxt -d l2_m2_r8.00 mp_harmonic.h5 0,1.009144071427338,1.00100865293711e-06 1,1.009144071427338,1.00100865293711e-06 2,1.009144071427338,1.00100865293711e-06 3,1.009144071427338,1.00100865293711e-06 4,1.009144071427338,1.00100865293711e-06 5,1.009144071427338,1.00100865293711e-06 6,1.009144071427338,1.00100865293711e-06 7,1.009144071427338,1.00100865293711e-06 8,1.009144071427338,1.00100865293711e-06 9,1.009144071427338,1.00100865293711e-06 10,1.009144071427338,1.00100865293711e-06 $ h5dump -d l2_m2_r8.00 mp_harmonic.h5 HDF5 "mp_harmonic.h5" { DATASET "l2_m2_r8.00" { DATATYPE H5T_IEEE_F64LE DATASPACE SIMPLE { ( 11, 3 ) / ( H5S_UNLIMITED, 3 ) } DATA { (0,0): 0, 1.00914, 1.00101e-06, (1,0): 1, 1.00914, 1.00101e-06, (2,0): 2, 1.00914, 1.00101e-06, (3,0): 3, 1.00914, 1.00101e-06, (4,0): 4, 1.00914, 1.00101e-06, (5,0): 5, 1.00914, 1.00101e-06, (6,0): 6, 1.00914, 1.00101e-06, (7,0): 7, 1.00914, 1.00101e-06, (8,0): 8, 1.00914, 1.00101e-06, (9,0): 9, 1.00914, 1.00101e-06, (10,0): 10, 1.00914, 1.00101e-06 } } } Testsuites pass. OK to commit? PS: The optional capability support depends on a recent patch to the flesh which has not been applied yet. I won't commit these three patches unless that patch is accepted and committed. -- Ian Hinder ian.hinder(a)aei.mpg.de

4 10

OpenMP errors in GRHydro
by Erik Schnetter 17 Dec '10

17 Dec '10

I just found and corrected OpenMP errors in GRHydro's prim2con. I believe they have been there for some weeks. When using OpenMP to parallelise loops, one has to take care that there are two kinds of variables: serial variables (that exist once per MPI process) and parallel variables (that exist once per thread). Since OpenMP correctness depends on everybody who modifies the code, let me briefly explain the issue below. Variables that are declared in Fortran in the usual way are serial by default; if they are set within a loop, there is a conflict if different threads set the variable to different values at the same time. To parallelise variables, they have to be listed in a "omp private" statement at the beginning of the loop. This is inconvenient. The wrong code looked like this: !$OMP PARALLEL DO do k = GRHydro_stencil,cctk_lsh(3)-GRHydro_stencil+1 do j = GRHydro_stencil,cctk_lsh(2)-GRHydro_stencil+1 do i = GRHydro_stencil,cctk_lsh(1)-GRHydro_stencil+1 det = SPATIAL_DETERMINANT(gxx(i,j,k),gxy(i,j,k),gxz(i,j,k), \ gyy(i,j,k),gyz(i,j,k),gzz(i,j,k)) The variable "det" is shared between all threads, and so different threads will assign different values to it at the same time, leading to essentially random results at run time. The correct code needs to look like this: !$OMP PARALLEL DO PRIVATE(det) do k = GRHydro_stencil,cctk_lsh(3)-GRHydro_stencil+1 do j = GRHydro_stencil,cctk_lsh(2)-GRHydro_stencil+1 do i = GRHydro_stencil,cctk_lsh(1)-GRHydro_stencil+1 det = SPATIAL_DETERMINANT(gxx(i,j,k),gxy(i,j,k),gxz(i,j,k), \ gyy(i,j,k),gyz(i,j,k),gzz(i,j,k)) Note the variable "det" is declared private. -erik PS: There may be other, similar errors in GRHydro. It may be time to have the code peer-reviewed after the significant changes since the release. We should also begin to use OpenMP in our test cases. -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

Static TOV example only with polytropic EOS?
by Erik Schnetter 16 Dec '10

16 Dec '10

The static TOV example of the Einstein Toolkit seems to be using a polytropic equation of state. Should we be showing off our capabilities by letting the entropy evolve? Also, there seems to be a bit of a confusion regarding the terms polytype, polytrope, and polytropic. I have no particular preference, but think we should use the same term everywhere. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

Meeting minutes
by Roland Haas 13 Dec '10

13 Dec '10

Meeting minutes: Present were: Frank, Roland, Tanja, Bruno, Christian, Peter, Erik, Josh - planned work over the break: * MHD, EOS (testing, debugging) * beginning of next year: remove EOS_General from GRHydro - HDF5 (Fortran interface): * currently only used by EOS_Omni * rewrite read-routines in EOS Omni in C to avoid need for Fortran interface if the Fortran interface is a pain to use for people (do we still want to do this?) * make sure building HDF5 works on all machines (see next item) - env-variables vs. options files vs. command line options * add option ignore-environment to make command to prefer options files options over env variables - publication list: * use same format as for requested publications (SPIRES key, bibtex) - create webpage/file to keep track of major changes in between releases (a changelog) - ET paper: * describe both infrastructure and physics thorns (and a physics example?) * make it a comprehensive paper to serve as a reference in the future * propose to publish in "Computantional Science and Discovery" (by IOP) * physics modules: MacLachlan, GRHydro, TwoPunctures, AHFinderDirect, Isolated Horizon thonrs (QLM?), ... * infrastructure thorns: Carpet, ... * glue modules: ADMBase, HydroBase, ... * need to come up with a list of key components, contact authors of modules to ask them to write a section * decide on author list arrangements: non-alphabetic main-authors first (writing paper, major contributors), then everyone else * will have PI call for this (in part. authors) - next phone call: Jan 10th unless there is need for an earlier one which would be on Jan 3rd 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

Re: [Users] [ET Trac] [Einstein Toolkit] #100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation
by Roland Haas 13 Dec '10

13 Dec '10

Hello all, > following: > > make sim options=optionsfile VARIABLE=OVERRIDE > > and thus override the setting for VARIABLE that may exist in > "optionsfile". > > We may want to change this (and I think we should); however, there is Should this really be changed? I find myself doing make sim options=optionsfile SILENT=NO occasionally when the make process fails for some odd reason (actually I would sometimes prefer if I could do more with this mechanism, eg. also OPTIMISE=NO when debugging). So if the possibility of doing VARIABLE=OVERRIDE on the command line is related to preferring environment variables over options file options then (at least for me) the current behaviour is the more useful one. 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.

2 1

Meeting Reminder
by Frank Loeffler 12 Dec '10

12 Dec '10

Hi, This is a reminder about our usual Monday Einstein Toolkit phone call. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/info/support/ Let's make this the last Einstein Toolkit call before Christmas, and thus within 2010. The next call after tomorrow will be January 10th, at 10am US central time. We should discuss what is foreseen to be happening within the toolkit over the holidays, especially for the development in GRHydro, but also on other aspects. Another issue I would discuss rather sooner than later is how we can keep track of publications which used the toolkit. This will be extremely important for the project reports. Waiting with this longer will only make it harder in the end. I would welcome ideas on how to keep a consistent and up-to-date database of publications. My personal expectation would be that this could be a bibtex file in some repository. But even then, a few more political/taste than technical issues remain, with the most often discussed being: how to choose keys for entries, how to (double?) cite arXiv and journal locations, as well as how to (or not to) include urls. It would be interesting to hear in this context how the different groups handle bibtex databases, especially when using multiple files from different sources. Frank

1 0

svn.(cactuscode|einsteintoolkit).org upgrade
by Frank Loeffler 10 Dec '10

10 Dec '10

Hi, The svn server for the Cactus and the Einstein Toolkit will be rebooted in about 15 minutes for a memory upgrade. It shouldn't take long to have it back up running after that. Frank Loeffler

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users December 2010