Users December 2011

users@lists.einsteintoolkit.org

16 participants
29 discussions

Einstein Toolkit Meeting Reminder
by Frank Loeffler 14 May '15

14 May '15

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/community/support/ I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. My agenda contains: - Fall workshop - PLEASE let us know if you come [1]! - Hotel booking - Release planning - release date: Mon Oct 24 2011 - freeze date: Mon Sep 26 - the day of the call! - branch name: ET_2011_10 - List of release-concerning bugs [2] - ET paper: proposed "freeze" by Oct 3rd (Mon after this call) As always: feel free to add to this list. Frank Loeffler [1] https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Fall_2011#Fall_Einstei… [2] https://trac.einsteintoolkit.org/query?status=!closed&milestone=ET_2011_11&…

10 31

Simulation domain volume and reduction weight sum differ
by Jakob Hansen 25 Sep '12

25 Sep '12

Hi, Using mercurial, I get this warning during simulations : INFO (CarpetReduce): Simulation domain volume: 170368000 INFO (CarpetReduce): Reduction weight sum: 170367999.880642 WARNING level 1 in thorn CarpetReduce processor 0 host tachyon2974 (line 120 of /home01/r632kgw/jakob/CactusP/arrangements/Carpet/CarpetReduce/src/mask_test.c): -> Simulation domain volume and reduction weight sum differ Simulations seem to run okay though. What is causing this warning and is it serious or can I just ignore it? Cheers, Jakob

3 3

support_old_CalcTmunu_mechanism
by Frank Loeffler 23 Sep '12

23 Sep '12

Hi, Are there objections to change the default of TmunuBase::support_old_CalcTmunu_mechanism from "yes" to "no"? Frank

1 1

Propose thorns for inclusion in the EinsteinToolkit
by Barry Wardell 26 Apr '12

26 Apr '12

Hi, Recently Ian Hinder and I have created an arrangement of thorns called EinsteinExact which provide some exact solutions for use in Cactus. The scope of these thorns is similar to that of the Exact thorn but with some notable improvements: * The extrinsic curvature is computed symbolically rather than using finite differencing so it should be accurate to within roundoff. This means that EinsteinExact is more exact than Exact. * The solutions used in EinsteinExact come from a database of metrics which have been correctness-tested, e.g., by checking symbolically that they are a solution of the Einstein equation. * EinsteinExact is written in Mathematica and uses Kranc, so the raw source is very small (~250 lines) and easy to understand. * Adding a spacetime is as simple as typing the components of the metric into Mathematica. So far, the spacetimes included are Minkowski, Kerr-Schild, gauge wave and shifted gauge wave, but the list can easily be extended in the future. There is also support for arbitrary rotations, using the same conventions as the Exact thorn uses. We have not yet included the other transformations supported by Exact, but they shouldn't be difficult to add. We have checked that for these spacetimes the Exact solutions converge to the EinsteinExact solutions at the correct finite differencing order used by Exact. We would like to propose the EinsteinExact arrangement for inclusion in the EinsteinToolkit. If you would like to try it out, you can get it using: git clone --recursive git://github.com/barrywardell/EinsteinExact Any comments or suggestions are welcome. Regards, Barry

4 6

changing CarpetRegrid2 parameters for ETK Maxwell + mercurial Carpet?
by Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] 01 Mar '12

01 Mar '12

