On Wed, 1 Sep 2010, Roy Stogner wrote:
> On Wed, 1 Sep 2010, Derek Gaston wrote:
>
>> On Sep 1, 2010, at 4:22 PM, Roy Stogner wrote:
>>
>>> This all sounds good except for the map - what would
>>> paralleltype_map["vector_name"] get you that
>>> get_vector("vector_name").type() doesn't?
>>
>> You're thinking too far down the path. When you call add_vector()
>> the vector doesn't (normally) get created or inited right then.
>> That initialization is when the ParallelType gets set. You have to
>> store a map of vectors->ParallelType _between_ the calls to
>> add_vector() and init_data()! I don't see any other way....
>
> Initialize the vector e.g. as GHOSTED with size 0 and an empty ghost
> index set?
Or for that matter we allow write access to NumericVector::type()...
although I'm not sure what we were thinking with that; it's not a
necessary solution in the case of an uninitialized vector and it would
be outright broken in other cases.
Ah - this was a hack you added! ;-) From before we fixed the
PetscVector(Vec) constructor to properly infer the type automatically.
We could make use of it now... although initializing a 0-size vector
and getting rid of that accessor feels "cleaner" somehow.
---
Roy
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
