Users December 2011

users@lists.einsteintoolkit.org

16 participants
29 discussions

Restarting from a checkpoint with simfactory
by Kyriaki Dionysopoulou 19 Dec '11

19 Dec '11

Hi all, I recently updated my simfactory and since then I'm not able to restart from a checkpoint if I don't specify the checkpoint output and recover directories explicitly in the parfile. Since before I updated I was able to do that without specifying the checkpoint output/recover directories I'm just wondering if there is an intentional change in simfactory's default behavior or if this is a bug that I should report on TRAC. I attach a simple test parfile that reproduces the problem and a basic thornlist. The default location for the checkpoint output/recover directories should be output-XXXX. Cheers, Kiki -- Kyriaki Dionysopoulou Max Planck Institute for Gravitational Physics Albert Einstein Institute Am Muehlenberg 1 D-14476 Potsdam Germany Tel. : +49 331 567 7185 Fax : +49 331 567 7298 email : Kyriaki.Dionysopoulou(a)aei.mpg.de

2 1

How to review a patch
by Erik Schnetter 19 Dec '11

19 Dec '11

I feel it is a good idea to describe what we want to achieve by having many of our small patches to the Einstein Toolkit reviewed before they are accepted, because the discussion surrounding these patches is sometimes going into strange directions. -erik For contributing a new small feature or a modification to the Einstein Toolkit, we are using Trac to review changes before they are applied to the code. This review serves several purposes, such as: 1. Some of the basic infrastructure code is used by many people, and we want a second pair of eyeballs to look at the code to catch errors and omissions early. Some problems occur only on a few machines, and if an experienced user looks at the code, he/she may notice something that otherwise goes undetected for a long time. 2. There exists a loosely-defined strategic plan for the Einstein Toolkit and its components, and we want to make sure that the individual contributions go roughly in the right direction, or (more importantly) don't accidentally undo a feature that is important for us. 3. Exposing changes to the public before they are applied is a good way to make people think before they commit, thus helping avoid sloppy mistakes. It follows from this that contributions to code that is new or that is actively developed doesn't really need to be reviewed. Similarly, "obvious" things should be corrected without review. If a modification concerns only a few lines of code and it is easily undone, it doesn't need much of a discussion (since, if things go wrong, it can easily be undone!). If a contribution or a patch is out for review, we are asking you to help, in particular by addressing the following questions: 1. Is there something obviously wrong with the code? Is there a tricky corner case in C/C++/Fortran/Perl/Bash that this code triggers, or would it break on some of the stranger supercomputers we use? Does the contribution contain a "d'oh!" kind of error? Is there a possible weird and unexpected interaction with other components of the ET, in particular if these have "well-known bugs"? 2. Is this contribution a step in the wrong direction for the overall ET? (In many cases this question is not relevant.) Does it somehow impede MHD, radiation transport, increased parallel scalability? Does it invite people to make errors that are difficult to detect? Does it introduce a lot of complicated code that isn't really necessary? In most cases it is not necessary to apply the patch or run the code for this review. This a review, not a test -- reviewing a paper doesn't require repeating a calculation presented in the paper (except in rare cases), it only requires understanding it. A contribution or a patch is not a duty that is delivered by a petitioner to us, the gatekeepers of the sanctuary. A contribution is a present, a gift to be cherished; it should be treated as a valuable and precious item. We only want to make sure there is no poison in there; apart from this, the simplest of gifts is still a gift that we are happy to receive. For example, if the discussion is heading towards one of the topics below, this big picture has been lost, and the review process is often not useful any more: 1. Checking whether the patch applies cleanly. Especially if a patch has been sitting on the shelves for a few months, things may have changed, or the patch may depend on another patch. We can assume that people with commit rights will be able to make small modifications while applying a patch, will check whether the code builds, and will run the test suite if necessary. And if things break, things can be corrected later, or even undone. 2. Running the code to perform a quick check whether the patch actually implements the feature that it is advertised to implement. We can assume that the contributor describes the changes to the best of his/her knowledge, and should trust this description. On the other hand, discovering corner cases where things may fail usually requires examining the code, not just running it. 3. Reminding the contributor to update the documentation or add a test case. These go without saying, and if the contributor forgets, he/she can be reminded afterwards. (Or someone else may step in and provide these.) 4. Rejecting a contribution only because there is a better way of implementing it. It is ok to reject a patch if it is badly written, or if there is a better implementation already underway. But rejecting a contribution simply because it would be cleaner to do things differently, and without volunteering the time to work on such a better alternative, is unfair. Presumably, once the better alternative arrives (if it every arrives), the current implementation can be removed again. ("A bird in the hand is worth two in the bush.") 5. Asking the contributor to split up the patch into multiple, inter-dependent contributions, unless it this truly necessary. There is much to be said for providing contributions in small, self-contained units, and to not mix unrelated contributions. However, there is also a limit to this, because each contribution needs to be prepared, tested, and reviewed (and reviewing is currently a bottleneck). If two related features were developed together, then they should be reviewed together. 6. Small, nit-picking comments along the line of "you should have done it this way, but now that you didn't, we're accepting your contribution anyway". The ET is not perfect (and will never be), our contributions are not perfect either, and nit-picking while reviewing does not create the kind of generous atmosphere where newcomers feel invited to contribute. -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

