Matthew Knepley <[email protected]> writes: > On Thu, Mar 22, 2018 at 7:09 AM, Jed Brown <[email protected]> wrote: > >> Matthew Knepley <[email protected]> writes: >> >> > On Thu, Mar 22, 2018 at 6:15 AM, Lisandro Dalcin <[email protected]> >> wrote: >> > >> >> On 22 March 2018 at 12:51, Matthew Knepley <[email protected]> wrote: >> >> > On Thu, Mar 22, 2018 at 3:44 AM, Lisandro Dalcin <[email protected]> >> >> wrote: >> >> >> >> >> >> >> >> >> ftp://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/ >> >> 2018/03/21/examples_master_arch-linux-cxx-cmplx-pkgs-64idx_churn.log >> >> >> >> >> >> The thing is, PETSc does not currently have a way of mapping a plain >> C >> >> >> `int` type to a PETSc datatype. I'm wiling to take the required work >> >> >> to fix this issue. >> >> > >> >> > >> >> > Is this not what PetscMPIInt is for? >> >> > >> >> >> >> No, not at all, PetscMPIInt it not even mentioned in the PetscDatatype >> >> enumeration. The whole PetscDatatype this is kind of messy, and fixing >> >> it should take some time, and this for sure will no make my h-index >> >> explode, right?. For now, mapping MPI_INT -> PETSC_ENUM seems >> >> workaround the issue just fine. >> >> >> > >> > What I meant was, we already have a typedef 'PetscMPIInt' which is >> supposed >> > to reproduce MPI_INT, so why not add PETSC_MPI_INT to the PetscDataTypes >> > rather than map MPI_INT to PetscEnum? >> >> https://bitbucket.org/petsc/petsc/issues/188/remove-use-of-petscdatatype >> > > I agree, but this was about short term fixing.
I guess I'd rather see a quick workaround if someone needs the capability now instead of expanding an interface that we're trying to remove.
