Re: [petsc-dev] PetscSF vs VecScatter
Blaise, VecScatter will always be there as a way to arrange moving vector entries around between vectors. Someday (I bet Jed thought it would be years ago) PetscSF might be so good that VecScatter would be completely implemented on top of PetscSF and the old VecScatter implementations removed but that is only behind the scenes and not visible to users anyway. Does that sound reasonable or for some reason do you think the VecScatter API should be dropped and we force people who need to do vector scatters to do them by calling the PetscSF themselves? Barry > On May 21, 2015, at 3:16 PM, Blaise A Bourdin wrote: > > Hi, > > What is PETSc’s vision for VecScatter and PetscSF? > > It seems that the only thing that prevents PetscSF from completely replacing > VecScatter right now is that it does not support operations (ADD_VALUES, > INSERT_VALUES). Is this an inherent restriction to SF that will force it to > coexists with VecScatter, or is there a plan to add support for operations > and gradually replace VecScatter with PetscSF? > > Regards, > Blaise > > > -- > Department of Mathematics and Center for Computation & Technology > Louisiana State University, Baton Rouge, LA 70803, USA > Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 > http://www.math.lsu.edu/~bourdin > > > > > > >
[petsc-dev] PetscSF vs VecScatter
Hi, What is PETSc’s vision for VecScatter and PetscSF? It seems that the only thing that prevents PetscSF from completely replacing VecScatter right now is that it does not support operations (ADD_VALUES, INSERT_VALUES). Is this an inherent restriction to SF that will force it to coexists with VecScatter, or is there a plan to add support for operations and gradually replace VecScatter with PetscSF? Regards, Blaise -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin
Re: [petsc-dev] PetscSF vs. VecScatter
Blaise A Bourdin writes: > Hi, > > I am looking at adding full support for exodus to DMPlex (input and output). > Until I can understand better the nemesis format (a parallel extension of > exodusII), my goal is to be able to scatter data back to cpu 0, re-use the > pre-distribution ordering and use the sequential exo library. > > I can figure out how to do that using VecScatter but I am intrigued by > PetscSF. > Is there any documentation available, beside > src/vec/is/sf/examples/tutorials/ex1.c? > In particular a short description of the basic concepts would be helpful. I think this document is still a fine intro. http://59A2.org/files/StarForest.pdf The SF code is much cleaner than VecScatter and it'll get support for new MPI features. I haven't run a systematic performance comparison, but if SF can match VecScatter on all machines, we'll be able to start retiring the (hairy) VecScatter implementation code and make it run over SF. DMPlex uses SF in a bunch of places, if you'd like more complicated usage examples. pgpuVFvs0M4tc.pgp Description: PGP signature
[petsc-dev] PetscSF vs. VecScatter
Hi, I am looking at adding full support for exodus to DMPlex (input and output). Until I can understand better the nemesis format (a parallel extension of exodusII), my goal is to be able to scatter data back to cpu 0, re-use the pre-distribution ordering and use the sequential exo library. I can figure out how to do that using VecScatter but I am intrigued by PetscSF. Is there any documentation available, beside src/vec/is/sf/examples/tutorials/ex1.c? In particular a short description of the basic concepts would be helpful. Blaise -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin
