On 16/03/15 18:43, Jørgen Kvalsvik wrote:
On 03/16/2015 06:34 PM, Bård Skaflestad wrote:
On 16/03/15 18:28, Jørgen Kvalsvik wrote:
On 03/16/2015 05:07 PM, Bård Skaflestad wrote:
We currently implement the second approach. The matrix sparsity
(connection) structure does not change between calls to solve(),
although the numerical values of the coefficients certainly change.
Isn't that what the second version is all about? Meaning no sparsity
structure is re-formed, considering it's determined during
initSystemStructure and never changed.
Yes it is. We implement the second version. No change to the formed
matrix sparsity/connection structure, but changes to the numerical
values of the coefficient matrix and right hand sides.
Right, but isn't this also, I suppose implicitly, reforming the
unchanged sparsity structure?
"It depends".
Specifically, it depends specifically on what you mean by the term
"sparsity structure". If you mean the pattern of non-zeros of the
mathematical object represented by a particular coefficient matrix, then
yes assembling new numerical values does (potentially) changes the
sparsity structure. However, in the context of a packaged software
implementation, the sparsity structure is the contents of the "ia" and
"ja" arrays of struct CSRMatrix--or their internal Dune::BCRSMatrix<>
equivalents. Those are formed once, during initSystemStructure(), and
not changed during numerical assembly.
In essence, the structural analysis that creates the sparsity structure
is run once for each call to initSystemStructure() and subsequently used
only in a read-only capacity. Note that the BCRSMatrix<> produces an
error if an unknown matrix element is referenced in
S_[i][j]
after its 'endindices()' method has been called (i.e., once its
build-stage ('ready') is 'built').
Sincerely,
--
Bård Skaflestad <bard.skafles...@sintef.no>
SINTEF ICT, Applied Mathematics
_______________________________________________
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm
