On Wed, 14 Jan 2009, Tim Kroeger wrote:

> Now, the first problem I encounter -- but actually it's not really a problem 
> -- is that PETSc supplies the possibility to automatically communicate any 
> changes of vector components to the other processors that may have those 
> indices as ghost indices.  While, in a long term view, using that 
> functionality would help to get rid of the duplicated solution 
> representation, I think that I should for now *not* use that functionality 
> since the current construction of current_local_solution does not expect 
> that.

Interesting possibility, but even in the long run I don't think we'd
want to use it unless it's quite efficient.  I can't see how they'd
accomplish that without requiring every set() to perform tests, every
ghost dof set() to do non-blocking message sends, and every get() to
test for a message receipt.  Synchronizing data only in large batches
when we know it's necessary isn't quite as intuitive but is probably
faster.

Plus there's the Trilinos question - if we assume NumericVectors have
such functionality, are we going to be able to get it easily from
every implementation without adding it ourselves?
---
Roy

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to