[petsc-dev] Man pages usage of "Collective on XXX"
Hapla Vaclav
vaclav.hapla at erdw.ethz.ch
Thu Feb 7 08:20:12 CST 2019
On 7 Feb 2019, at 15:10, Patrick Sanan via petsc-dev <petsc-dev at mcs.anl.gov<mailto:petsc-dev at mcs.anl.gov>> wrote:
(Forgot to reply-all before)
I'd propose to update the guidelines in the dev manual to say that unless otherwise specified, collectivity is wrt the communicator associated with the PETSc object in the first argument slot.
Let me take e.g.
https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatTranspose.html
as an example.
So you mean that
Collective on Mat
could be replaced by just
Collective
which would implicitly mean
Collective [on Mat mat argument]
That's perhaps quite a good idea!
Note that it's an information also for users, so this interpretation note about probably shouldn't be mentioned _only_ in the dev manual.
Cheers,
Vaclav
Am Do., 7. Feb. 2019 um 10:35 Uhr schrieb Patrick Sanan <patrick.sanan at gmail.com<mailto:patrick.sanan at gmail.com>>:
Am Mi., 6. Feb. 2019 um 21:09 Uhr schrieb Matthew Knepley via petsc-dev <petsc-dev at mcs.anl.gov<mailto:petsc-dev at mcs.anl.gov>>:
On Wed, Feb 6, 2019 at 3:03 PM Dave May via petsc-dev <petsc-dev at mcs.anl.gov<mailto:petsc-dev at mcs.anl.gov>> wrote:
* I notice that most man pages will say
Collective on <type>
e.g.
https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMDA/DMDACreate.html
* Some others say
Collective on <implementation-name>
e.g.
https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMDA/DMDACreateNaturalVector.html
or
https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMCompositeAddDM.html
In the former, at least the word "DMDA" gets linked back to the implementation, whilst in the latter "DMComposite" does not.
Should "Collective on <implementation-name>" be avoided?
It is potentially somewhat unclear given that the name of the implementation does not appear anywhere in the arg list (type or variable name).
That said, "collective on <type>" could be similarly criticized if a method existed with two args of the same type.
* Many of the methods in this file
www.mcs.anl.gov/petsc/petsc-current/src/dm/impls/shell/dmshell.c.html<http://www.mcs.anl.gov/petsc/petsc-current/src/dm/impls/shell/dmshell.c.html>
simply say "Collective" (without a type or implementation name), or they say "Logically Collective on XXX"
I do realize that there is a pattern that the statement "collective on xxx" or "not collective" applies (implicitly) to the first argument of any PETSc function call (at least that I've come across) so possibly just indicating the method as "Collective" might suffice (assuming (i) there is a pattern and (ii) everyone knows about the pattern).
Q: Should I make a PR to unify these man pages (and any others I spot) to just say "Collective on <type>"?
This has always bugged me. It should say, I think, 'Collective on <arg name>", or "Logically collective on <arg name>".
I agree - ultimately I think we're just trying to say "this operation is [logically] collective wrt the MPI communicator associated with object XXX", so specifying this with respect to an argument makes the most sense. Right now the dev manual says "class XXX" which seems potentially ambiguous (for instance you could have two arguments for local/global Vecs living on different communicators).
In terms of reducing clutter and making things more maintainable, I would support explicitly adopting the convention that if no argument is specified (e.g. just "Collective"), then this refers to the first argument - I think this is very intuitive for class methods (e.g. DMFoo(DM dm,..,) is going to be collective or not wrt the communicator associated with "dm").
Thanks,
Matt
Thanks,
Dave
--
What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
-- Norbert Wiener
https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190207/83294169/attachment-0001.html>
More information about the petsc-dev
mailing list