[petsc-dev] VTK viewer design question

[Patrick Sanan]

2018-06-29 17:15 GMT+02:00 Jed Brown <jed at jedbrown.org>:

> Stefano Zampini <stefano.zampini at gmail.com> writes:
>
> > Vec and DM classes should not be visible from Sys. This is why they are
> > PetscObject.
> > If they were visible, builds with --with-single-library=0 will be broken.
> >
> > 2018-06-29 17:06 GMT+03:00 Patrick Sanan <patrick.sanan at gmail.com>:
> >
> >> I'm looking at the VTK viewer implementation  and I notice that
> >> PetscViewerVTKAddField() [1]
> >> accepts a parameter which, despite being called "dm", is of type
> >> PetscObject.
>
> I would not object to moving vtkv.c into src/dm -- it isn't actually
> usable without DM.
>

Yeah, it seems like moving this logic somehow into the DM package (either
by moving the entire thing, or by introducing another callback?) is the
natural thing to do.

>
> >> I think that this is used, amongst other things, to ensure that vectors
> >> being queued up to be written all come from the same DM.
> >>
> >> I'd like to relax this to only require that the vectors all come from
> >> *compatible* DMDAs, but this would require the DM API in vtkv.c.
>
> Why?  The function is developer level and there is VecGetDM() to give
> the correct DM.  I would rather that PetscViewerVTKAddField_VTK change
> this logic to merely check for compatibility:
>
>   if (vtk->dm) {
>     if (dm != vtk->dm) SETERRQ(PetscObjectComm((
> PetscObject)viewer),PETSC_ERR_ARG_INCOMP,"Cannot write a field from more
> than one grid to the same VTK file");
>
This is what I actually do in my proof-of-concept hack. I hackily include
petscdm.h in vtkv.c, cast the arguments back to (DM), and use
DMGetCompatibility() instead of the check for identical DMs.

Later, I do use VecGetDM() to pull out the required dof/node, but this
happens in a callback defined in grvtk.c, which is in the DM package, so no
problem.


> >> My questions: is this argument of type PetscObject for any reason other
> >> than not wanting to bother including petscdm.h ? Might this be something
> >> other than a DM in some case (and in which case, why is the argument
> called
> >> "dm")? Am I missing a reason that I'll get into trouble eventually if I
> >> change this?
> >>
> >> (Similar question for the "vec" argument).
> >>
> >> [1] http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/
> >> Viewer/PetscViewerVTKAddField.html
> >>
> >
> >
> >
> > --
> > Stefano
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180629/992448e1/attachment.html>