Hi all. At Erik's suggestion (off-list), I resolved some checkpoint recovery issues by moving from "Curie" to the new ETK release. However, my old grid specifications seem no longer to work. The parameters are for a 2:1 mass-ratio BHB evolution. I've used three "centres" -- one each for the punctures, and one centred at the origin. Below is what I used to have in CarpetRegrid2, which worked with the last "Curie" release of ETK (the full grid is [-2048,2048] in size). ------------------------------------------------------------------- # Parameters of thorn CarpetRegrid2 (implementing CarpetRegrid2) CarpetRegrid2::freeze_unaligned_levels = "yes" CarpetRegrid2::num_centres = 3 CarpetRegrid2::num_levels_1 = 12 CarpetRegrid2::position_x_1 = -3.3333333333333333333 CarpetRegrid2::movement_threshold_1 = 0.10 CarpetRegrid2::radius_1[5] = 40 CarpetRegrid2::radius_1[6] = 20 CarpetRegrid2::radius_1[7] = 10 CarpetRegrid2::radius_1[8] = 5 CarpetRegrid2::radius_1[9] = 2.5 CarpetRegrid2::radius_1[10] = 1.25 CarpetRegrid2::radius_1[11] = 0.625 CarpetRegrid2::num_levels_2 = 13 CarpetRegrid2::position_x_2 = 6.6666666666666666667 CarpetRegrid2::movement_threshold_2 = 0.05 CarpetRegrid2::radius_2[5] = 40 CarpetRegrid2::radius_2[6] = 20 CarpetRegrid2::radius_2[7] = 10 CarpetRegrid2::radius_2[8] = 5 CarpetRegrid2::radius_2[9] = 2.5 CarpetRegrid2::radius_2[10] = 1.25 CarpetRegrid2::radius_2[11] = 0.625 CarpetRegrid2::radius_2[12] = 0.3125 CarpetRegrid2::num_levels_3 = 6 CarpetRegrid2::radius_3[1] = 1024 CarpetRegrid2::radius_3[2] = 512 CarpetRegrid2::radius_3[3] = 256 CarpetRegrid2::radius_3[4] = 160 CarpetRegrid2::radius_3[5] = 96 CarpetRegrid2::regrid_every = 60 CarpetRegrid2::verbose = "yes" ------------------------------------------------------------------- This doesn't work now, however. Current ETK complains that some entries in radius_1 and radius_2 are unspecified, and it sets them to zero with catastrophic results. To resolve this, I am now explicitly setting the missing levels: CarpetRegrid2::radius_1[1] = 1024 CarpetRegrid2::radius_1[2] = 512 CarpetRegrid2::radius_1[3] = 256 CarpetRegrid2::radius_1[4] = 160 CarpetRegrid2::radius_2[1] = 1024 CarpetRegrid2::radius_2[2] = 512 CarpetRegrid2::radius_2[3] = 256 CarpetRegrid2::radius_2[4] = 160 This runs, but complains every time step about mismatched "simulated domain volume" and "reduction weight sum": ---------------------------------------------------------------------------------- INFO (CarpetReduce): Simulation domain volume: 442368 INFO (CarpetReduce): Reduction weight sum: 442367.999999072 WARNING level 1 in thorn CarpetReduce processor 0 host r186i2n12.p4.nas.nasa.gov (line 120 of /home1/bjkelly1/CODES/Cactus/configs/hahndol/build/CarpetReduce/mask_test.c): -> Simulation domain volume and reduction weight sum differ ---------------------------------------------------------------------------------- After a short evolution time (7.25 M, or more than 1700 time steps), the run crashes. First there are several messages of the form: ---------------------------------------------------------------------------------- INFO (CarpetReduce): Simulation domain volume: 442368 INFO (CarpetReduce): Reduction weight sum: 442367.999991311 INFO (CarpetRegrid2): Centre 1 is at position [-3.29831,-0.331478,7.81462e-15] with 12 levels INFO (CarpetRegrid2): Centre 2 is at position [6.58787,0.867484,8.98107e-15] with 13 levels INFO (CarpetRegrid2): Centre 3 is not active INFO (CarpetRegrid2): Regridding INFO (CarpetRegrid2): Regridding levels 10 and up WARNING level 1 in thorn CarpetLib processor 58 host r186i3n7.p4.nas.nasa.gov (line 182 of /home1/bjkelly1/CODES/Cactus/configs/hahndol/build/CarpetLib/dh.cc): [...] -> /home1/bjkelly1/CODES/Cactus/configs/hahndol/build/CarpetLib/dh.cc:948: [ml=0 rl=10 c=59] The following grid structure consistency check failed: Synchronisation and boundary prolongation: All points must have been received needrecv.empty() [...] WARNING level 0 in thorn CarpetLib processor 94 host r186i3n12.p4.nas.nasa.gov 12676 (line 1973 of /home1/bjkelly1/CODES/Cactus/configs/hahndol/build/CarpetLib/dh.cc): 12677 -> The grid structure is inconsistent. It is impossible to continue. -------------------------------------- I'm attaching my current parameter file in full. I'm reluctant to post the entire STDOUT/STDERR, since it's around a MB in size. Any ideas would be appreciated. I would turn to the copious documentation on CarpetRegrid2, but as noted before, there is none. Thanks, Bernard ----------------------------------------------------------------------------- Bernard Kelly -- CRESST Research Associate, NASA/GSFC Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly(a)nasa.gov<mailto:bernard.j.kelly@nasa.gov> Web: http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iphone… -----------------------------------------------------------------------------

4 13

problem with first example simulation with ETK
by Jose Fiestas Iquira 10 Jan '12

10 Jan '12

