[petsc-dev] de-global variablelizing PETSc

[Barry Smith]

   There are a variety of possibilities and I don’t think we’ve done enough playing with possibilities to come to any grand decision decisions yet.

   1) The PetscThread code that Shri and Jed have been working on focuses on a Vec object that is “controlled” by an MPI process which can then use multiple threads to perform operations inside the vector.  This is for vectors that are “largish” on a node.

    2) The model that Ed wanted, that I provided crude support for, has a Vec object that is “controlled” by an individual thread and uses that individual thread to perform operations inside it. This is for vectors that are “smallish” on a node.

   3) ???

   Here “controlled” by means created by and then method calls are made on it by either the MPI process or the individual thread.

    Our support for 1 is still immature and we’ve never even done 2 before (which is why there are all those damn globals lying around).

     What the entire soup should look like and how it should be coded is still open in my mind.

   Barry


On Nov 10, 2013, at 4:01 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Dmitry Karpeyev <karpeev at mcs.anl.gov> writes:
>> What would happen to VecCreate(PETSC_COMM_WORLD,&v)?
> 
> VecCreate(petsclib, PetscCommWorld(petsclib), &v);
> 
>> Would v now be a collection of threadwise Vecs?
> 
> Independent vecs in each thread that calls the function (this is in no
> way collective between threads, and you can "hand off" the lib and vec
> contexts between threads).
> 
>> How would they sync?
> 
> The point is that they would be separate, even with separate logging and
> debugging.  This may not be solving the right problem.