Users August 2011

users@lists.einsteintoolkit.org

17 participants
39 discussions

Meeting minutes
by Roland Haas 22 Aug '11

22 Aug '11

Meeting minutes: Present were: Frank, Roland, Tanja, Josh, Bruno, Yosef, Erik ET release: * no new reported issues with Carpet/Hg and simfactory/python * CCE thorns (to be uodated with the missing SphericalHarmonicDecomp thorn today) have been moved into ET, thorns are in their final location * will incorporate CCE thornlist once all servers (McLachlan) are up again and the thornlist can be tested Fall workshop: * dates (in meeting minutes from 8/8 and soon on wiki): Oct. 31st to Nov. 3rd noon to noon. * topics will be MHD ** constraint transport ** radiation transport ** EOS * Infrastructure development ** improved scheduling (dependency based scheduling) ** GPGPU in Cactus Spring workshop: * target group: potential new users * have school on numerical relativity rather than code introduction only * timeframe: 3 intense days to accommodate grad students (classes, money) * initial schedule proposal to be decided in small group (the one with registered interest). Comments are welcome. ET paper: * some progress * TOV data is in * BBH waveform convergence is much higher than expected (8th order rather than 4th order). Investigate with extra runs at intermediate resolutions 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

Move of carpetcode.org
by Christian D. Ott 22 Aug '11

22 Aug '11

Dear All, the server handling carpetcode.org and carpet git and mercurial repositories is moving to new hardware today (2011/08/21). In this process, the IP address of the server will change from 78.46.246.114 to 78.47.165.8 and its ssh server key will change. If you access repositories via ssh, you will have to remove the old entry for carpetcode.org from your ~/.ssh/known_hosts file before being able to access the new server. Sorry for any inconvenience this move might cause. - Christian

2 4

Einstein Toolkit Meeting Reminder
by Frank Loeffler 21 Aug '11

21 Aug '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/community/support/ I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. My agenda will contain: - The CCE thorns moved into the dev-version of the ET A test thornlist is in manifest (CCE.th). It's not in the main thornlist mainly because I couldn't test it because servers are currently down (server move) - Are there new issues with hg carpet? - Are there new issues with python simfactory? - The fall workshop needs an announcement: we need to pick one, at maximum two topics for the ET session. - The spring workshop needs some planning to be able to at least get an idea of what to get money for, mainly: - Which topic? - What is target group? - How many people? - Whom to invite for talks/lectures? - The ET paper saw some progress. I now handle this by direct emails to section writers, but please comment if you like within the meeting. Frank Loeffler

1 0

IOJpeg change
by Steven R. Brandt 20 Aug '11

20 Aug '11

I'd like to propose the following change to IOJpeg. It gets rid of annoying error messages when one of the dimensions is one. if (CCTK_EQUALS(gridpoints, "hyperslab")) { /* now do the actual I/O looping over all directions */ for (dir = 0; dir < maxdir; dir++) { /* get the directions to span the hyperslab */ if (dir == 0) { dir_i = 0; dir_j = 1; /* xy */ if(GH->cctk_gsh[0]==1 || GH->cctk_gsh[1]==1) continue; } else if (dir == 1) { dir_i = 0; dir_j = 2; /* xz */ if(GH->cctk_gsh[0]==1 || GH->cctk_gsh[2]==1) continue; } else { dir_i = 1; dir_j = 2; /* yz */ if(GH->cctk_gsh[1]==1 || GH->cctk_gsh[2]==1) continue; } Cheers, Steve

1 0

Possible performance issue with some codes
by Ian Hinder 18 Aug '11

18 Aug '11

Hi, A change was made a few months ago to ADMBase to solve some problems with the ADMBase variables not being synchronised in some situations where they need to be. This was r59 in ADMBase SVN. The bit I'm worried about is this: +# For Mesh Refinement it is possible (eg Cowling approximation) that ADMBase variables will need synchronization even when not evolved (eg when a new refined grid appears) +if (CCTK_Equals(evolution_method, "static") || CCTK_Equals(evolution_method, "none") || CCTK_Equals(lapse_evolution_method, "static") || CCTK_Equals(shift_evolution_method, "static") || CCTK_Equals(dtlapse_evolution_method, "static") || CCTK_Equals(dtshift_evolution_method, "static") ) +{ + SCHEDULE ADMBase_Boundaries IN MoL_PostStep BEFORE ADMBase_SetADMVars + { + LANG: C + OPTIONS: LEVEL + SYNC: lapse + SYNC: dtlapse + SYNC: shift + SYNC: dtshift + SYNC: metric + SYNC: curv + } "Select ADMBase boundary conditions - may be required for mesh refinement" +} For any code which does not use the ADMBase::[lapse/shift]evolution_method parameters to control their evolution, unnecessary syncs will be performed for the ADMBase variables. Whereas before these parameters seemed to be a superfluous part of the ADMBase infrastructure (after all, why activate your evolution thorn if you're not going to evolve with it?), it now seems that it is essential to extend and use these parameters if you want to use ADMBase, or performance will suffer. The GT evolution code would suffer from this, the last time I looked at it, and other groups' codes might also. -- Ian Hinder ian.hinder(a)aei.mpg.de

