Users May 2010

users@lists.einsteintoolkit.org

16 participants
27 discussions

Commit rights and policy
by Frank Loeffler 10 May '10

10 May '10

Hi, As discussed today I have given everyone currently listed as maintainer on http://einsteintoolkit.org/about/developers/ commit rights to the whole toolkit. This excludes the admin repository where the permissions for all the other repositories are stored, as is information about email addresses and such (for proper From: addresses in commit emails). Only four people do have read/write rights there currently: Colby (computer support), Gab, Erik and myself. Given that privacy-related information is stored there (like email addresses), we decided to keep this repository private, in contrast to everything else in the project. Another issue besides commit rights are some commit guidelines (you could call it policies if you want). We currently do not have this spelled out on the web pages, but we would like to get to that point in the future. We should take the experience with what we will try now as basis for that: Changes should be reviewed by at least one (other) maintainer. We should come up with a table of thorns and their 'maintainers' within the toolkit and ideally these persons should approve (or decline) a patch. However, the announcement of patches and the corresponding discussion should happen on the users mailing list to give everyone the opportunity to speak up and also to prepare for this change. There have to be exceptions to make this practical, but there cannot be strict rules about direct commits without discussions. Use common sense to decide about that. Nobody will shout at you if you get it wrong (at least not it's not too often). Good examples which don't need a discussion are: - Trivial changes (like typos) in documentation or comments, or extension thereof (always welcome) - Obvious bugs which fix problems like a compiler error or a file which was left out of a previous commit - Code cleanup which is not expected to change any result (like a formating change) Although you might _want_ to have a second look if this is a bigger change. If you would like to make such a change but you are not a maintainer, please simply send it to the users list regardless. Frank

1 0

weak scaling performance comparison
by Jian Tao 06 May '10

06 May '10

Hi All, The total evolution time per point per iteration of KL9 of both the CCATIE code and ML in Einstein Toolkit is shown in the attached graph. We run 3 times for each benchmark and the run with minimum evolution time is used. 1. the total evolution time of ET is shorter with larger number of cores. 2. the physics code of ET is faster when more than 8 cores are used. 3. the infrastructural time (regrid + restriction + sync) of ET is longer. I am using the git version of Carpet. Regards, Jian

1 0

Schedule change in Exact.
by Eloisa Bentivegna 04 May '10

04 May '10

Hello, I'd like to propose the following patch for the schedule.ccl of thorn Exact: ------------------------------------------------------ 135a136,140 > > schedule Exact__initialize in MoL_PostStep > { > LANG: Fortran > } "Set data from exact solution on an exact slice" ------------------------------------------------------ This should ensure that Exact__initialize is executed after regridding, in the same way that Exact__gauge already is. Thanks! Eloisa

5 9

GetComponents
by Bruno Coutinho Mundim 04 May '10

04 May '10

Hi, would it be possible to add a directive such as !PROTOCOL to GetComponents? That would be useful to access git repositories with ssh protocol, for example. Some private arrangements may need this feature and it would be interesting to use GetComponents for them as well. What do you think? Thanks, Bruno.

2 1

McLachlan no longer compiles
by Tanja Bode 03 May '10

03 May '10

Hello all, I did a completely fresh checkout of the Einstein Toolkit today using the einsteintoolkit.th file from the website, but it fails to compile McLachlan. There are many errors which pop up, specifically with respect to GenericFD functions and vectorization. The version had to be reset to patch 1309ac14bdb5406b3f274ff2a3eb09f41d6ab2d2 (before both regenerate code commits) before McLachlan compiled again. Cheers, Tanja

1 0

possible CVS server issues
by Roland Haas 03 May '10

03 May '10

Hello all, the cvs server at cvs.cct.lsu.edu seems to have become unaccessible from outside of LSU (I can still ping it from is.cct.lsu.edu). Trying to check out a thorn from LSUThorns I get: Updating module: LSUThorns/QuasiLocalMeasures from repository: :pserver:cvs.cct.lsu.edu/numrel located in: whisky/arrangements ERROR: Could not update module LSUThorns/QuasiLocalMeasures Died at ./GetComponents line 1353. 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.

3 3

benchmarking scripts
by Jian Tao 03 May '10

03 May '10

Hi, Please give it a try, http://www.cct.lsu.edu/~jtao/cct/xirel/einsteintoolkit/BENCHMARKS.tgz BENCHMARK should be under your Cactus directory. After you cd BENCHMARK, run ./xirelbench.sh To avoid any errors, you must have the whole set of einsteintoolkit downloaded and simfactory correctly configured. Regards, Jian

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users May 2010