[petsc-dev] Simultaneous use of different precisions

Barry Smith bsmith at mcs.anl.gov
Wed Nov 17 16:14:46 CST 2010

On Nov 17, 2010, at 4:06 PM, Jed Brown wrote:

> On Wed, Nov 17, 2010 at 22:41, Barry Smith <bsmith at mcs.anl.gov> wrote:
> I hate beyond words the standard C++ template model
> Me too.
> This, I think, can be done using ONLY simple C++ function polymorphism (allowing VecSetValues(double*) and VecSetValues(single *) for example)
> If I call VecGetArray(X,&singleptr) and X is "double", would this error or make a copy?

   In Model II it is an error (runtime) whenever you call an object of one precision with a function that exposes a different precision.

>  What about "local" callbacks (or any callback that passes scalars)?  And any composed function (that part is not type safe, so C++ name mangling won't save you)?

   Beats me.

> An acceptable C solution might be to have a PetscShortScalar typedef, VecGetArrayShort(), and maybe also MatSetValuesShort() (integration for assembly can be time consuming, and float is twice as fast if you vectorize well) which would give you no-copy access to short storage.  You could still have C++ overloaded variants, but I usually want some explicit control over types matching.  To allow people to make their Shorts (likely float) into Longs (likely double), have them recompile with a macro defined that causes the Short names to be defined to the long ones.

  Yuck :-).  This doesn't really simplify things anyways because there are billions of places where calls are made where the calling function has a exposed precision in one of the arguments. Somehow you've got to get PETSc compiled with both precisions and in the same library.

> But this does snowball if you want {Real,Complex}{Short,Long} in the same code.
> Documentation for the Short variants could be organized so that it doesn't cause clutter, but hopefully there aren't a huge number that need this specialization.
> Thanks for the summary, I hope it works out.

   After a tiny bit of hard earned success I'm thinking redoing all of PETSc with proper code generation :-) What will I think tommorow :-(


> Jed

More information about the petsc-dev mailing list