Users April 2012

users@lists.einsteintoolkit.org

21 participants
31 discussions

Start a nNew thread

Einstein Toolkit Meeting Reminder
by Frank Loeffler 14 May '15

14 May '15

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

simfactory run sub-options
by Roland Haas 01 May '12

01 May '12

Hello all, reading the docs at http://simfactory.org/info/documentation/userguide/_auto/commands/run.html#… it seems as if the "run" subcommand requires a --recover option to recover from a checkpoint. However looking at the simfactory generated RunScripts, this option is not used (though my runs seem to recover fine). Since I have to do some lower-level fooling around with simfactory runs: is this option still required? Or does simfactory by now find checkpoints automatically and links them into the new folder? In particular I am wondering if I can use a single qsub script --8<-- #!/bins/h # PBS ... # PBS ... sim run mysim --walltime 24:00:00 --procs 42 --num-threads 13 sim cleanup mysim qsub $myself --8<-- and have it re-submit itself again and again and have simfactory properly create new output folders, link the checkpoints files from segment to segment and run with the options. 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 3

Meeting Minutes
by Roland Haas 30 Apr '12

30 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Present were: Frank, Roland, Peter, Tanja, Yosef, Erik, Ian, Christian Ott, Josh, Bruno, Scott, Philipp LSU server certificate: * old certificate expired * CCT is working on getting a new certificate from LSU * we will set a deadline of two weeks for this issue to be resolved. If it is not resolved by then we will move the ET material to einsteintoolkit.org (nee cactuscode.org). We want this to happen before the release date. ET release: * number of open tickets actually increased but some older ones were fixed. Please help reduce them. [1] * Ian reports that all testsuites currently pass on Damiana * please runs the testsuites on machines assigned to you [2] - - preferably using simfactory since it automates the process and you would also be testing simfactory - - test with 1 and 2 MPI processes and the default number of cores for the machine * Ian provided a comprehensive list of commit messages which Frank will condense into a changelog Zelmani branch: * we want to get rid of it by merging all changes back into trunk * some changes to GRHydro require supporting changes to MoL * Christian Reisswig is being tasked to prepare patches and submit them for review * currently three distinct changes beyond what is in https://trac.einsteintoolkit.org/ticket/827: - - add multirate support to MoL and GRHydro to use different Runge Kutta scheme for hydro and GR - - add option to sync only the conservatives which reduces communication considerably - - move atmosphere reset into last RK substep which also reduces communication - - the last two changes can conceivably slightly change results in the buffer zones MHD paper: * status: most special relativity test, the GR ones do not - - cylindrical shock tests need Local Lax Friedrich method, which we have in common with other codes - - have monopole test that mostly demonstrates how divergence cleaning works - - Alf\'en test implemented but needs testing - - Loop advection: Philipp will take over from Josh and Bruno - - Rotor needs work - - Bondi accretion needs work - - magnetized TOV in cowling and GR has been done by Philipp and used to test the GRMHD patches - - rotating collapse: Philipp is working on this, can compare to results by Shibata - - send out extra status update either via email or through the paper repository * please include parameter files in paper repository (currently in GRHydro_InitData/par) * want mature version of paper in a month (RIT has time, Philipp has time, everyone else was silent) Yours, Roland [1] https://trac.einsteintoolkit.org/query?status=accepted&status=assigned&stat… - -- 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ewvwACgkQTiFSTN7SboXhzgCg0vc60ouH47hD1rUF/iiNJnLx 3UoAoIP8sGHK+dBrTGva04ylmtskOmKv =Xdql -----END PGP SIGNATURE-----

1 0

Einstein Toolkit Meeting
by Frank Loeffler 29 Apr '12

29 Apr '12

1 0

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

Meeting Minutes
by Roland Haas 25 Apr '12

25 Apr '12

Present were: Frank, Roland, Peter, Tanja, Yosef, Erik, Ian, Steve * connectivity issues with LSU svn server - should be gone by now (was a LDAP server migration) - please report in a trac ticket (and amend the ticket) whenever that happens (again) - currently svn.einsteintoolkit.org and svn.lsu.edu are two different machines (for historical reasons). Since only svn.lsu.edu seems to cause problems, there is the suggestion to migrate LSUThorn and simfactory from svn.lsu.edu to svn.einsteintoolkit.org ET release: * ADMMass - used by Frank, Luca (that we know of) - please speak up if you use this thorn and (even better) you would have a test suite and or documentation for it - want test suite and/or docs for inclusion in the toolkit - do not include if neither one is provided * SphericalSlice - no test suites or docs - do not include without since it is a rather complicated thorn - all agree that it is very useful - Erik might have time to write some docs but not soon - see discussion on generic Cactus output routines in ticket #822 * Outflow - no (sustained) objection to inclusion voiced - clearly indicate that output format will change as soon as we have the generic Cactus output routines in place and or that we might use SphericalSlice - make current output routines more Cactus compliant if there are not yet - used by: Tanja, Roland (who are authors), all of GT, interest by Frank, Bruno Giacomazzo * OpenCLRuntime: - needs test case or example, do not include otherwise - deemed useful by Frank and Erik (who is author) * ML_NSSN_O2: - remove from toolkit * ML_NSSN_MP: - propose to remove or remove if already proposed * ADM: - remove only if tests are rewritten to no longer use it * BSSNL_MoL: - remove/convert/regenerate all testsuites using it (assigned to Roland) Yours, Roland

4 4

Einstein Toolkit Meeting
by Frank Loeffler 22 Apr '12

22 Apr '12

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#. The main topic will be the organization of the next ET release. In particular, this means ll discuss: - Is there code which should be included (but which isn't yet)? If so: which? So far we have identified the following, and I tried to summarize the current state for each: - ADMMass: no documentation - SphericalSlice: no testsuite, no documentation - Outflow: suggestion rewrite I/O to use Cactus I/O, probably using SphericalSlice - OpenCLRuntime: no review so far - Should something be removed? - EOSG_* has been removed - 2nd order McLachlan thorns removed - Should something be depreciated (marked as being removed in the fall)? - No candidates so far - Release-relevant tickets (11) [1] - ChangeLog - Release Name - Ada Lovelace (World's First Computer Programmer) http://en.wikipedia.org/wiki/Ada_Lovelace - others? Not necessarily connected to the release: - Bug reports: a lot happened during last week: 21 issue were opened or changed and are still open, 25 tickets could be closed. Some of them were: - a lot of issues of the virtual machine have been resolved - a lot of issues with libraries in ExternalLibraries have been resolved - some thorns used version 1.8 of hdf5, without real reason, which prevented building on system with only api 1.6 available. This has been 'backported'. - The ET trac now has a working Captcha system, so not signed in users can attach their email to newly created tickets - The first ET paper was accepted. As usual, feel free to add to this agenda. Frank Loeffler [1] https://trac.einsteintoolkit.org/query?status=!closed&milestone=ET_2012_05&…

1 0

memory address limitations, using ints?
by Scott Hawley 20 Apr '12

20 Apr '12

Hi. I doing runs on Nautilus with some rather large grids, which are not being broken up on more than just a few (2 to 8) MPI processes. I'm noticing that there's a grid size of about 385^3 which I can't exceed, without Cactus/Carpet beginning to behave strangely, e.g. AHFinderDirect no longer works, and memory errors abound. Obviously there's the possibility that I have errors in the way I specify the grids in my parameter files. But I'm wondering: Have other people had success doing "very" large runs on, say, a shared memory architecture where MPI / domain decomposition are not employed? If so, than I've probably just made a mistake in my par file. If not... I'm wondering if this has to do with trouble address memory locations, and I notice that the type "int" is used in places, e.g. in the definition of CFINDEX3D,.. static inline int CCTK_GFINDEX3D (const cGH *GH, int i, int j, int k); static inline int CCTK_GFINDEX3D (const cGH *GH, int i, int j, int k) { return (i + GH->cctk_lsh[0]*(j + GH->cctk_lsh[1]*k)); } Should these "int" declarations be changed to "long" or "unsigned int" in order to access larger numbers? Thanks.

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users April 2012