<div dir="ltr">Vec and DM classes should not be visible from Sys. This is why they are PetscObject.<div>If they were visible, builds with --with-single-library=0 will be broken.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-06-29 17:06 GMT+03:00 Patrick Sanan <span dir="ltr"><<a href="mailto:patrick.sanan@gmail.com" target="_blank">patrick.sanan@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm looking at the VTK viewer implementation  and I notice that PetscViewerVTKAddField() [1]<div><div>accepts a parameter which, despite being called "dm", is of type PetscObject. </div><div><br></div><div>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. <div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div>(Similar question for the "vec" argument).</div></div></div><div><br></div><div>[1] <a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Viewer/PetscViewerVTKAddField.html" target="_blank">http://www.mcs.anl.gov/petsc/p<wbr>etsc-current/docs/manualpages/<wbr>Viewer/PetscViewerVTKAddField.<wbr>html</a></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Stefano</div>
</div>