Users March 2011

users@lists.einsteintoolkit.org

15 participants
25 discussions

Negative timesteps with timestep_method="courant_speed" and terminate="time"
by David Radice 03 Mar '11

03 Mar '11

Hello, I have experienced a curious problem when trying to use Time::timestep_method = "courant_speed" with Cactus::terminate = "time". What happens is that, after the final time is reached, the timestep becomes negative, afterwards the code quickly crushes (my equations are not time-reversible and I guess that dt >= 0 is also assumed in many other parts of the code)... The attached patch for the Time thorn fixes the problem, even tough I am not exactly sure on why the commented-out part of the code leads to the problem: it would seem to me that cctkGH->cctk_time should always be less then cctk_final_time when this routine is executed... Do you have any idea of what is going on? 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 3

parameter files
by Babiuc-Hamilton, Maria 03 Mar '11

03 Mar '11

Hello, I am trying to run the configuration compiled with einsteintoolkit.th and the parameter files qc0-mclachlan.par, static_tov and ks-mclachlan.par, on 12 processors with OpenMPI, but I am getting those errors: qc0-mclachlan.par: WARNING level 0 in thorn CarpetInterp processor 6 host muci-train01.marshall.edu (line 1683 of /home/babiuc/Einstein_Tooklit/Cactus/configs/einsteintoolkit/build/CarpetInterp/interp.cc): -> Grid function "AHFINDERDIRECT::ahmask" has only 1 active time levels on refinement level 1; this is not enough for time interpolation cactus_ks-mclachlan: /home/babiuc/Einstein_Tooklit/Cactus/configs/einsteintoolkit/build/Carpet/helpers.cc:201: int Carpet::Abort(cGH*, int): Assertion `0' failed. [muci-train01:11103] *** Process received signal *** [muci-train01:11103] Signal: Aborted (6) static_tov: WARNING level 0 in thorn Bindings processor 3 host muci-train01.marshall.edu (line 5193 of /home/babiuc/Einstein_Tooklit/Cactus/configs/einsteintoolkit/build/CactusBindings/Functions/AliasedFunctions.c): -> The function EOS_Omni_GetHandle has not been provided by any thorn in your thornlist cactus_ks-mclachlan: /home/babiuc/Einstein_Tooklit/Cactus/configs/einsteintoolkit/build/Carpet/helpers.cc:201: int Carpet::Abort(cGH*, int): Assertion `0' failed. [muci-train01:11439] *** Process received signal *** [muci-train01:11439] Signal: Aborted (6) ks-mclachlan.par: WARNING level 1 in thorn CarpetReduce processor 1 host muci-train01.marshall.edu (line 1084 of /home/babiuc/Einstein_Tooklit/Cactus/configs/einsteintoolkit/build/CarpetReduce/reduce.cc): -> Grid function "CARPETREDUCE::weight" has only 1 time levels on refinement level 0; this is not enough for time interpolation The first two parameter files abort the run. The last one keeps the run going until it ends in NaN. Is there a simple fix for this? thank you, Maria

3 2

EOS_Omni readtable.f90
by Babiuc-Hamilton, Maria 02 Mar '11

02 Mar '11

Hello I have problems compiling the thorn EOS_Omni with an intel compiler and mpich2. If I use an externally installed hdf5, then the compilation chokes with the error: Cactus/configs/einsteintoolkit/build/EOS_Omni/nuc_eos/readtable.f90(5): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [HDF5] use hdf5 ------^ If I let hdf5 be built internally, then the compilation goes almost to the end, and quits with the errors: /Cactus/configs/einsteintoolkit/lib/libthorn_EOS_Omni.a(readtable.F90.o): In function `nuc_eos_readtable_': /home/babiuc/Cactus/configs/einsteintoolkit/build/EOS_Omni/nuc_eos/readtable.f90:(.text+0x32): undefined reference to `h5lib_mp_h5open_f_' Do I need extra flags? Maria

