LAPACK Archives

[Lapack] LAPACK: dead link on the website

Mark,
Actually if the build finish without a segfaut, you're fine.
I would build again the Reference BLAS first and then ATLAS.

Here is a little script that may help you.
You should have only Numerical Errors (between 200 and 500) Those are torture 
tests and we know some are failing.

   cat *.out > testing_results.txt
   echo " ****************************************************** "
   echo " RESULTS"
   echo "     - numerical failure: "
grep -i "out of" testing_results.txt | grep drivers
grep -i "out of" testing_results.txt | grep -v drivers
grep -i "largest test error" testing_results.txt |  grep -v "D\-" | grep -v 
"E\-" | grep -v "+00" 
grep -i "Error in"  testing_results.txt
nb_illegal=`grep -c -i illegal testing_results.txt`
   echo "     - illegal error:     $nb_illegal "
info_error=`grep -i -c -h "error code" testing_results.txt`
   echo "     - info error:        $info_error "
nb_signal=`grep -i -h signal testing_results.txt | grep -c -v toto`
nb_exception=`grep -i -h exception testing_results.txt | grep -c -v "flags 
raised"`
severe_error=`expr $nb_signal + $nb_exception`
   echo "     - severe error       $severe_error"

Regards,
Julie


On Mar 22, 2011, at 9:16 AM, Mark Dixon wrote:

On Mon, 21 Mar 2011, julie langou wrote:

Thank you Mark for reporting the dead link. This has been corrected.

Thanks Julie.

It seems that you already went through : 
http://www.netlib.org/lapack/faq.html#_how_do_i_interpret_lapack_testing_failures
 and it seems it did not help. What are your output errors? maybe I can help 
you understand them
Sincerely,
Julie

Thanks for the offer - I must admit that I feel that I'm thrashing about a 
bit on this one.

I've been trying to install a BLAS/LAPACK stack, based on ATLAS 3.8.3 and 
LAPACK 3.3.0, on our main compute cluster running RHEL5 64-bit. Perhaps being 
a little too eager, I trying to build it against every variant of compiler on 
the system and in both 32-bit and 64-bit modes.

After reading the FAQ and some of the forum entries, I've hit upon the 
following method for analysing the test output files to see if a build is 
"good" or not:

 1) grep for 'failed to pass'
 2) grep for ' result ' to obtain the results of test failures
 3) Take (2) and remove minor errors - any result that is a small number
    (where small is defined here as a number not in scientific notation)
 4) Ignore anything from files [sdcz]gd.out

Is this a reasonable definition?

Based on this, I'm still working-through the advice in the FAQ (varying 
compiler flags and BLAS implementation).

Thanks,

Mark
-- 
-----------------------------------------------------------------
Mark Dixon                       Email    : m.c.dixon@Domain.Removed
HPC/Grid Systems Support         Tel (int): 35429
Information Systems Services     Tel (ext): +44(0)113 343 5429
University of Leeds, LS2 9JT, UK
-----------------------------------------------------------------


**********************************************
Julie Langou; Research Associate in Computer Science
Innovative Computing Laboratory;
University of Tennessee from Denver, Colorado ;-)
julie@Domain.Removed; http://www.cs.utk.edu/~julie/







-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://lists.eecs.utk.edu/mailman/private/lapack/attachments/20110322/f8e97d80/attachment.html
 

<Prev in Thread] Current Thread [Next in Thread>


For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or