Users

users@lists.einsteintoolkit.org

3 participants
3983 discussions

Failing AHFinderDirect test cases.
by Peter Diener 02 Jun '10

02 Jun '10

Hi, I have been looking at why some of AHFinderDirect test cases fail. First I checked the tests running on 1 processor and found that the cause of the failing test cases was a bug fix made in 2005 where the tests had not been updated afterwards. For those tests I regenerated the output. One additional test failed by not producing output because it didn't converge to the specified tolerance. I wasn't able to find a version of the code (after the date that the test case had been created) that I was able to compile and that passed the test. For that reason (after discussing with Erik) I disabled that test by renaming the parameter file to someting not ending in .par. After that I realized that a lot of the tests failed when running on 2 procs. After some investigating, I realized that the cause was to be find in Exact. When going from 1 to 2 procs, the coordinates setup by CoordBase and CartGrid3d can differ at the roundoff level. In the particular case I was looking at in one case the y-coordinate was -3.3999999999999999 while in the other it was: -3.4000000000000004 so a difference only in the last digit. This introduced a difference of the computed 4-metric in the 2 last digits. Now Exact uses 2nd order finite differencing with an epsilon of 1.e-6 to calculate time derivatives of the 3-metric and and the spatial derivatives of the shift that is needed to calculate the extrinsic curvature. In this process there is a significant cancelletion of digits leading to a loss of 6-7 digits so the extrinsic curvature only agreed to 9-10 digits. In other grid points the coordinates were identical and so was the extrinsic curvature. So essentially the process of constructing the extrinsic curvature iteself lead to some arbitrary noise at the 9-10 digit level. When this was fed into AHFinderDirect the differences were amplified even more leading to differences in the mass at the 6th digit level. Currently Erik is working on improving this (by using higher order finite differencing with a larger epsilon), but the main conclusion is that we have to be very careful when making tests based on initial data from the current version of Exact and may have to reduce the accuracy criteria for pass/fail significantly. Cheers, Peter

3 2

Meeting Notes Jun 1st
by Frank Loeffler 01 Jun '10

01 Jun '10

Hi, here are the notes of today's meeting: The main topic was how the future development of the ET should happen. First, Erik explained what the current (not yet that old) policy states: 1 There will be stable branches from time to time 2 There is one development branch for most of the development 3 There might be extra branches if wished for. Commits to 1 and 2 have to have a review, unless they are trivial, development in 3 is up to the maintainer of that branch. Christian and Roland (?) said they thought the reviews only apply to 1, not also 2. Frank suggested to go with Christians email-suggestion, which would: - try to avoid branches, but might have - have stable branches - have (almost) free development in /trunk Frank noted that in order to achieve stable branches, a more or less regular freeze of /trunk would be necessary: no further development, only bug fixes. One of Christian's arguments against a lot of branches was that keeping them in sync with the main development branch takes a lot of time which could be better spent. This often leads to diverging branches which are never really merged. Ian Hinder generally does not mind to handle multiple branches. Roland Haas suggested to maybe add one more level: in addition to stable and development there could be an experimental branch which would be free for any type of development while the development branch is only updated from the experimental branch from time to time, as the stable branch is from the development branch. This didn't find another supporter. Erik noted that with free development inside /trunk (the development branch) it would not be stable enough to be used for production - anything might break after an update. This means there have to be regular updates of the stable versions from the development version to be able to take advantage of new features. Erik asked what a good time for such a cycle would be and suggested 3-6 months. Nobody objected. Everyone was requested to voice her/his opinion about this topic, and everyone on the call (except Pablo, who had dropped off) agreed on Christian's suggestion (with a few additions from todays meeting): 1 There will be stable branches from time to time, targeting at about every 3-6 months. Commits to these branches needs a code review unless trivial. 2 Most of the development will happen in the development branch, which is /trunk. No special policy for commit is in place there, common sense rules. 3 There will be a freeze from time to time to move changes in the development branch to a new stable branch. When and how long such a freeze happens will be discussed. 4 There might be extra branches with their maintainers being responsible to enforce any policy they like. Erik suggested to start with a freeze to get a first stable release before starting to implement MHD into GRHydro. He estimated the time to 1-2 weeks. Christian agreed that this delay wouldn't be a problem for the MHD development. Christian asked if there is a tutorial of how to create a good testsuite, but nobody could name something like that apart from a small part of the Cactus documentation. Everybody agreed that this should be improved, but nobody volunteered to be responsible for this. So: everyone is invited to see if she/he could add tips to the Cactus documentation. It was also noted that most discussions should happen on the users@einsteintoolkit mailing list and only the "boring administrative stuff" should be sent to the maintainers list. Last but not least, the main topic for next week's meeting will be how MHD will be implemented in GRHydro: figuring out who does what and probably also how and when. Next week's meeting will take place at it's usual time: Mon, Jun 7th at 10am CDT, with the usual phone information: Each participant of the teleconference will call 578-4942 (225-578-4942 from off-campus or 866-573-0359 toll free). Participants will press 118682# for Conference Line one. Frank

1 0

Reminder: Temporary move of the Einsteintoolkit phone call
by Frank Loeffler 01 Jun '10

01 Jun '10

On Fri, May 28, 2010 at 02:14:20PM -0500, Frank Loeffler wrote: > We will try to move the usual time for the Einstein toolkit phone call > (also known as Xirel/CIGR phone call) just for one week (number 22) from > Mon (May 31st) to Tue (June 1st). We will have out weekly phone call tomorrow, June 1st at 10am CET. Frank Loeffler

2 3

Temporary move of the Einsteintoolkit phone call next week
by Frank Loeffler 28 May '10

28 May '10

Hi, We will try to move the usual time for the Einstein toolkit phone call (also known as Xirel/CIGR phone call) just for one week (number 22) from Mon (May 31st) to Tue (June 1st). I created a doodle poll to have an overview when people will be available. Please indicate you choices here: http://www.doodle.com/cu77wrvwa5saqn8b Frank Loeffler

1 0

compilation problem on 10.6.3 macbook pro
by Babiuc-Hamilton, Maria 27 May '10

27 May '10

Hello, I am trying to compile a thorn arrangement for the qc0-mclachlan.par parameter file, with the einsteintoolkit.th on a macbook pro 10.6.3 intel core i7. I have attached the configuration file I am using and the output of the compilation errors. The errors are of type: Undefined symbols: "_ompi_mpi_comm_null", referenced from: MPI::Cartcomm::Clone() const in libthorn_CarpetSlab.a(mapping.cc.o) etc.... "MPI::Win::Set_errhandler(MPI::Errhandler const&)", referenced from: vtable for MPI::Win in libthorn_CarpetSlab.a(mapping.cc.o) etc..... please help, Maria

4 11

w_lorentz factor in TOVSolver external.inc
by Roland Haas 27 May '10

27 May '10

Hello all, the attached patch should to fix what seems to be a wrong definition of the Lorentz factor in the source term computation of TOVSolver. This is only needed for non-zero speeds. Both patched and unpatched versions pass (TwoPunctures') bhns-eval testsuite (since the testsuite does not test non-zero speeds). Ok to apply? 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.

5 10

wrong linking address on EinsteinToolkit website
by Jian Tao 27 May '10

27 May '10

Hi, On the tutorial page, http://einsteintoolkit.org/info/documentation/tutorial.php The link to "thornlist for the Einstein Toolkit" doesn't work. Regards, Jian

6 8

Re: [Users] [Commits] [svn:einsteintoolkit] GRHydro/trunk/ (Rev. 115)
by Frank Loeffler 26 May '10

26 May '10

Hi, On Wed, May 26, 2010 at 11:40:05PM +0000, cott(a)einsteintoolkit.org wrote: > * initial structural modifications to start with MHD development (Noble/Ott) Could we do that in a separate branch until it works in at least some basic way? This way not every commit would have to be reviewed by another maintainer. Frank

1 0

Re: [Users] [Commits] [svn:einsteintoolkit] GRHydro/trunk/src/ (Rev. 116)
by Roland Haas 26 May '10

26 May '10

Hello all, On 05/26/2010 07:44 PM, cott(a)einsteintoolkit.org wrote: > User: cott > Date: 2010/05/26 06:44 PM > > Modified: > /trunk/src/ > GRHydro_Con2PrimM.F90 > > Log: > * tiny I would like to suggest to create a development branch for the MHD development so that GRHydro/trunk is more or less stable when we release the Einstein Toolkit. Yours, Roland

1 0

Problem compiling the Einstein Toolkit on Kraken
by Barry Wardell 25 May '10

25 May '10

Hi, I have been trying to compile the Einstein Toollkit on Kraken and have encountered a problem with the AHFinder thorn. I looks to me like a compiler problem. The error message I get is: Preprocessing /nics/a/proj/cactus/barrywar/xt5/Cactus/arrangements/EinsteinAnalysis/AHFinder/src/AHFinder_pow.F Compiling /nics/a/proj/cactus/barrywar/xt5/Cactus/arrangements/EinsteinAnalysis/AHFinder/src/AHFinder_pow.F *** glibc detected *** /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902: realloc(): invalid next size: 0x00000000009f2e80 *** ======= Backtrace: ========= /lib64/libc.so.6[0x2b93a06a534e] /lib64/libc.so.6[0x2b93a06a7fbd] /lib64/libc.so.6(__libc_realloc+0x11c)[0x2b93a06a925c] /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902[0x42a628] /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902[0x442772] /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902[0x437d66] /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902[0x62d2d5] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b93a0657154] /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902(tolower+0x3a)[0x4030aa] ======= Memory map: ======== 00400000-007de000 r-xp 00000000 00:10 4860079 /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902 008de000-00919000 rwxp 003de000 00:10 4860079 /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902 00919000-00ad5000 rwxp 00919000 00:00 0 [heap] 2b93a051e000-2b93a0539000 r-xp 00000000 00:10 7042057 /lib64/ld-2.4.so 2b93a0539000-2b93a053f000 rwxp 2b93a0539000 00:00 0 2b93a056e000-2b93a056f000 rwxp 2b93a056e000 00:00 0 2b93a0590000-2b93a05d7000 rwxp 2b93a053f000 00:00 0 2b93a0638000-2b93a063a000 rwxp 0001a000 00:10 7042057 /lib64/ld-2.4.so 2b93a063a000-2b93a0761000 r-xp 00000000 00:10 7041955 /lib64/libc-2.4.so 2b93a0761000-2b93a0861000 ---p 00127000 00:10 7041955 /lib64/libc-2.4.so 2b93a0861000-2b93a0864000 r-xp 00127000 00:10 7041955 /lib64/libc-2.4.so 2b93a0864000-2b93a0866000 rwxp 0012a000 00:10 7041955 /lib64/libc-2.4.so 2b93a0866000-2b93a086c000 rwxp 2b93a0866000 00:00 0 2b93a086c000-2b93a0876000 r-xp 00000000 00:10 7041972 /lib64/libnss_files-2.4.so 2b93a0876000-2b93a0975000 ---p 0000a000 00:10 7041972 /lib64/libnss_files-2.4.so 2b93a0975000-2b93a0977000 rwxp 00009000 00:10 7041972 /lib64/libnss_files-2.4.so 2b93a0977000-2b93a0989000 r-xp 00000000 00:10 7042051 /lib64/libnss_ldap.so.2 2b93a0989000-2b93a0a88000 ---p 00012000 00:10 7042051 /lib64/libnss_ldap.so.2 2b93a0a88000-2b93a0a8a000 rwxp 00011000 00:10 7042051 /lib64/libnss_ldap.so.2 2b93a0a8a000-2b93a0a95000 rwxp 2b93a0a8a000 00:00 0 2b93a0a95000-2b93a0ace000 r-xp 00000000 00:10 10175636 /usr/lib64/libldap-2.3.so.0.2.20 2b93a0ace000-2b93a0bce000 ---p 00039000 00:10 10175636 /usr/lib64/libldap-2.3.so.0.2.20 2b93a0bce000-2b93a0bd0000 rwxp 00039000 00:10 10175636 /usr/lib64/libldap-2.3.so.0.2.20 2b93a0bd0000-2b93a0bdd000 r-xp 00000000 00:10 10175634 /usr/lib64/liblber-2.3.so.0.2.20 2b93a0bdd000-2b93a0cdd000 ---p 0000d000 00:10 10175634 /usr/lib64/liblber-2.3.so.0.2.20 2b93a0cdd000-2b93a0cde000 rwxp 0000d000 00:10 10175634 /usr/lib64/liblber-2.3.so.0.2.20 2b93a0cde000-2b93a0cf5000 r-xp 00000000 00:10 10125323 /usr/lib64/libgssapi_krb5.so.2.2 2b93a0cf5000-2b93a0df5000 ---p 00017000 00:10 10125323 /usr/lib64/libgssapi_krb5.so.2.2 2b93a0df5000-2b93a0df6000 rwxp 00017000 00:10 10125323 /usr/lib64/libgssapi_krb5.so.2.2 2b93a0df6000-2b93a0df8000 r-xp 00000000 00:10 7041961 /lib64/libdl-2.4.so 2b93a0df8000-2b93a0ef8000 ---p 00002000 00:10 7041961 /lib64/libdl-2.4.so 2b93a0ef8000-2b93a0efa000 rwxp 00002000 00:10 7041961 /lib64/libdl-2.4.so 2b93a0efa000-2b93a0f0d000 r-xp 00000000 00:10 7041966 /lib64/libnsl-2.4.so 2b93a0f0d000-2b93a100c000 ---p 00013000 00:10 7041966 /lib64/libnsl-2.4.so 2b93a100c000-2b93a100e000 rwxp 00012000 00:10 7041966 /lib64/libnsl-2.4.so 2b93a100e000-2b93a1010000 rwxp 2b93a100e000 00:00 0 2b93a1010000-2b93a1021000 r-xp 00000000 00:10 7041983 /lib64/libresolv-2.4.so 2b93a1021000-2b93a1120000 ---p 00011000 00:10 7041983 /lib64/libresolv-2.4.so 2b93a1120000-2b93a1122000 rwxp 00010000 00:10 7041983 /lib64/libresolv-2.4.so 2b93a1122000-2b93a1124000 rwxp 2b93a1122000 00:00 0 2b93a1124000-2b93a113b000 r-xp 00000000 00:10 10125347 /usr/lib64/libsasl2.so.2.0.21 2b93a113b000-2b93a123b000 ---p 00017000 00:10 10125347 /usr/lib64/libsasl2.so.2.0.21 2b93a123b000-2b93a123c000 rwxp 00017000 00:10 10125347 /usr/lib64/libsasl2.so.2.0.21 2b93a123c000-2b93a127c000 r-xp 00000000 00:10 10125317 /usr/lib64/libssl.so.0.9.8 2b93a127c000-2b93a137c000 ---p 00040000 00:10 10125317 /usr/lib64/libssl.so.0.9.8 2b93a137c000-2b93a1382000 rwxp 00040000 00:10 10125317 /usr/lib64/libssl.so.0.9.8 2b93a1382000-2b93a14c0000 r-xp 00000000 00:10 10175951 /usr/lib64/libcrypto.so.0.9.8 2b93a14c0000-2b93a15bf000 ---p 0013e000 00:10 10175951 /usr/lib64/libcrypto.so.0.9.8 2b93a15bf000-2b93a15e1000 rwxp 0013d000 00:10 10175951 /usr/lib64/libcrypto.so.0.9.8 2b93a15e1000-2b93a15e5000 rwxp 2b93a15e1000 00:00 0 2b93a15e5000-2b93a1659000 r-xp 00000000 00:10 10125337 /usr/lib64/libkrb5.so.3.2 2b93a1659000-2b93a1759000 ---p 00074000 00:10 10125337 /usr/lib64/libkrb5.so.3.2 2b93a1759000-2b93a175d000 rwxp 00074000 00:10 10125337 /usr/lib64/libkrb5.so.3.2 2b93a175d000-2b93a177f000 r-xp 00000000 00:10 10125327 /usr/lib64/libk5crypto.so.3.0 2b93a177f000-2b93a187e000 ---p 00022000 00:10 10125327 /usr/lib64/libk5crypto.so.3.0 2b93a187e000-2b93a1880000 rwxp 00021000 00:10 10125327 /usr/lib64/libk5crypto.so.3.0 2b93a1880000-2b93a1882000 r-xp 00000000 00:10 7041964 /lib64/libcom_err.so.2.1 2b93a1882000-2b93a1981000 ---p 00002000 00:10 7041964 /lib64/libcom_err.so.2.1 2b93a1981000-2b93a1982000 rwxp 00001000 00:10 7041964 /lib64/libcom_err.so.2.1 2b93a1982000-2b93a1985000 r-xp 00000000 00:10 10125339 /usr/lib64/libkrb5support.so.0.0 2b93a1985000-2b93a1a84000 ---p 00003000 00:10 10125339 /usr/lib64/libkrb5support.so.0.0 2b93a1a84000-2b93a1a85000 rwxp 00002000 00:10 10125339 /usr/lib64/libkrb5support.so.0.0 2b93a1a85000-2b93a1a89000 r-xp 00000000 00:10 7041970 /lib64/libnss_dns-2.4.so 2b93a1a89000-2b93a1b88000 ---p 00004000 00:10 7041970 /lib64/libnss_dns-2.4.so 2b93a1b88000-2b93a1b8a000 rwxp 00003000 00:10 7041970 /lib64/libnss_dns-2.4.so 2b93a1c00000-2b93a1c21000 rwxp 2b93a1c00000 00:00 0 2b93a1c21000-2b93a1d00000 ---p 2b93a1c21000 00:00 0 2b93a1d00000-2b93a1d0d000 r-xp 00000000 00:10 7041994 /lib64/libgcc_s.so.1 2b93a1d0d000-2b93a1e0c000 ---p 0000d000 00:10 7041994 /lib64/libgcc_s.so.1 2b93a1e0c000-2b93a1e0d000 rwxp 0000c000 00:10 7041994 /lib64/libgcc_s.so.1 7fff0a571000-7fff0a58c000 rwxp 7fff0a571000 00:00 0 [stack] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] pgf90-Fatal-/opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902 TERMINATED by signal 6 Arguments to /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902 /opt/pgi/9.0.4/linux86-64/9.0-4/bin/pgf902 /tmp/pgf90wDYfc7plxihs.ilm -fn /nics/a/proj/cactus/barrywar/xt5/Cactus/configs/ET/build/AHFinder/AHFinder_pow.f -debug -x 120 0x200 -opt 3 -terse 1 -inform warn -x 51 0x20 -x 119 0xa10000 -x 122 0x40 -x 123 0x1000 -x 127 4 -x 127 17 -x 19 0x400000 -x 28 0x40000 -x 70 0x8000 -x 122 1 -quad -vect 56 -y 34 16 -x 34 0x8 -x 32 1048576 -y 19 8 -y 35 0 -x 42 0x30 -x 39 0x40 -x 39 0x80 -x 34 0x400000 -x 149 1 -x 150 1 -x 59 4 -x 59 4 -tp k8-64e -x 124 0x1400 -y 15 2 -x 57 0x3b0000 -x 58 0x48000000 -x 49 0x100 -x 120 0x200 -astype 0 -x 121 1 -x 124 1 -x 125 0x200 -x 9 1 -x 42 0x14200000 -x 72 0x1 -x 136 0x11 -x 80 0x800000 -quad -x 119 0x10000000 -x 129 0x40000000 -x 129 2 -mp -x 69 0x200 -x 69 0x400 -x 0 0x1000000 -x 2 0x100000 -x 0 0x2000000 -x 161 0xcff7 -x 162 0xcff7 -x 0 0x1000000 -x 2 0x100000 -x 0 0x2000000 -x 161 128 -x 162 128 -x 161 53239 -x 162 53239 -x 0 0x2000000 -cmdline '+pgf90 /nics/a/proj/cactus/barrywar/xt5/Cactus/configs/ET/build/AHFinder/AHFinder_pow.f -g -Mx,125,0x200 -fastsse -fast -Mvect=sse -Mscalarsse -Mcache_align -Mflushz -O3 -Mvect=assoc -mp=nonuma -Minfo -Minfo=mp -Mneginfo -c -o /nics/a/proj/cactus/barrywar/xt5/Cactus/configs/ET/build/AHFinder/AHFinder_pow.F.o' -asm /tmp/pgf90MDYfYzxbMlTG.sm make[3]: *** [AHFinder_pow.F.o] Error 127 make[2]: *** [make.checked] Error 2 make[1]: *** [/nics/a/proj/cactus/barrywar/xt5/Cactus/configs/ET/lib/libthorn_AHFinder.a] Error 2 make: *** [ET] Error 2 Uncaught exception from user code: Error 2 occurred while executing command "make -j2 ET" at /nics/a/proj/cactus/barrywar/xt5/Cactus/simfactory/sim line 4500. at /nics/a/proj/cactus/barrywar/xt5/Cactus/simfactory/sim line 4500 main::execute('make -j2 ET') called at /nics/a/proj/cactus/barrywar/xt5/Cactus/simfactory/sim line 1682 main::command_build('ET') called at /nics/a/proj/cactus/barrywar/xt5/Cactus/simfactory/sim line 448 Does anybody have an idea how to fix this? Barry

2 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users