Re: [petsc-dev] questions on new include organization
On Wed, Feb 13, 2013 at 12:08 AM, Barry Smith <[email protected]> wrote:
On Feb 12, 2013, at 10:56 PM, Matthew Knepley <[email protected]> wrote:
On Tue, Feb 12, 2013 at 11:41 PM, Barry Smith <[email protected]> wrote:
1) Can we move the section data structures from vecimpl.h to isimpl.h? in preparation for its refactoring and why is PetscSectionCreate in section.c defined in src/vec/vec/impls/seq? Can vsection.c be split in two with the only the "Vec" related routines kept in the Vec directory
All the above makes sense if you agree with this designation as an IS. Can we go over this again to make sure it is correct?
a) PetscSection does a job very similar to PetscLayout, but Layout is not an IS
b) The internals of PetscSection look like two ISes, and a list of embedded PetscSections. This does not sound like an IS
Regardless of these two, PetscSection does not belong in the vector subdirectory and most definitely not in the impls/seq directory, so even if in the end it does not become exactly an IS it more belongs in the is directory then in the vec directory
That is convincing.
c) I believe the claim will be, "I can always think of the output as a list of integers", however that is a very broad category, which also includes graphs, meshes, etc. Internally this looks nothing like a list of numbers, and the current queries do not just return members of this list.
a graph and mesh most definitely cannot be thought of as a list of integers since they contain information about relationships BETWEEN items. Does PetscSection contain such additional information?
Yes. PetscSection represents groups of numbers, and you can see the grouping.
What queries "do not just return members of this list" in PETSc section? (That is queries we wish to retain anyways).
For example, you can ask "how many items are in group p?". This is crucial, and the whole point of the structure. I don't see how you can recover that information from just the list of dof numbers. Matt
Barry
Matt
2) matimpl.h really needs vecimpl.h?
#define __MATIMPL_H
#include <petscmat.h> #include <petsc-private/petscimpl.h> #include <petsc-private/vecimpl.h>
Doesn't seem to so I've removed the vecimpl.h and pushed
Seems there may be a few of these unneeded dependencies hanging around,
I'll try to hunt them down.
Barry
-- 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
-- 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
participants (1)
-
Matthew Knepley