Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Re: [Users] [Commits] [svn:einsteintoolkit] ADMMacros/trunk/src/macro/ (Rev. 107)
by Ian Hinder 05 Nov '10

05 Nov '10

On 4 Nov 2010, at 23:55, diener(a)cct.lsu.edu wrote: > User: diener > Date: 2010/11/04 05:55 PM > > Modified: > /trunk/src/macro/ > DXYDG_undefine.h > > Log: > Undefine the guts instead of the declare. This bug has been there > since the > beginning and showed up when using ADM with the leapfrog scheme > using a > predictor-corrector step at the first iteration. The source code to > calculate > the second derivative of the matric with respect to x and y was not > included > in the pre-processed source code for the corrector step, resulting > in the > value calculated for the last point in the predictor step was used for > all grid points. This lead to wrong results that depended on the > number > of processors used, since different values where used on different > processors. Good catch! Does this mean that the testsuite results were wrong all along, and now have to be regenerated? Before this fix, the test_ADM_2 test passed on 1 but not 2 processes, and after the fix it fails on both. What other codes would have been affected? For example, BSSN_MoL? Again I repeat my call for correctness tests in addition to regression tests... -- Ian Hinder ian.hinder(a)aei.mpg.de

3 6

Meeting minutes
by Roland Haas 04 Nov '10

04 Nov '10

Meeting minutes: Present were: Ian, Tanja, Roland, Frank, Christian, Peter, Gabrielle, Eloisa, Bruno, Josh * GRHydro: ** a development branch to add finite-temperature evolution was created in order to keep trunk stable for the release ** temp_and_ent_evolution_method will be renamed to temperature_evolution_method * Testsuites: ** we suspect that failures of MacLachlan testsuites might be related to OpenMP settings and numerical accuracy ** for now we will remove the Hamiltonian constraint from the testsuite ** in the future we want per variable tolerances ** Peter and Eloisa will look into the failing AHFinderDirect testsuites ** Peter will look into the failing ADM testsuite ** Roland will look into why some GRHydro testsuites fail *upcoming ET release: ** name: Chandrasekhar ** Ian will create git tags for the release (Kranc, Carpet, MacLachlan?) ** Frank will create svn tags for the release ** will have to look into build issues with libjpeg (might already be resolved by now) *future ET release: ** simfactory should be able to run the testsuites ** run testsuites using OpenMP ** per variable tolerances ** use EOS_Omni in GRHydro, remove one+ EOS interface ** create a tarball with the complete checkout for easier download by new users 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 5

GetComponents Patch
by Eric Seidel 03 Nov '10

03 Nov '10

Hi all, I have a patch for GetComponents that I would like to apply to the svn trunk. It address the following trac tickets: #75 Checkout/update timestamp #61 make COMPONENTLIST_TARGET 'stable' #76 GetComponents should not create links if repository cannot be checked out Ian mentioned that he thought the logs should be placed inside the checked out source tree, while GetComponents currently places them in $HOME/.crl/crl.log. I personally like the central location for logs, but I would be open to changing the location of the log files if others agree with Ian. Any thoughts? Eric

3 6

making kranc scripts available with (and consistent with) EinsteinToolkit
by Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] 03 Nov '10

03 Nov '10

