petsc carries a version of Blas that uses int arguments (int32) type, while 
Matlab carries a version of Blas that uses int64_t arguments (hidden behing 
a ptrdiff_t type (check MATLAB_DIR/extern/include/blas.h). 
In serial mode, Matlab discards the Petsc Blas library (even when it was statically 
linked against the mex files!) symbols, and replaces them with its version. 
Because the prototypes conflict (32 vs 64), crashes ensue whenever using a Blas 
routine (for ex: VecAXPY calls BLASaxpy_, which calls daxpy). 

To avoid that, we have to recompile Petsc with a 64 bit prototype. Luckily, 
Petsc did a good job, and hid the Blas int type into the typedef BLASint (check
in include/petsc.h). Just typedef it back from int to int64_t, and recompile, 
and that does the trick. Don't forget the #include "inttypes.h" at the top of petsc.h,
otherwise, crashes during the compile.

Same problem may arise for using the lapack library.

Now, Petsc pretends it can compile in --with-64-bit-pointers. That sets PetscInt to long long 
The only problem, it says MUMPS, Scalapack, blacs, Plapack don't support 64 bit indexing. 
Mumps looks like it might. 

If compiling --with-64-bit-pointers,  all prototypes in Petsc ask for PetscInt = long long 
which Issm does not know. Can't compile with this option. Unless we switch to 64 bit integers 
in ISSM. Started to put this framework into place: we now have IssmInt, IssmDouble, IssmChar 
in types.h. They rely on ISSM_USE_64_BIT_INDEXING symbol, define in config.h, instantiated by 
autotools with --with-64bit-pointers=1 in configure.sh

Recomendation: wait until MUMPS implements 64 bit indexing. 
