Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Meetinq minutes
by Roland Haas 07 Mar '11

07 Mar '11

Present were: Tanja, Frank, Roland, Ian, Eloisa, Bruno, Peter ET paper: * no further progress on text * TOV parameter file for test cases has been submitted and is being tested * Kerr/pertrubed BH test ** Bruno,Eloisa,Peter,Ian are working on it ** use puncture initial data with spin to have physical perturbation (see turduckening paper, arXiv:0809.3533) upcoming Einstein Toolkit release (end of May): * want to use OpenMP in testsuites * provide tarball for all the sources files ready to be compiled * create list of changes file in repository * versions used: ** Carpet/git, Carpet/hg will become development version after release ** simfactory/perl * finish transition to EOS_Omni (testsuites, documentation, transition guides, ...) * address testsuite accuracy issues (tolerance per variable issues, dependencies of results on number of processors) ** re-read old discussions concerning this 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

Einstein Toolkit Spring workshop
by Christian Reisswig 07 Mar '11

07 Mar '11

Dear Einstein Toolkit users, the Einstein Toolkit Spring workshop https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Spring_2011 will be held from Tue, 04/26/11 - Fri, 04/29/11 at the Cahill Center for Astronomy and Astrophysics at Caltech. Registration can be done by replying to this email. For further information, please refer to the website above. cheers, Christian -- ----------------------------------------------------------------- Christian Reisswig Cahill Center for Astronomy and Astrophysics California Institute of Technology -----------------------------------------------------------------

1 0

ET Meeting Reminder
by Frank Loeffler 06 Mar '11

06 Mar '11

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/info/support/ I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. Some points of tomorrows discussion will be: 1) ET paper status 2) Last week we agreed to have a short Einstein Toolkit workshop at CalTech from noon April 26th to noon April 29th. That being said, the core of the meeting will happen until April 28th, with the last day 'reserved' for loosely working together, otherwise known as hacking away. Information about the workhop will be posted to the wiki: https://docs.einsteintoolkit.org/et-docs/index.php?title=ET_Workshop_Spring… The two primary topics of the workshop will be the remaining work on a) MHD b) EOS_Omni 3) First plans / goals for next release end of May. Frank Löffler

1 0

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

Meetinq minutes
by Roland Haas 28 Feb '11

28 Feb '11

Present were: Roland, Frank, Tanja, Christian, Ian, Erik, Bruno, Peter ET paper: * Christian will work on the "Evolution methods" section * add statement about NSF support/grants and number of funded personnel in introduction spring ET workshop: * afternoon Tue April 26th - Friday April 29th (with Friday not being a full day) * at CalTech (NOT at GT) * Christian will send out an email with logistical information (for CalTech hotel rates) fall ET workshop: * suggested to hold in Atlanta, up for further discussion (date, location, topics, target audience) Einstein Toolkit: * remove EOS general code from GRHydro * remove GZ_Pach code from GRHydro * remove EOS general EOS thorns from ET in next release or at least the release after next 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

GRHydro simplifications
by Christian D. Ott 28 Feb '11

28 Feb '11

Hi All, in today's call, I would like to discuss the following proposed changes to GRHydro that are primarily for code simplification: * remove "General" EOS interface and just keep EOS_Omni as the single EOS interface supported by GRHydro * remove obsolete routine connecting GRHydro to the GZ Patch System. - Christian

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users