3 4

Re: [Users] [Einstein Toolkit] #319: more OpenMP WORKSHARE sections in GRHydro Reconstruct
by Roland Haas 02 Mar '11

02 Mar '11

Hello Erik, all, > For best OpenMP performance, there should probably be as few parallel > regions as possible. In general, a single parallel region per routine > would be best (unless the routine has a complex structure). I agree and both gcc and icc accept if statements inside the workshare (at least it compiles). However: > I think that if statements inside a workshare construct are fine (I'm not > completely sure about this). In this case, code such as The OpenMP specifications (section 2.5.4 of http://www.openmp.org/mp-documents/spec30.pdf or here https://computing.llnl.gov/tutorials/openMP/#WORKSHARE) list only array or scalar assignments and WHERE constructs within WORKSHARE sections, so I was not sure and chose the err on the side of caution (and overly long code admittedly). Should have put this into the original description (was in then I deleted it again :-) ). > Some of your patch reads as if the current code had workshare constructs > outside of a parallel region. This would be senseless and looks like a bug > to me. Yes, some of the current code has OMP WOKSHARE outside of PARALLEL sections which seems to be harmless (at least the code ran for me and did not produce nonsense). > could be simplified to have only a single, enclosing workshare construct. I can try and see if it works and if it does amend my patch with a single OMP WORKSHARE section around all of the initialization statements as well as a comment that we might be using undefined behaviour here. 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

Re: [Users] Thorn Periodic
by Seyyed Mohammad Hassan Halataei 01 Mar '11

01 Mar '11

Dear Erik, Thank you for your respond. I want to use cylindrical coordinates in my problem (r, phi, z) and I think I need a physical boundary condition for phi ,rather than a symmetry. It seems rotational boundary condition can be helpful and I thought if I use periodic boundary condition for phi (namely , periodic_y = yes) the code should satisfy my demand . However, it could not. Am I on the right track ? I think RotatingSymmetry90 cannot do that , because I want to have the full range [-PI, PI] and evolve it . All I need is connecting two ends of the grid in phi direction (or y) together . In other words, I like to tape -PI to PI. Do you think the thorn Periodic is the appropriate thorn or there is a better thorn which can do that for me ? Thank you Hassan On Mon, Feb 28, 2011 at 5:37 PM, Erik Schnetter <schnetter(a)cct.lsu.edu>wrote: > Hassan > > The current version of this thorn is located in an svn repository at > <http://svn.cactuscode.org/arrangements/CactusNumerical/Periodic>. > However, this thorn implements a toroidal symmetry, not a rotational > symmetry. Can you describe the symmetry that you are trying to apply? > For example, there is another thorn CactusNumerical/RotatingSymmetry90 > that may be more suitable. There is also another thorn available that > implements a Cartoon symmetry. > > We describe much of our code at <http://einsteintoolkit.org>, and we > use the mailing list <users(a)einsteintoolkit.org> for discussion. Would > you mind using this mailing list instead of keeping this conversation > private? The mailing list has the advantage that others will also be > able to help when I don't know the answer. > > -erik > > On Mon, Feb 28, 2011 at 6:20 PM, <halatae1(a)illinois.edu> wrote: > > Dear Dr. Schnetter, > > > > I am Hassan Halataei, working in Professor Shapiro's Numerical Relativity > group in Univ. of Illinois at Urbana-Champaign. I am trying to use the thorn > Periodic you have written in 2003 to implement rotational symmetry in my > problem (Single Black hole surrounded by an accretion disk) . I read the > 2-page documentary of the thorn and acted according to that . However, the > thorn does not work for me . I tried several different things for days to > make it work , however the result does not obey periodic boundary condition > . I was wondering if you let me know if there is anything that I missed or > any other consideration that I must take care of ? > > > > > > Thank you > > Hassan > > > > > > -- > Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/ >

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users March 2011