Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

warning
by Steven R. Brandt 14 Nov '13

14 Nov '13

My application issues the following warning when I attempt to run with FMR. WARNING[L1,P0] (Carpet): There are not enough time levels for the desired temporal prolongation order in the grid function group "FUNWAVE::MIXING_GROUP". With Carpet::prolongation_order_time=1, you need at least 2 time levels. I don't sync this group anywhere. Does anyone know why I need two time levels? Cheers, Steve

2 2

testsuite status
by Frank Loeffler 14 Nov '13

14 Nov '13

Hi, Here a quick update over the current testsuite status: Builds using gcc succeed in all tests - maybe in part because test data might actually have been produced using this. The problems we see usually come from the Intel compiler, but for different reasons. Using default (simfactory) options, we have a couple of failures on most machines using the Intel compiler. First, assuming an Intel compiler version > 11, all tests pass with fp-model set to precise. This is encouraging, as it means that the remaining failures there are caused by inaccuracies introduced by the compiler, which indicates one or multiple of three things (or both). Either the error-tolerance is set too low on the tests, the tests themselves have conceptional accuracy problems (e.g. the ones using Exact), or the simfactory compiler options are simply too inaccurate. We have adapted some of the tests falling into the first category already. We have replacements for most tests using Exact already (which pass) and might therefore drop the old and known-to-be-problematic Exact testsuites before the release (we know that the problem is in Exact itself, which isn't as exact as the name implies). We are unlikely at this point to suggest to change compiler options. Most people wouldn't be using the precise options for the Intel compiler in their productions runs, and this environment is the one we have to test. Another issue is the Intel compiler version 11. This seems to cause segfaults in some suites, especially hydro suites, and at the moment we suspect the usage of cray pointers to be the culprit. Higher compiler versions seems to be fine, but some machines don't have that option. This includes queenbee - the machine used for the Einstein Toolkit test accounts and the new users tutorial. We need to find a fix for this. IDAxiOffBrillBH and RotatingDBHIVP suites seem to have problems on Loewe (and one of them on stampede). Only someone with access to Loewe could have a look at what happens there. The only remaining problem I can see besides all these is the balsara4_1d test, and Roland is going to look into that. Given this, I suggest to properly fix the tests, one way or another, and postpone the release at least to next week - and depending on availability of the people involved (SC13 next week) maybe the week after that (but don't count on it). Frank

1 0

Machine tests
by Frank Loeffler 14 Nov '13

14 Nov '13

Hi We need people running tests on various machines. See below for a (probably not complete) list of machines that we don't have even halfway recent results online, but should. Pick and choose some by replying to this email. This includes not only actually running the tests, but potentially trying to fix problems if any arise - so simply running 'distribute' might not be all that is needed, and not everyone has a login everywhere. bluewaters hopper kraken stampede supermuc titan zwicky I do/did queenbee supermike tezpur spine Frank

4 8

Test failures
by Frank Löffler 14 Nov '13

14 Nov '13

Hi So far, Ian ran tests on datura and I ran the testsuites, on my workstation. The gcc build shows no failures at all, but the intel suite shows 9, but in part different than the one on datura. http://einsteintoolkit.org/release-info/parse_testsuite_results.php In the following I try to give a short summary of some of the failures: Exact/KS-tilted fails on my workstation. This has always been a fragile test. GRHydro_test_shock_* fail on datura. I don't have the raw files, but it seems from the overview page that all files show problems. This has to be looked into. It would be interesting to see if this is a datura-only problem of whether we see this elsewhere too. balsara4_1d fails on my workstation - likely a tolerance issue. Anyone? A lot of the other hydro tests fail on datura, suggesting that there is a real problem with hydro there. Some of the Multipole tests fail due to tolerance in the convergence order output. I would like to see someone who is expert in that thorn/testsuite to take a look. Some of the RotatingSymmetry180/90 testsuites fail on my workstation, due to tolerance, as suggested by the results. These are the Kerr testsuites, and at the same time the corresponding Kerr-EE suites succeed, suggesting a similar issue as with other Exact testsuites: insufficient accuracy of the initial data itself - or in other words a tolerance problem. So, in short: apart from a hydro problem on datura we see the 'usual' Exact-related problems, a failure in balsara4_1d and in the testsuites of Multipole. However, we need more results. Please test other machines as well! Frank