4 7

Re: [Users] Reminder: Cactus support chat
by Ian Hinder 17 Aug '11

17 Aug '11

On 17 Aug 2011, at 05:00, knarf(a)cct.lsu.edu wrote: > Hi > > You are cordially invited to join our weekly Cactus support chat on > Wednesdays from 9am to 10am CDT/CST (central US timezone). > > The chat uses the EVO [1] collaboration software, which requires Java. > It also requires a valid login, but registration is free at > https://evo.caltech.edu/evoGate/Profile/register.jsp > > The EVO meeting URL is > http://evo.caltech.edu/evoNext/koala.jnlp?meeting=eleBevvsvIa8avaeIl > > In addition to the simple chat, EVO also offers audio/video conference > support as well as a view of remote desktops, which can make resolving > problems much easier in some cases. However, the typical support chat > doesn't make use of these additions, so it is ok to join e.g. without > sound or video support. > > The Cactus team > > [1] http://evo.caltech.edu/evoGate/ We decided in the ET telecon on Monday that a few of us would get together in this week's support chat and see how much progress we can make with addressing the tickets on trac.einsteintoolkit.org (this includes Cactus tickets as well as other ET tickets). We will try to close tickets that can be closed and test and apply patches for tickets which have them. Please consider joining in. -- Ian Hinder ian.hinder(a)aei.mpg.de

1 0

CCE tutorial
by Yosef Zlochower 16 Aug '11

16 Aug '11

Hi, Several weeks ago on an Einstein Toolkit telecon I was asked to prepare a tutorial on using CCE with the Einstein Toolkit. Maria Babiuc and I will be working on the tutorial. The slides describe how one should modify a BBH parameter file to output the Cauchy metric, compile and run utilities for modifying (filtering) and examining the data, and compiling and running the Pitt Null code (now available in the Incoming repository of the Einstein Toolkit) to produce the characteristic waveform on scri+. All the code required to run CCE is provided by the Einstein Toolkit (either in the standard toolkit, or in the Incoming repository). The slides, as well as a ThornList and parameter file are available at http://ccrg.rit.edu/~yosef/cce.html Let me know if there are any questions or requests for clarification. --

1 1

Wanted: PushComponents
by Erik Schnetter 16 Aug '11

16 Aug '11

I am dreaming of PushComponents, a simpler way to discuss patches, to commit them, and to ensure test cases don't silently begin to fail. Applying a patch to the Einstein Toolkit requires commonly several stages: - A problem or missing feature needs to be identified - There is a bit of discussion on the mailing list or in TRAC - A patch is created - The test cases are run - A patch is proposed - The patch is reviewed - The patch may be modified or updated - The test cases are run (again), hopefully on several systems - The committer applies the patch to a clean checkout, maybe runs the test cases again - The committer writes a commit message and commits/pushes the patch This is a bit more complicated if several thorns are involved, if the original patch author doesn't have commit rights, or if the underlying problem only occurs only on a specific system. I suggest to define a self-contained patch format, probably stealing the idea from git. This format would define the complete patch, possibly for several components, in such a way that a single command (PushComponents) can apply the patch, check for conflicts, create commit messages, and push the commits upstream. Ideally, it would also keep the distinction between author and committer. Building on this patch format, we would implement a script that 1. Checks out a clean copy of e.g. the Einstein Toolkit (GetComponents) 2. Applies the patch locally 3. Runs the test cases (and maybe also a specific parameter file) locally as well as on a set of remote systems (SimFactory) 4. Checks the results, and 5. If all is fine: commits and pushes the patch (PushComponents) In this way, the currently separate actions (apply a patch, test it, and commit it) are joined together in a way that is easy to use, and people are not tempted any more to commit patches without testing. If running the test cases takes an hour or two, this doesn't matter -- it's all automated, and it's all running in the background. If something fails, this isn't a burden either -- after all, one only has to run a single command to try again. To test whether the test suite returns the expected result, I suggest to keep track in which test cases failures may be temporarily ignored. This will allow us to use this new system right away, even before we have corrected all currently failing test cases. That is, each new commit may only reduce the number of failures. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

