Dear Roy,
On Wed, 3 Sep 2008, Roy Stogner wrote:
As far as I understand, currently the NumericVector interface class (with
its implementations such as PetscVector) is used as a parallel as well as a
serial vector.
Yes.
I notice that there is a method localize() that seems to transform a
serial into a parallel vector,
The reverse - localize() takes a parallel vector, and with no
send_list it gives you a global vector, or with a send_list it gives
you a global vector which only has valid coefficients on the listed
indices.
Ah, I understand. Actually, this explains why I never understood any
code that dealt with these things: because I had the wrong intuition
about what localize() does. I think, a better name for that method
would be "serialize()", but of course you can't change the name now.
What about a better documentation of this? I have attached a patch
for this.
but I can't find a corresponding "serialize()" method.
There is no reverse method to produce a parallel vector from a global
one;
I see, you are also calling serial vectors "global vectors" now.
This way, the method localize() creates a global vector, which does
not seem really intuitive to me.
I think the only place that's done in the library is in
System::reinit, so perhaps nobody ever bothered to factor it out.
Okay, I understand.
Perhaps I have not yet understood the concept correctly (which seems
not to be a good qualification to perform some modifications to that
class).
Not if you're going to be modifying things unassisted, definitely.
But I think part of the problem with the class is the API's learning
curve, and it's probably easier for a newer user who isn't already
familiar with the quirks to see where that could be improved.
That might be correct. So if the only task for me is to discuss
things with you, then I'm in.
Concerning the compatibility of a "SparseVector" class with the other
vector formats: Wouldn't it be easiest to let "SparseVector" default to a
serial NumericVector for all vector formats other than Petsc at first? (I
would assume that most users are using PETSc.)
That makes a lot of sense. For that matter I should probably stop
referring to it as "SparseVector"; we could just use the existing
serial NumericVector API, with at most an additional send_list option
in the constructor.
Does the vector have to decide on its constuction whether it is a
parellel, serial or sparse vector? If yes, you are right. If not,
just let the localize() method that takes a send_list use PETSc's
methods that you like to use.
By the way, if I add additional vectors to a system using
add_vector(), I assume they are stored parallel as well, right?
Thanks. This is interesting. My thoughts:
These numbers include ~500 seconds of project_vector time out of ~3500
seconds total. Not good, but not the 50% penalty I thought we were
seeing before.
Strange enough, because still the program gives the impression of
spending much more than 50% of the time in EquationSystems::reinit().
(I perform a lot of output to a logfile and watch that file with "tail
-f". Then I have a look at it from time to time, and in most cases
the state of the logfile indicates that the code is currently inside
EuqationSystems::reinit().) The question hence is: What else does
EquationSystems::reinit() do, other than System::project_vector()?
I notice that DofMap::reinit() takes a large amount of time; does that
mathod scale well?
Perhaps, a lot of time is just used by waiting of one processor for
another one to finish some task?
There's some other surprising expenses here. Parallel::max() taking
.6 seconds per call, 400 seconds total!? That seems pretty messed up
even for a slow interconnect.
In particular since Parallel::min() takes much less time per call.
Again, perhaps it often happens that one processor needs more time to
finish some other things and the others have to wait.
But back in project_vector: The localizations are taking ~110 seconds
total, but ~150 seconds are spent in projection computations that
should be scaling perfectly with Nproc. ~240 seconds are spent in
enforce_constraints_exactly, but it looks like there's some
inefficient localization there that I'd forgotten about; I'll fix that
too.
If you weren't so many kilometers away, I would invite you to join me
watching my logfile to see that the code appears to be inside
EquationSystems::reinit() nearly all the time.
Best Regards,
Tim
--
Dr. Tim Kroeger Phone +49-421-218-7710
[EMAIL PROTECTED], [EMAIL PROTECTED] Fax +49-421-218-4236
MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany
Amtsgericht Bremen HRB 16222
Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen
Index: include/numerics/numeric_vector.h
===================================================================
--- include/numerics/numeric_vector.h (Revision 3006)
+++ include/numerics/numeric_vector.h (Arbeitskopie)
@@ -354,8 +354,8 @@
virtual T dot(const NumericVector<T>&) const = 0;
/**
- * Creates a copy of the global vector in the
- * local vector \p v_local.
+ * Creates a copy of the global (i.e. parallel) vector in the
+ * local (i.e. serial) vector \p v_local.
*/
virtual void localize (std::vector<T>& v_local) const = 0;
@@ -366,7 +366,7 @@
virtual void localize (NumericVector<T>& v_local) const = 0;
/**
- * Creates a local vector \p v_local containing
+ * Creates a local (i.e. serial) vector \p v_local containing
* only information relevant to this processor, as
* defined by the \p send_list.
*/
@@ -374,7 +374,7 @@
const std::vector<unsigned int>& send_list) const = 0;
/**
- * Updates a local vector with selected values from neighboring
+ * Updates a local (i.e. serial) vector with selected values from neighboring
* processors, as defined by \p send_list.
*/
virtual void localize (const unsigned int first_local_idx,
@@ -382,7 +382,7 @@
const std::vector<unsigned int>& send_list) = 0;
/**
- * Creates a local copy of the global vector in
+ * Creates a local (i.e. serial) copy of the global (i.e. parallel) vector in
* \p v_local only on processor \p proc_id. By
* default the data is sent to processor 0. This method
* is useful for outputting data from one processor.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