2 6

Meeting Minutes
by Roland Haas 12 Nov '13

12 Nov '13

Present: Erik, Frank, Roland, Philipp, Steve Release: * want to release this week * Name: Noether (http://en.wikipedia.org/wiki/Emmy_Noether) * fix outstanding tickets by Tuesday ** GRHydro failures: Roland ** Regenerate Kranc thorns: Roland ** failure of Dissipation on bethe: Roland simfactory: * simfactory's distribute script now runs short benchmarks, the benchmarks last about 2min Yours, Roland

1 1

Release Notes
by Frank Loeffler 12 Nov '13

12 Nov '13

Hi, I started to write up release notes. The current state can be found here: https://svn.einsteintoolkit.org/www/about/releases/ET_2013_11_announcement.… Please add/change/comment. All developers should have write permissions (this is a subversion repository, so you can just check things out and commit changes - no need to send me patches). Frank

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 10 Nov '13

10 Nov '13

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/ In short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. I expect us to talk primarily about the upcoming release, but any other topic is of course welcome, and will be discussed first. Frank Löffler

1 0

Testing Simfactory for release
by Erik Schnetter 07 Nov '13

07 Nov '13

I have updated the option lists in Simfactory for several machines. This is to ensure that these option lists and machine descriptions are current, so that these machines can be used easily. I have tested that the test suites can be run, but not whether they succeed. According to my tests, these option lists now allow syncing, building, submitting, and running on the following systems without problems: - Bethe, Blue Waters, Gordon, Hopper, Kraken, Lonestar, Mike, Nvidia, Orca, Philip, Queen Bee, Redshift, Stampede, Stampede-MIC, Titan, Trestles, Zwicky There are problems on the following systems: - Carver, Pandora, Surveyor (job submission) - Vesta (running test suite) I did not test the following systems: - Datura, GPC, Loewe, Supermuc As mentioned above, I did not check the results of running the test cases; I assume that some test cases are failing on some of these systems. I think we should address the problems on Pandora, Datura, and Vesta, and maybe Loewe. I volunteer for Vesta. I am using the "distribute" script that comes with Simfactory for this. To use it: - Check out the Einstein Toolkit - run e.g. ./sim/bin/distribute --no-benchmark queenbee - this will sync, and then remotely build, submit a simple test job, run the test cases, and then test checkpoint/recovery/presubmission - high-level output: tail -f log/queenbee.results - verbose output: tail -f log/queenbee.out Since this works remotely, this requires keeping a network connection from your machine to the machine being tested. I thus run this from a workstation, not from my laptop. If you run this on Queen Bee directly, you obviously don't need to keep a network connection since the tests will run locally. Other important options for "distribute": - --no-clean: don't rebuild from scratch - --no-recover: don't test checkpoint/recovery; this step will fail without a queueing system (e.g. on a workstation) -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.

3 2

Re: [Users] coverage tests
by Roland Haas 05 Nov '13

05 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Steve, > Just saw this email today. See utils/GcovAnalysis.pl, and comments > at the top of the file. Very nice. Thank you. 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. - -- 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJ5ZRsACgkQTiFSTN7SboUbVACgr0exLzk6pgnEC85NVNewjHQK aZgAoI2IL/1W6lgZHTB06G3WBwxW5Pu2 =cF7E -----END PGP SIGNATURE-----

1 0

Evolving grid arrays using MoL
by Ian Hinder 04 Nov '13

04 Nov '13

Hi, What is the current situation with evolving grid arrays with MoL? Over the past 7 years, this topic has come up repeatedly on the mailing lists, and some of the old information is probably out of date. Is there a way to do this without using any hacks, or are hacks still necessary? Is there an example somewhere of how to do this, or does someone have an example they would be willing to share? -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

7 17

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users