Dear colleagues, I am a new ETK user and am running my first example simulation as described here https://docs.einsteintoolkit.org/et-docs/Tutorial_for_New_Users I could not finish the example after: ./simfactory/bin/sim submit static_tov --parfile=par/static_tov.par --procs=32 --walltime=8:0:0 with the following error message: Parameter file: /home/ettest24/Cactus/par/static_tov.par Error: could not access simulation base directory /scratch/ettest24/simulations for reading and writing Aborting Simfactory. Probably my LONI account is not completely set, or need to copy some data in /scratch/ettest24/simulations/ which does not exist? Would appreciate any help. All the best, Jose

2 3

Re: [Users] [Einstein Toolkit] #66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices
by Ian Hinder 21 Dec '11

21 Dec '11

On 18 Oct 2011, at 15:51, Einstein Toolkit wrote: > #66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices > -----------------------------------+---------------------------------------- > Reporter: bcmsma@… | Owner: eschnett > Type: defect | Status: new > Priority: minor | Milestone: > Component: Carpet | Version: > Resolution: | Keywords: > -----------------------------------+---------------------------------------- > > Comment (by rhaas): > > The output_XXX ones work for out3d_vars (the "sliced" 3d output), they do > not work for the legacy out_vars 3d output as you correclty point out. The > former should produce identical output for grid functions (and maybe > scalar and arrays though that is much less well tested). Its code cannot > be used for checkpointing though which is why the old legacy code is still > in (and I don't fully trust the new 3D code yet since it has not been > active for very long). I wasn't really aware of the new-style 3D output method. Does this method allow for parallel output (i.e. one file per process)? If not, then I worry that it might be quite slow. -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

2 1

Re: [Users] [Einstein Toolkit] #659: vip.rzg.mpg.de: Internal Compiler Error: Insufficient storage
by alibeck 21 Dec '11

21 Dec '11

Einstein Toolkit schrieb: > #659: vip.rzg.mpg.de: Internal Compiler Error: Insufficient storage > -----------------------------------------------+---------------------------- > Reporter: alexander.beck-ratzka@… | Owner: eschnett > Type: defect | Status: review > Priority: major | Milestone: > Component: SimFactory | Version: > Resolution: | Keywords: Formaline > -----------------------------------------------+---------------------------- > Changes (by knarf): > > * cc: alexander.beck-ratzka@… (added) > > > Comment: > > Alex? > > I have just tried to add a comment, saying the big has been fixed. Unfortunately I am getting the following error message: [snip] Submission rejected as potential spam [snip] My comment was as follows: [snip] I have changed in the machine config file mdb/machines/vip.ini the make alias. The line make = gmake -j16 has been exchanged against make = env LDR_CNTRL='MAXDATA=0xB0000000@DSA' gmake -j16 The solution is also available now in the trunk version. Using this alias, the build is working now. [snip] Any ideas, what might have causes this error? Best wishes Alexander

4 4

Problem when checking out ET-dev
by Michael Pürrer 20 Dec '11

20 Dec '11

Hi all, I ran into the following problem when checking out the development version of ET: ----------------------------------------------------------------- Checking out module: Carpet/doc from repository: ssh://carpetmercurial@carpetcode.org/carpet into: Cactus/arrangements carpetmercurial(a)carpetcode.org's password: I had no problem checking out the development version of Carpet following http://www.carpetcode.org/get-carpet.html. Does anybody know a solution? Michael

5 9

Re: [Users] Restarting from a checkpoint with simfactory
by Barry Wardell 19 Dec '11

19 Dec '11

On Mon, Dec 19, 2011 at 10:08 PM, Erik Schnetter <schnetter(a)cct.lsu.edu>wrote: > > There was a discussion regarding where to place checkpoint files. I > originally intended them to reside within the corresponding output-NNNN > directories, and this required setting the checkpoint directory to > $parfile, same as the output directory. However, since then others made the > point that they rather wanted all checkpoint files of a simulation in the > same directory, because this enables Cactus to remove the checkpoint files > of previous restarts -- this makes restarts less independent, but can save > disk space. This requires setting the checkpoint directory to > "../checkpoints". > > I don't recall what changes were necessary in Simfactory to support this, > but there may have been some. > In the end, I don't think any changes were made in order to support this. The only changes were in the parfiles. > However, Simfactory always expected all output directories to be set to > $parfile, or to subdirectories of $parfile. It may be that things worked > without doing so, but I never used or tested this myself. > I guess it must have always been the case that this didn't work. It does seem somewhat counter-intuitive that by default Cactus outputs checpoints to a different location than where it looks for them. Barry

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users December 2011