From 489a12e8f45e75bbc338fda4e9fbf1b3b1f5a4bc Mon Sep 17 00:00:00 2001
From: linhart
- As mentioned above, we usually add a new test these days every
+ As mentioned above, we add a new test every
time we add new functionality to the library or fix a bug. If you
- want to contribute code to the library, you should consider this
- as well. Here's how: you need a testcase, an entry in the
+ want to contribute code to the library, you should do this
+ as well. Here's how: you need a testcase,
+ a subdirectory with the same name as the test, an entry in the
Makefile, and an expected output.
- .
You open an output file in a directory with the same
+ name as your test, and then write
all output you generate to it,
- through the
- There are a number of directories where you can put tests
- in. Extensive tests of individual classes or groups of classes
+ There are a number of directories where you can put a new test.
+ Extensive tests of individual classes or groups of classes
have traditionally been into the
- More recently, we have started to create more atomic tests, that
+ We have started to create more atomic tests which
are usually very small and test only a single aspect of the
library, often only a single function. These tests go into the
You have to create a subdirectory
+ with the same name as your test to hold the output from the test.
+
+ One convenient way to create this subdirectory with the correct
+ properties is to use svn copy.
+
@@ -405,8 +417,8 @@ int main ()
where tests reside, there is a separate Makefile that contains a
list of the tests to be run in a variable called
make hierarchical/OK
- If the output isn't equal, then you'll get to see something like
+ If the output isn't equal, then you'll see something like
this:
=====Checking====== hierarchical/output
@@ -317,12 +317,12 @@
- The basic idea is that you open an output file in a directory with the same
- name as your test (don't forget to create this directory), and then write
+
+ Adding new tests
The testcase
@@ -365,21 +365,23 @@ int main ()
return 0;
}
deallog
stream (which works just like any
+ through the deallog
stream. The deallog
+ stream works like any
other std::ostream
except that it does a few more
- things behind the scenes that are helpful in this context). In
- above case, we only (nonsensically) write a zero to the output
+ things behind the scenes that are helpful in this context. In
+ above case, we only write a zero to the output
file. Most tests actually write computed data to the output file
to make sure that whatever we compute is what we got when the
test was first written.
base/
,
lac/
, deal.II/
, fe/
,
hp/
, or multigrid/
directories, depending on
@@ -387,16 +389,26 @@ int main ()
bits/
directory and often have names that are
composed of the name of the class being tested and a two-digit
- number (for example, dof_tools_11
). There are also
+ number, e.g., dof_tools_11
. There are
directories for PETSc and Trilinos wrapper functionality.
A directory with the same name as the test
+
+
+svn copy existing_test_directory my_new_test
+
+
An entry in the Makefile
tests_x
. You should add your test to the bottom of
- this list, by adding the base name of your testfile (i.e. without
- the extension .cc
). Note that the entries can contain
+ this list, by adding the base name of your testfile, i.e., without
+ the extension .cc
. The entries can contain
wildcards: for example, in the tests/bits/
directory,
the tests_x
variable contains the entry
petsc_*
which at the time of this writing tests 120
@@ -418,7 +430,7 @@ int main ()
make my_new_test/output
- which should compile, link, and run your test. Running your test
+ This should compile, link, and run your test. Running your test
should generate the desired output file.
- So why generic
? The reason is that sometimes test results
+ Why generic
? The reason is that sometimes test results
differ slightly from platform to platform, for example because numerical
roundoff is different due to different floating point implementations on
different CPUs. What this means is that sometimes a single stored output is
@@ -469,7 +481,7 @@ int main ()
first file it found in this process. To make things a bit clearer, if you
are, for example, on a i686-pc-linux-gnu
box and use
gcc4.0
as your compiler, then the following files will be
- searched for (in this order):
+ sought (in this order):
testname/cmp/i686-pc-linux-gnu+gcc4.0 testname/cmp/i686-pc-linux-gnu+gcc3.4 @@ -489,7 +501,7 @@ testname/cmp/generic Most of the time, you will be able to generate output files only for your own platform and compiler, and that's alright: someone else will create the output files for other platforms - eventually. You therefore only have to copy your output file to + eventually. You only have to copy your output file totestname/cmp/generic
. diff --git a/deal.II/lac/include/lac/full_matrix.h b/deal.II/lac/include/lac/full_matrix.h index 89e89e07d0..330c925fc8 100644 --- a/deal.II/lac/include/lac/full_matrix.h +++ b/deal.II/lac/include/lac/full_matrix.h @@ -954,7 +954,8 @@ class FullMatrix : public Table<2,number> void cholesky (const FullMatrix&A); /** - * *this = $V W^T$ where $V,W$ + * *this(i,j) = $V(i) W(j)$ + * where $V,W$ * are vectors of the same length. */ template diff --git a/deal.II/lac/include/lac/full_matrix.templates.h b/deal.II/lac/include/lac/full_matrix.templates.h index 1c32461da3..dd19a5aa89 100644 --- a/deal.II/lac/include/lac/full_matrix.templates.h +++ b/deal.II/lac/include/lac/full_matrix.templates.h @@ -1321,13 +1321,13 @@ FullMatrix ::cholesky (const FullMatrix &A) for (unsigned int i=0; i< this->n_cols(); i++){ SLik2 = 0.0; for (unsigned int j = 0; j < i; j++){ - SLik2 += (*this)(i,j)*(*this)(i,j); SLikLjk = 0.0; for (unsigned int k =0; k = 0, ExcMatrixNotPositiveDefinite()); -- 2.39.5