I am open to any suggestions to make the code better, especially if the way
it's coded now is wrong.
I believe what the MPI_TYPE_INDEXED is trying to do is this...
I have a domain of for example 8 hexahedral elements (2x2x2 cell domain)
that has 27 unique connectivity nodes (3x3x3 nodes)
In this
Dominik,
with MPI_Type_indexed, array_of_displacements is an int[]
so yes, there is a risk of overflow
on the other hand, MPI_Type_create_hindexed, array_of_displacements is
an MPI_Aint[]
note
array_of_displacements
Displacement for each block, in multiples of
oldtype
Hi Gilles,
I believe I have found the problem. Initially I thought it may have been an
mpi issue since it was internally within an mpi function. However, now I am
sure that the problem has to do with an overflow of 4-byte signed integers.
I am dealing with computational domains that have a little
Dominic,
at first, you might try to add
call MPI_Barrier(comm,ierr)
between
if (file_is_there .and. irank.eq.iroot) call
MPI_FILE_DELETE(file,MPI_INFO_NULL,ierr)
and
call
MPI_FILE_OPEN(comm,file,IOR(MPI_MODE_WRONLY,MPI_MODE_CREATE),MPI_INFO_NULL,iunit,ierr)
/* there might me a race co
Gilles,
I do not have the latest mpich available. I tested using openmpi version
1.8.7 as well as mvapich2 version 1.9. both produced similar errors. I
tried the mca flag that you had provided and it is telling me that a
configuration file is needed.
all processes return:
STOP A configuration fi
Dominic,
this is a ROMIO error message, and ROMIO is from MPICH project.
at first, I recommend you try the same test with the latest mpich, in order
to check
whether the bug is indeed from romio, and has been fixed in the latest
release.
(ompi is a few version behind the latest romio)
would you b
