Hi Peter, I think this misconstrues what constitutes “non-intrusive”. What you are actually saying is that you don’t want to use actual published API features of Firedrake like plotting and computing the L^2 norm, but you instead want to exploit unpublished implementation details in order to use a different tool for these things. Just using Firedrake to accomplish those goals (which would literally be a couple of lines of code) would in no way detract from the non-intrusiveness of your reduced order model, because you still wouldn’t be using any information about how the PDE was solved. In fact, it’s a bit worse than that. If you actually want to be non-intrusive then your code cannot possibly plot or compute an L^2, error, because both of those things require knowing what the basis functions used in the finite element method were. Those things can only be the purview of the PDE solver. What you are proposing to do isn’t actually non-intrusive, it’s just conveying basis function information implicitly through a numbering convention rather than explicitly by calling the Firedrake API. Regards, David From: <firedrake-bounces@imperial.ac.uk> on behalf of "Sentz, Peter" <sentz2@illinois.edu> Date: Wednesday, 2 October 2019 at 19:54 To: Lawrence Mitchell <wence@gmx.li> Cc: firedrake <firedrake@imperial.ac.uk> Subject: Re: [firedrake] Gathering D.O.F.s onto one process Hi Lawrence, I am working on Non-Intrusive Reduced Order modeling techniques for PDEs. To have such a method be non-instrusive, the PDE solver should only be used to compute training data and test data (the d.o.f.s of the PDE), but developing the reduced order model should be independent of how the data was computed. In order to make sense of the data (plotting and L^2 error computation) I need the mesh ordering that the D.o.f.'s actually correspond to. - Peter ________________________________ From: Lawrence Mitchell <wence@gmx.li> Sent: Tuesday, October 1, 2019 5:35 AM To: Matt Knepley <knepley@gmail.com> Cc: Sentz, Peter <sentz2@illinois.edu>; Firedrake Project <firedrake@imperial.ac.uk> Subject: Re: [firedrake] Gathering D.O.F.s onto one process
On 1 Oct 2019, at 10:48, Matthew Knepley <knepley@gmail.com> wrote:
On Mon, Sep 30, 2019 at 10:46 PM Sentz, Peter <sentz2@illinois.edu> wrote: So is there a way to return how the global degrees of freedom are distributed across processors?
I would recommend changing your workflow so that you do not need this, since it complicates everything.
However, if you still really want to do this, you can
1) Tell the DM to constructs mappings back to the original ordering https://www.mcs.anl.gov/petsc/petsc-master/docs/manualpages/DM/DMSetUseNatur...
2) After distribution, map a vector back to that ordering https://www.mcs.anl.gov/petsc/petsc-master/docs/manualpages/DMPLEX/DMPlexGlo...
3) Output that vector using view()
FWIW, I would be a little bit careful checking that this all DTRT. We don't set a Section on the DMPlex before distribution, so (as I understand the code) the global-to-natural SF won't be built. Aside: why does the interface in PETSc not build an SF for the permutation of the topology to natural ordering, and then you would do: DMGlobalToNatural(dm, Vec global, Section layout, Vec natural); Peter, perhaps you can explain why you need a consistent ordering and we can figure out a way to achieve the same thing without doing this dance. As Matt says, it does make lots of things more complicated. Thanks, Lawrence