I wish I can only deal with small problem, but that is only a test problem and I guess we need to use this code to compute much larger 3-D cases. Now it is too slow so I cannot test any larger cases than 400k dofs. I tried 400k dofs, still, 2 cores are slower than 1 core.
The weirdest thing is the iterations does not change much, when using block jacobi this would change, but not significantly. Sometimes with Pilut the number of iterations even decreased, but with more time. On Tuesday, April 3, 2018 at 11:29:53 PM UTC-4, Wolfgang Bangerth wrote: > > > Feimi, > > > Of course, I will make a pull request after the preconditioner is fully > > commented & tested, although it was a really small addition to the > code... > > Excellent -- we are always glad for any kind of contribution, large or > small. > > > > I'm sorry I was not clear in explaining my problem. I had a block matrix > to > > solve, and the ILU is used for solving the inverse of the schur > complement > > (by applying ILU to an approximate of it as the preconditioner) in my > DIY > > preconditioner. > > > > I tried different # of dofs as you suggested and I found it very weird: > for > > same case with different number of global refinement, I found only when > I > > have 26k dofs, the time with 2 cores is faster than 1 core, either > coarser > > or finer mesh causes solver to be slower in parallel (also tried > > BlockJacobi and the results are almost the same). I wonder if there > could > > be any possibility that my communication has problem or the matrix is > > already not distributed? Don't understand.... > > That's such a small problem. The fastest way to solve problems that are so > small is to use a direct solver. I'll point to this again: > > > It often comes down to how much communication you do. If your problem is > > small, then there is not very much work to do for each process, and much > > time is spent on communication between processes. A typical rule of > thumb > > is that your problem needs to have at least 50,000 to 100,000 unknowns > per > > process for computations to offset communication. > > > As to the concrete slowdown you see, I would suggest to also look at the > number of GMRES iterations you do. If the number of iterations you need > depends significantly on the number of cores, then you're in trouble. Good > and > scalable methods must all result in a number of iterations that does not > depend on the number of cores in a significant way. > > Best > W. > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: [email protected] > <javascript:> > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
