<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-06-29 17:15 GMT+02:00 Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com">stefano.zampini@gmail.com</a>> writes:<br>
<br>
> Vec and DM classes should not be visible from Sys. This is why they are<br>
> PetscObject.<br>
> If they were visible, builds with --with-single-library=0 will be broken.<br>
><br>
> 2018-06-29 17:06 GMT+03:00 Patrick Sanan <<a href="mailto:patrick.sanan@gmail.com">patrick.sanan@gmail.com</a>>:<br>
><br>
>> I'm looking at the VTK viewer implementation  and I notice that<br>
>> PetscViewerVTKAddField() [1]<br>
>> accepts a parameter which, despite being called "dm", is of type<br>
>> PetscObject.<br>
<br>
</span>I would not object to moving vtkv.c into src/dm -- it isn't actually<br>
usable without DM.<br></blockquote><div><br></div><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>> I think that this is used, amongst other things, to ensure that vectors<br>
>> being queued up to be written all come from the same DM.<br>
>><br>
>> I'd like to relax this to only require that the vectors all come from<br>
>> *compatible* DMDAs, but this would require the DM API in vtkv.c.<br>
<br>
</span>Why?  The function is developer level and there is VecGetDM() to give<br>
the correct DM.  I would rather that PetscViewerVTKAddField_VTK change<br>
this logic to merely check for compatibility:<br>
<br>
  if (vtk->dm) {<br>
    if (dm != vtk->dm) SETERRQ(PetscObjectComm((<wbr>PetscObject)viewer),PETSC_ERR_<wbr>ARG_INCOMP,"Cannot write a field from more than one grid to the same VTK file");<br></blockquote><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
>> My questions: is this argument of type PetscObject for any reason other<br>
>> than not wanting to bother including petscdm.h ? Might this be something<br>
>> other than a DM in some case (and in which case, why is the argument called<br>
>> "dm")? Am I missing a reason that I'll get into trouble eventually if I<br>
>> change this?<br>
>><br>
>> (Similar question for the "vec" argument).<br>
>><br>
>> [1] <a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/<wbr>petsc-current/docs/<wbr>manualpages/</a><br>
>> Viewer/PetscViewerVTKAddField.<wbr>html<br>
>><br>
><br>
><br>
><br>
> -- <br>
> Stefano<br>
</div></div></blockquote></div><br></div></div>