[petsc-dev] VTK viewer design question

[Jed Brown]

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.

>> 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