4 4

Meeting minutes
by Roland Haas 15 Aug '11

15 Aug '11

Meeting minutes: Present were: Peter, Erik, Frank, Eloisa, Ian, ROland, Tanja, Bruno, Yosef Carpet/Hg test runs: * AEI (Ian) ran a production type inspiral simulations and finds speed differences around 3% and waveform differences around 10^-4 which is below finite differencing errors. * however since vectorization does not yet work in Carpet/Hg and AEI usually uses it to obtain a 20% speed increase they will not use it in actual for-paper simulations * GT (Roland) ran a hydro simulation which so far produces similar results in git and hg, but has not progressed far due to issues with learning how to use simfactory Outstanding failing testsuites: * RotatingSymmetry180/90 works again with Carpet/Hg * QLM still fails (with MPI errors) Simfactory/python: * GT used simfactory/python for the first time, found it to be a large piece of software, would like more documentation and tutorials that are up-to-date * reiterate ticket 221 https://trac.einsteintoolkit.org/ticket/221 * RIT needs possibility to update parameter files in an ongoing simulation (already possible by modifying the file directly) * in summary: ** want more/corrected/updated documentation before the release (all contribute, please) ** maybe extract/incorporate documentation into python code to try and keep it up to date ** Erik will have a look at Ian's existing documentation http://www.aei.mpg.de/~ianhin/simfactory-userguide/ * wishlist (no particular order or priority): ** check for stalled simulations ** check when restarts fails continuously do to encountering the same error again and again ** copy input data files into simulation directory CCE: * try to simplify setup of parameters (relation between them) * check if unigrid Carpet can be used instead of PUGH as well (Yosef thinks is should but is not quite sure) * copy only required thorns from incoming to ET, leave out the ones that are not supported * Caltech extraction thorn (Worldtube) still finds NaNs, hopes to fix by end of month Fall meeting: * see reminder email: > - The fall workshop will be a "two-track" workshop, in the following > sense: There will be a ET-workshop, covering a selection of > mhd/eos/radiation transport questions. Here we need to decide on > which topic and someone to invite (but without financial support > at this point). > There will also be a Cactus-workshop, at the same time, the same > building, sharing the same room for part of the time, sharing some > discussions, and of course sharing the breaks. This is for people > with only moderate interest in the ET workshop topics, but greater > interest in infrastructure development. Prime candidates for > topics here are improved Cactus scheduling and GPGPU support. > > I am happy to be able to say that coffee breaks are covered from LSU > side. Transportation, usual meals and hotels have to be covered by > the participants though. Information to suggested hotels ect isn't > available yet. MHD: * harmonic shift in McLachlan patch does not currently work, Ian and Bruno will work on 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.

1 0

Restart problem from checkpoint files
by Kentaro Takami 15 Aug '11

15 Aug '11

Hi, all, In git version of Carpet, I have restart problem from check point files. When I restart the simulation, the code is crashed and I receive the following errors: [takami-laptop:12229] *** Process received signal *** [takami-laptop:12229] Signal: Segmentation fault (11) [takami-laptop:12229] Signal code: Address not mapped (1) [takami-laptop:12229] Failing at address: 0x4c0 [takami-laptop:12229] [ 0] /lib/libpthread.so.0(+0xf8f0) [0x7ff7ea8588f0] The problem is related with the parameter 'adm_bssn::bound = "radiative"' in BSSN_MoL, because if we use 'adm_bssn::bound = "newrad"', I can restart the simulation without any error. When I use old Carpet, IOASCII, IOBasic, IOUtil (I don't know the version, because I got them created by Formaline thorn in old my simulation), I don't have any error even if I use "radiative" parameter. -- ////////////////////////////////////////////////////////////// // // NAME : Kentaro Takami // E-MAIL : kentaro.takami(a)aei.mpg.de // ADDRESS : Max-Planck-Institute for Gravitational Physics // Albert-Einstein-Institute // Am Muhlenberg 1 // 14476 Golm // Germany. // //////////////////////////////////////////////////////////////

3 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users August 2011