[petsc-dev] VTK viewer design question

Smith, Barry F. bsmith at mcs.anl.gov
Fri Jun 29 11:20:35 CDT 2018



> On Jun 29, 2018, at 10:15 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> 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, move it. It is based on DM and Vec 

   But wait. If it is moved to DM and takes a vec argument, which will know about the DM, should it have a DM argument or should it be:

PetscViewerVTKAddVec(PetscViewer viewer,Vec vec,PetscErrorCode (*PetscViewerVTKWriteFunction)(Vec,PetscViewer),PetscViewerVTKFieldType fieldtype)

> 
>>> 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");
> 
>>> 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



More information about the petsc-dev mailing list