We've had a bit of trouble working with the official ET-2010-06 release; specifically in trying to use Kranc to generate higher-order McLachlan code. Just grabbing the current release of kranc from github (git://github.com/ianhinder/Kranc.git) gives us an up-to-date version that doesn't work with the ET release code (for instance, it refers to GenericFD functions that don't exist in the ET release). Is there an "official" release of Kranc that goes with ET-2010-06? If so, can it be added to the einsteintoolkit.th? Thanks, Bernard

3 3

checkout timing of ET from GeorgiaTech
by Roland Haas 02 Nov '10

02 Nov '10

Hello all, checking out einsteintoolkit.th for the testsuites took me 17min the first time I tried yesterday, 11min the second time I tried and 8min just now. Updating via GetComponents was 7min yesterday and 2min today (when there was nothing to actually update). So it seems that maybe adding more memory to the server helped. 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 1

[trac-noreply@einsteintoolkit.org: [Einstein Toolkit] #69: Formaline might stop build because of errors reported by tar]
by Frank Loeffler 01 Nov '10

01 Nov '10

Hi, I forward the following trac message to the users mailing list to start a discussion on this issue, but to have the issue recorded in trac at the same time. Frank ----- Forwarded message from Einstein Toolkit <trac-noreply(a)einsteintoolkit.org> ----- #69: Formaline might stop build because of errors reported by tar --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2010_11 Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- Beginning with version 1.16 of gnu tar: <quote> After creating an archive, tar exits with code 1 if some files were changed while being read. Previous versions exited with code 2 (fatal error), and only if some files were truncated while being archived. </quote> Even reading a file (as is done when compiling it in parallel) will change it in tar's view, because this changes the atime of the file. There does not seem to be an option which turns this new behavior off. Instead it is recommended to check the exit code of tar which is 0: if everything went ok 1: if files changed while being read/written 2: if some other error occurs. This means that Formaline should treat an exit code of 1 in tar as 'ok', while currently it aborts the build. However, this is safely true only for gnu tar. For example the version of tar on the 'pelican' system states: <quote> 0 Successful completion. >0 An error occurred. </quote> This is too vague to decide if ignoring an exit code of 1 can also here be ignored. File changes are a kind of error - of a kind one might be able to ignore. The documentation of this old version of tar doesn't mention which values are actually used for which errors though. Somewhere else I found [http://aplawrence.com/Bofcusm/2073.html this]: <quote> 0 - success 1 - bad directory tree, failed to extract a requested file, input file same as output file, failed to open input file, could not create link, link table malloc failure 2 - internationalization error that should never occur, checksum error 5 - checksum error 9 (EBADF) - error reading /etc/default/tar, misplaced end of volume </quote> So, it is probably not safe to assume that an exit value of 1 always means 'success' for any version of tar, in the case of Formaline. How should we proceed with Formaline? The current state is not desirable. As far as I can see we have two options: 1) Assume that an exit value of 1 to be a 'success'. I do have a patch for this. 2) Test for gnu tar and only then assume 1) Opinions? ----- End forwarded message -----

2 5

ET svn server
by Frank Loeffler 01 Nov '10

01 Nov '10

Hi, The subversion server of the ET (svn.einsteintoolkit.org and svn.cactuscode.org) will be down today for about 5-10 minutes to upgrade it's memory from 1 to 2GB. This will (hopefully) help with it's speed, especially under heavy load. Frank

1 0

Floating Point consistency
by Ian Hinder 01 Nov '10

01 Nov '10

This is the Intel document about floating point consistency that I talked about in the ET call today. http://software.intel.com/en-us/articles/consistency-of-floating-point-resu… > Consistency of Floating-Point Results using the Intel® Compiler > or > Why doesn’t my application always give the same answer? > > > Dr. Martyn J. Corden > David Kreitzer > > Software Solutions Group > Intel Corporation -- Ian Hinder ian.hinder(a)aei.mpg.de

1 0

Reminder weekly call, Monday Nov 1st
by Frank Loeffler 01 Nov '10

01 Nov '10

Hi, The next weekly Einstein Toolkit telecon will be today: Monday, Nov 1st, 10am central US time. The main topic will be the preparation of the new ET release. It's main blocker is the current testsuite status: - You can find information about how to run the testsuites in a more or less automatic way on the web page [2], where you can also find the current status [3]. - I can see four main points which need to be addressed: - IDScalarWaveElliptic/test_waveell and WaveBinarySource/test_binary_1 seem to fail on every platform. - Some GRHydro testsuites seem to fail with a gcc compiler, pointing to ppm. - A lot of testsuites fail on multiple processors, especially from AHFinderDirect. - We don't yet have current results from a nice collection of machines. Of course we will also discuss everything which came up since last time if it's not releated to the release. As usual, find the instructions for the call on the ET web pages [1]. Frank Loeffler [1] http://einsteintoolkit.org/info/support/ [2] http://einsteintoolkit.org/release-info/ [3] http://einsteintoolkit.org/release-info/parse_testsuite_results.php

1 1

[cott@tapir.caltech.edu: [Commits] [svn:einsteintoolkit] GRHydro/branches/hot_and_MHD_temp_dev/ (Rev. 165)]
by Christian D. Ott 31 Oct '10

31 Oct '10

Hi All, after talking with Frank, I have just created a temporary branch of GRHydro for finite-T and MHD development while trunk is being readied for release. Please do any development work in branch hot_and_MHD_temp_dev. We'll merge this branch with trunk once the release has happened. Best, - Christian ----- Forwarded message from cott(a)tapir.caltech.edu ----- To: commits(a)einsteintoolkit.org From: cott(a)tapir.caltech.edu Date: Sun, 31 Oct 2010 16:04:51 GMT Subject: [Commits] [svn:einsteintoolkit] GRHydro/branches/hot_and_MHD_temp_dev/ (Rev. 165) User: cott Date: 2010/10/31 11:04 AM Added: /branches/hot_and_MHD_temp_dev/ Log: * create a temporary branch "hot_and_MHD_temp_dev" for development while trunk is being readied for release _______________________________________________ Commits mailing list Commits(a)einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/commits ----- End forwarded message -----

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users