#873: SphericalHarmonicRecon test is failing ---------------------+------------------------------------------------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2012_05 Component: Other | Version: Resolution: | Keywords: testsuites ---------------------+------------------------------------------------------
Comment (by hinder):
Does anyone have an idea for how to fix this? It is the last failing test on Datura. The standard output (http://damiana2.aei.mpg.de/~ianhin/testsuites/einsteintoolkit/einsteintoolki...) shows large numbers of the following warning:
{{{ WARNING[L1,P0] (AEILocalInterp): CCTK_InterpLocalUniform(): input datatype 111 not supported! (0-origin) input #in=0 }}}
There was a comment that this might be due to a configuration problem on the machine, but the configuration has not changed. The regression was introduced some time between the 5th and the 7th of May.
{{{ Mon May 7 20:32:21 2012 +0100 * flesh 474dc19...cef5ed9 (1): > Protect declarations with external "C" * simfactory aa415d3...9aca06f (2): > Build documentation by default > Synchronise doc directory Mon May 7 17:32:18 2012 +0100 * flesh ac43e07...474dc19 (1): > Enable "restrict" as keyword in C++ * manifest 7b3195d...14405cd (3): > add comment about opencl thorns > Add OpenCL thorn, but keep it commented out > Add CCZ4 formulation Mon May 7 16:32:09 2012 +0100 * simfactory ba7196d...aa415d3 (4): > Invalidate aliaspattern to avoid conflicts > Set scratchbasedir > Set scratchbasedir > Introduce scratchbasedir instead of scratchdir Mon May 7 07:33:17 2012 +0100 * arrangements/EinsteinBase/HydroBase bbfe4eb...6c6a71a (1): > Documentation: fix conversion factor for SI units. Add Gaussian one. Mon May 7 03:32:00 2012 +0100 * simfactory 09478d5...ba7196d (2): > Update > Examine more lines for status output Sun May 6 23:32:00 2012 +0100 * arrangements/AEIThorns/AEILocalInterp aec6b0b...72130d2 (1): > Parallelize AEILocalInterp with OpenMP Sun May 6 03:31:59 2012 +0100 * simfactory f63e8d9...09478d5 (1): > Add missing scratchdir Sat May 5 23:32:01 2012 +0100 * simfactory ebc22d9...f63e8d9 (1): > Correct, update, and simplify configuration Sat May 5 22:32:04 2012 +0100 * simfactory a30ad51...ebc22d9 (1): > Set FFTW3_DIR instead of FFTW_DIR Sat May 5 16:32:01 2012 +0100 * simfactory 8f46d8e...a30ad51 (3): > Add Kraken to "known good machines" > Don't delete scratch directory > Clarify description of "scratchdir" Sat May 5 15:32:19 2012 +0100 * arrangements/EinsteinInitialData/NoExcision 29c738b...6a6b78c (1): > Declare all loop variables private * arrangements/EinsteinInitialData/TwoPunctures 7e3d877...59b4352 (1): > Declare all loop variables private * arrangements/LSUThorns/SummationByParts 7a5e754...cc09b8e (1): > Declare all loop variables as OpenMP private Sat May 5 13:32:30 2012 +0100 * repos/carpet 74be6e5...d7663b5 (1): > CarpetLib: Disable OpenMP collapse statements * simfactory c2b986b...8f46d8e (4): > Update > Update web page > Update list of "known good" machines on which to test > Update Forge configuration Sat May 5 04:32:22 2012 +0100 * arrangements/EinsteinEvolve/GRHydro c40fdb9...ddee80c (1): > remove tests using BSSN_MoL for which ML_BSSN alternatives exist * arrangements/EinsteinInitialData/Exact de5c5df...0b51a27 (1): > use ML_BSSN instead of BSSN_MoL for testsuites Sat May 5 03:32:11 2012 +0100 * arrangements/CactusNumerical/Dissipation b152a29...2af5af1 (1): > use ML_BSSN instead of BSSN_MoL in testsuites Sat May 5 02:32:26 2012 +0100 * arrangements/CactusNumerical/Cartoon2D 31c0fc2...3370381 (1): > use ML_BSSN instead of BSSN_MoL in testsuites * arrangements/CactusNumerical/RotatingSymmetry90 59fb60e...d25162a (1): > use ML_BSSN instead BSSN_MoL in testsuites Sat May 5 01:33:29 2012 +0100 * arrangements/CactusNumerical/RotatingSymmetry180 8f3cdd4...23b7bcf (1): > use ML_BSSN instead of BSSN_MoL in testsuites * repos/carpet 0a20793...74be6e5 (2): > CarpetEvolutionMask: use ML_BSSN instead of BSSN_MoL in testsuites > CarpetEvolutionMask: use dd.buffer_widths instead of buffer_width parameter }}}
In addition to fixing whatever this problem is, I think that the calling thorn should check the result and abort if the interpolation cannot be performed. Currently the error logs are very large.