<div class="gmail_quote">On Mon, Oct 18, 2010 at 03:25, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
DAXXX() routines are now either DMXXX() or DMDAXXX() see petscdm.h for details</blockquote></div><br><div>I'm a little concerned about this because all of these have implicit downcasting with no RTTI, so they are all totally unsafe.  When DA was a distinct type, you couldn't call DAGetCorners with a DM that was not also a DA.  Now the user has a generic DM, but almost every call they will make is a memory error if their DM is not DMDA.  It could be made runtime-safe by putting RTTI guards at the top of every public DMDA* function, but runtime type checking is not as good as compile-time if the latter is reasonably achievable.</div>
<div><br></div><div>Note that PETSc itself (for multigrid, DD, etc) works almost exclusively with the DM API and should not need to call the DMDA API directly (specialization is via DMOps).  In contrast, user code is specialized to a particular implementation of DM, and pretty much always uses the specialized API.  The old API was safer because the API that the user called was explicitly specialized, rather than implicitly downcasted from DM.  </div>
<div><br></div><div>Of course I agree that DM organization was messy, but I'm not convinced that this change is an improvement for the user since it gives up a lot of safety and offers little in return.</div><div><br>
</div><div>Jed</div>