On 03/16/2015 04:43 PM, Bård Skaflestad wrote: > On 16/03/15 16:11, Jørgen Kvalsvik wrote: > in the periodic case, it uses plain assignment S_[i][j] = x, >> whereas in all the other cases it uses +=. > > Do you mean *Dirichlet* case rather than periodic in the above statement? > > I ported it to use += in all >> cases, and it still gives the same result. Yes, pardon me.
> > Yes it does because Dirichlet and Periodic are only encountered on > boundaries meaning update (+=) has the same effect as assignment (=). Another great thing I'll add to the comments. It is unfortunately unclear (although you can reasonably guess, which I did) that they reduce to be equal. > The reason is that each boundary connection is encountered exactly once > during system assembly and the matrix is explicitly initialised to all > zero elements at the beginning of assembleDynamic(). > > That said, I did write assignment on purpose because Dirichlet > conditions are essential boundary conditions and those statements > implement a variant of the technique sometimes referred to as explicit > elimination and the assignment expresses explicit value overriding a bit > more clearly than update. Which, as implied by the previous paragraph, is something you can deduce from the assignment, but also -can- be interpreted to be either a bug or a different last-touch semantic. > > As for the overall construction approach, it basically boils down to > which is more expensive: > > * Having two copies of the matrix in memory and re-forming > the (unchanging) sparsity structure on each call to solve() > > * Forming the sparsity structure once and doing per-coefficient > updates > > The latter has an O(log (number of non-zeros per row)) time complexity > for each coefficient and the former consumes more memory. On the other > hand, if done correctly, the former approach has an essentially optimal > overall time complexity of > > O(total number of non-zero elements) > > so that's an attractive property. As far as I can tell it's the former that's been implemented now, as we keep around the sparsity pattern and just zero it between calls to solve. I doubt this will change, although I might actually attempt to modify ownership slightly. I shan't promise too much though, as I might stumble onto more details and limitations and will only happen during longer measurement runs of other code.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