Re: [Users] [svn:cactuscode] OpenMPI/trunk/ (Rev. 5)
by Erik Schnetter 19 Dec '11

19 Dec '11

Bruno This change sets OPENMPI_INC_DIRS unconditionally, overwriting the user's configuration. If you look further down in the file, you will see the line : ${OPENMPI_INC_DIRS="${OPENMPI_DIR}/include"} which sets OPENMPI_INC_DIRS iff the user has not already set it. That is, your change should not be necessary. I will revert this change. -erik On Mon, Dec 19, 2011 at 1:05 AM, <bcmsma(a)astro.rit.edu> wrote: > User: bmundim > Date: 2011/12/19 12:05 AM > > Modified: > /trunk/ > configure.sh > > Log: > Indicate include and lib directories when building this library. > > File Changes: > > Directory: /trunk/ > ================== > > File [modified]: configure.sh > Delta lines: +2 -0 > =================================================================== > --- trunk/configure.sh 2011-12-19 04:12:48 UTC (rev 4) > +++ trunk/configure.sh 2011-12-19 06:05:49 UTC (rev 5) > @@ -84,6 +84,8 @@ > fi > DONE_FILE=${SCRATCH_BUILD}/done/${THORN} > OPENMPI_DIR=${INSTALL_DIR} > + OPENMPI_INC_DIRS=${OPENMPI_DIR}/include > + OPENMPI_LIB_DIRS=${OPENMPI_DIR}/lib > > ( > exec >&2 # Redirect stdout to stderr > > _______________________________________________ > Commits mailing list > Commits(a)cactuscode.org > http://cactuscode.org/mailman/listinfo/commits > -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

2 1

Problems with mpich2
by jhar131＠cct.lsu.edu 18 Dec '11

18 Dec '11

When attempting to build a simulation (in fedora), I encounter an undefined reference error pertaining to MPI. I have installed mpich2 and mpich2-devel both automatically with yum -y as suggested in the notation; as well as manually after this error. Any suggestions? Creating cactus_Test in /home/joshua/Cactus/exe from CactusBase/Boundary CactusBase/CartGrid3D CactusBase/CoordBase CactusConnect/HTTPD CactusConnect/HTTPDExtra CactusWave/IDScalarWaveC CactusBase/IOASCII CactusBase/IOBasic CactusIO/IOJpeg CactusBase/IOUtil CactusPUGHIO/IsoSurfacer CactusBase/LocalReduce CactusPUGH/PUGH CactusPUGH/PUGHReduce CactusPUGH/PUGHSlab CactusConnect/Socket CactusBase/SymBase CactusBase/Time CactusWave/WaveBinarySource CactusWave/WaveToyC ExternalLibraries/libjpeg /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trid' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trvalid' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_env2int' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trrealloc' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trspace' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trDebugLevel' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_TrSetMaxMem' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trlevel' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trmalloc' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_env2bool' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_env2range' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trcalloc' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trfree' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_env2str' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trstrdup' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trdump' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trinit' collect2: ld returned 1 exit status

4 6

Einstein Toolkit Meeting Reminder
by Frank Loeffler 18 Dec '11

18 Dec '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#. Topics are welcome from everyone. Because this is the last meeting this year however I don't expect important issues to be discussed as some might already have left for holidays. The first meeting next year will be held Monday, January 9th at the usual time. Frank Loeffler

1 0

ADMMass thorn
by Ian Hinder 16 Dec '11

16 Dec '11

Hi, There is a thorn AEIThorns/ADMMass which computes the ADM mass of a spacetime. I have recently been asked why this thorn is not included in the ET. According to its README file, the thorn was written by Frank Loeffler and is GPL. It has been contributed to by Frank, Luca and Erik. It has a test suite but no documentation. Should we aim to include this thorn in the next release? Is the functionality to compute the ADM mass available elsewhere in the ET? -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

5 6

Problem with CarpetRegrid2/AMR
by Hal Finkel 15 Dec '11

15 Dec '11

I am trying to setup a simple simulation using CarpetRegrid2's AMR capability. As Erik has already pointed out to me (off list), the adaptive-refinement triggering code is still under development. Nevertheless, I would really like to get it working. In my current test case, I am using Kranc to solve a Klein-Gordon equation (with a non-linear potential). With the provided initial conditions, the system has an expanding bubble. This works well when refinement is turned off. To be clear, the evolution equation is: evolCalc = { Name -> "SFBubble_Evolve", Schedule -> {"in MoL_CalcRHS"}, Where -> Interior, Shorthands -> {}, Equations -> { dot[chi] -> chiM, dot[chiM] -> PD[chi,li,lj] Euc[ui,uj] - Vchi[chi] } }; where Vchi[chi_] := V'[chi] (V is the potential). The AMR level_mask is set by: lvlmskSet = { Name -> "SFBubble_SetLevelMask", Schedule -> {"AT preregrid"}, Where -> Interior, Shorthands -> { adchix, adchiy, adchiz }, Equations -> { adchix -> fabs[dx PD[chi,1]], adchiy -> fabs[dy PD[chi,2]], adchiz -> fabs[dz PD[chi,3]], "level_mask" -> ( Max[ adchix, adchiy, adchiz ]/dchimax ) /. Max[a_, b_, c_] -> fmax[a, fmax[b, c]] } }; (in words: the value of chi should not change by more than dchimax over the length of one grid cell) I am using the Periodic thorn to provide periodic boundary conditions. I've attached six pictures. They are at t = 0, the first level 1 intermediate time step, and the first coarse time step. The first three pictures are the value of chi on a slice through the middle of the box. The second three pictures are the value of level_mask. As can be seen in the second chi image, the interpolation into the refined region seems to be incorrect. The "boundary" seems to have appeared in the middle of the block. I have also attached the block descriptions. Is there something I could be doing incorrectly which would cause this? Otherwise, does anyone have any ideas on where to look for the problem? I am using the trunk version as of this morning. Thank you in advance, Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

6 46

Possible Carpet issue with Maxwell version of ET
by Yosef Zlochower 14 Dec '11

14 Dec '11

Hi, I am trying some simulations using the Maxwell version of ET and the LazEv evolution thorn. In the thorn, I define a 1 timelevel GF dotalp which is never synchronized. A test run died with the following error: WARNING level 0 in thorn CarpetLib processor 0 host n0024.cluster (line 385 of /nfs.data/temphome/yosef/ET_STABLE/Maxwell/Cactus/arrangements/Carpet/CarpetLib/src/gdata.cc): -> Internal error: extrapolation in time. variable=LAZEV::dotalp time=118.90625 times=[118.9375] I am unsure how the times could have gotten out of sync at such a late time in the simulation without getting out of sync earlier. I also do not understand why a time interpolation should have been attempted in the first place. I don't sync or attempt to interpolate this GF.

3 8

Problem by installing the ETK
by Jose Fiestas Iquira 13 Dec '11

13 Dec '11

Dear colleagues, I am a new user of the ETK. While installing it in my laptop I realized I needed git and hg to be able to copy the data. So I did. Now I am asked for a password: carpetmercurial(a)carpetcode.org's password: I can not get over this problem. Can I just break the installation? Will it work? Thank you, Jose Fiestas PS. I just apply for an account at LONI and am following the instructions to get it.

2 3

Meeting minutes
by Roland Haas 12 Dec '11

12 Dec '11

Hello all, present were: Erik, Frank, Christian, Tanja, Ian, Yosef, Eloisa, Bruno Giacomazzo, Josh, Bruno, Steve ET seminars: * only single proposal, by Ian Hawke * will ask Ian for presentation, likely not during usual timeslot due to conflicts, will have doodle poll for suitable time (will be in January) new thorns: * Erik has written infrastructure to have MPI as a thorn in ExternalLibraries * this requires that thorns that explicitly use MPI add a REQUIRE MPI into their configuration.ccl * add NoMPI into this framework * Erik has already submitted the patch for review (https://trac.einsteintoolkit.org/ticket/686 and https://trac.einsteintoolkit.org/ticket/685 which are prerequisites, a thorn OpenMPI is written but not yet in incoming) Alpaca: * Steve suggests to present Alpaca at Whist12 (with Oleg managing details): http://wwwx.cs.unc.edu/~tgamblin/whist-2012/index.html Simfactory: * Ian, Erik and maybe Barry will (virtually) meet for a bug squashing/ticket closing session. Times to be agreed upon. 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 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users December 2011