Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Re: [Users] [ET Trac] [Einstein Toolkit] #103: Handle parameter files with DOS newline convention
by Frank Loeffler 05 Jan '11

05 Jan '11

On Thu, Dec 30, 2010 at 03:56:47PM -0000, Einstein Toolkit wrote: > Try the attached patch - it fixes the problem for me. The patch looks fine and works. Thanks for contributing, please commit. Frank

1 0

reduction in carpet
by Hee Il Kim 05 Jan '11

05 Jan '11

Hi, Belated Happy New Year ! I am writing a simple code for the calculation of ADM mass and angular momentum by using ML_ADMQuantities. As you know, it requires reduction procedure for the summation of the integrand, e.g., density * volume measure. I've tried various reduction APIs including old deprecated one, but I could only succeed in the integration only over the coarsest grid level, which was not accurate. If I use the new reduction API in the reference manual of Cactus, CCTK_ReduceGridArrays; CCTK_ReduceGridArrays(const cGH *GH, int dest_processor, int local_reduce_handle, int param_table_handle, int N_input_arrays, const CCTK_INT input_array_variable_indices[], int M_output_values, const CCTK_INT output_value_type_codes[], void* const output_values[]); , I encounter the following error .... WARNING[L3,P0] (Cactus): CCTK_ReduceGridArrays: no grid array reduction registered WARNING level 0 in thorn ML_Analysis processor 0 host compute-0-5.local (line 159 of Evaluate_ADMQuantities.F90): -> Failed to integrate J_z Param_table_handle is not clear to me but it seems not causing the problem. The reduction operators are registered by CactusBase/LocalReduce. Could you let me know which reduction function I have to use for this calculation? I mean the integration over the whole grid levels. Should I do loop over refinenment levels; ... do loop over reflev call CCTK_Reduce enddo ... Thanks in advance, Hee Il

2 1

LONI allocations (demonstration accounts); allocation switch-over
by Erik Schnetter 02 Jan '11

02 Jan '11

Some Einstein Toolkit users have access to the loni_cactus05 allocation, e.g. via a demonstration account. Note that this allocation (loni_cactus05) has run out at the end of 2010, and we expect to receive a renewal (loni_cactus06) within the next week (or two). If you used to have access to loni_cactus05, you can request access to loni_cactus06 at <http://allocations.loni.org/>. You will need to wait until you see loni_cactus06 listed there before requesting access. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users