[petsc-dev] major changes to DA in PETSc-dev

Lisandro Dalcin dalcinl at gmail.com
Mon Oct 18 08:08:23 CDT 2010

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
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
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

More information about the petsc-dev mailing list