On 18 October 2010 14:26, Jed Brown <jed at 59a2.org> wrote: > On Mon, Oct 18, 2010 at 03:25, Barry Smith <bsmith at mcs.anl.gov> wrote: >> >> DAXXX() routines are now either DMXXX() or DMDAXXX() see petscdm.h for >> details > > 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. > 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. > 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. > Jed
In a private chat discussion, Jed said this: With DMs, the user will never have a discretization that works with a generic DM, they will always reference explicitly which DM they are using. Because DA is so different from an unstructured mesh or a particle method, they have to choose which method they are using. Very different from matrices where they don't have to choose until runtime. I totally agree. -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169
