[petsc-users] Debugging MatAssemblyEnd

[Dominik Szczerba]

>> I seem to have had a classical deadlock, A was being assembled while
>> some threads lurked around elsewhere. Adding some barriers seems to
>> fix the problem, at least with the cases I currently have.
>
> Barriers should never affect the correctness of a pure MPI code that doesn't
> do weird things like communicate through the filesystem. We use the barriers
> for debugging, but they can generally be removed once the underlying issue
> is sorted out.

Do you claim I should not use MPI_Barrier at all when only programming
Petsc? Is really all required synchronization managed automatically?

I do some raw MPI programming before and after, but not inside the
Petsc core solver.

> Also, when you say "threads", are you referring to MPI processes, or are you
> using actual threads (e.g. pthreads or OpenMP)?

I meant the MPI processes, sorry for the confusion.

>> What I still miss is what would be the advantage of
>> MPI_Barrier(((PetscObject)A)->comm) over
>> MPI_Barrier(PETSC_COMM_WORLD).
>
> I don't know whether all processes on PETSC_COMM_WORLD are supposed to pass
> through this assembly. If A was on a subcommunicator, then only those
> processes should be calling assembly. Note that these communicators are the
> same for many users.

They are not the same for me, but I think I see the point now.

Thanks,
Dominik