hi Stefano, (taking it back on the list)
>> Also note that >> the matrix depends on the number of processes because the degrees of >> freedom are ordered in a different way. The matrix should be the same >> with the same number of processes of course. >> > So, I can't test for a correct parallel assembly by comparing a serial > output to a parallel one? Is there a way do to that? Not easily. The problem is that the degrees of freedom need to be numbered differently depending on the number of processes. This is because each process gets a contiguous range. You could create a mapping for the reordering of the degrees of freedom and then swap rows and columns of the matrix. Problem is that even then, a matrix does not need to be the same, because an entry (a+b)+c is not necessarily equal to (c+b)+a in floating point. You can not control the order in a parallel computation to match the serial case. We also don't know the order of operations inside of PETSc, so reproducing that is very hard to do. You should verify on a higher level by looking at norms, integrate errors, or compare to reference solutions. >> Is this also happening in step-18 for you? > > Yes, it also happening with step-18. I inserted a call to write_ascii() > function assembly_system() in TopLevel<dim>::solve_timestep(). Can you describe exactly what is happening, what output you are getting, and what it should be? If you give me a small example I can check if I can reproduce the problem (it might be related to a certain petsc version for example). You can email me a patch or different source code. Try to make the problem/number of processes/etc. as small as possible. -- Timo Heister http://www.math.tamu.edu/~heister/ _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
