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#.
We didn't have time last week to finish all of the discussions that we started, so we will continue to discuss our plans of how and when to retire thorns.
I also suggest to remove all testsuites using Exact that have counter-parts from EinsteinExact.
In addition, any other question or comment is of course welcome.
Current status of the development version: all tests except those in ADM (deprecated) and one Carpet testsuite pass.
Frank
On Fri, Dec 06, 2013 at 09:33:39PM -0600, Frank Loeffler wrote:
Current status of the development version: all tests except those in ADM (deprecated) and one Carpet testsuite pass.
ADM is now retired, which leaves two Carpet testsuites failing: CarpetInterp/test/waveinterp-?p.par.
From what I can see this is not (necessarily) a failure of CarpetInterp, but of Carpet itself. This testsuite uses the three-level initialization, coupled to a few refinement levels. This scheme seems to have problems in that case. We have other testsuites using it, but not with mesh refinement. Using only unigrid with the failing testsuite seems to work (doesn't produce nans and non-sensical time values like when using mesh refinement).
Without a deep analysis it looks like that either the three-level initialization in Carpet is broken when using mesh refinement, or there is some error in the parameter file that both I and Carpet didn't catch.
Before spending time by looking into a possible fix in Carpet: is anyone actually using or interested in this feature? If not, we might as well use the time elsewhere and disable/remove it.
Frank
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all,
Before spending time by looking into a possible fix in Carpet: is anyone actually using or interested in this feature? If not, we might as well use the time elsewhere and disable/remove it.
I think we need to understand what causes the failure, even if we decide that we do not want to/can make the test pass. 3 timelevel initialization (or Carpet's methods to populate past timelevels using the evolution loop) would seem required for correct convergence in time.
We claim that 3-timelevel initialization is possible, so if we see that it does not work, we should understand why and either fix it or abort a run that tries to use it. Silently producing incorrect results seem to me to be very dangerous.
Also until we understand that actual mechanism behind the failure, this might affect other initialization methods as well. Our tests might just not catch it.
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.
On 13 Dec 2013, at 21:47, Frank Loeffler knarf@cct.lsu.edu wrote:
On Fri, Dec 06, 2013 at 09:33:39PM -0600, Frank Loeffler wrote:
Current status of the development version: all tests except those in ADM (deprecated) and one Carpet testsuite pass.
ADM is now retired, which leaves two Carpet testsuites failing: CarpetInterp/test/waveinterp-?p.par.
The ticket for this failure is https://trac.einsteintoolkit.org/ticket/1497.
From what I can see this is not (necessarily) a failure of CarpetInterp, but of Carpet itself. This testsuite uses the three-level initialization, coupled to a few refinement levels. This scheme seems to have problems in that case. We have other testsuites using it, but not with mesh refinement. Using only unigrid with the failing testsuite seems to work (doesn't produce nans and non-sensical time values like when using mesh refinement).
Without a deep analysis it looks like that either the three-level initialization in Carpet is broken when using mesh refinement, or there is some error in the parameter file that both I and Carpet didn't catch.
Before spending time by looking into a possible fix in Carpet: is anyone actually using or interested in this feature? If not, we might as well use the time elsewhere and disable/remove it.
I would like this to work.
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Frank Loeffler -
Ian Hinder -
Roland Haas