<p dir="ltr">Hi Thomas,</p>
<p dir="ltr">Assuming this is not the issue (it is probably worth explicitly measuring), it is also important to ensure that the sparsity pattern is preserved, not just the number of nonzeros per row. A sparse matrix with random nonzero locations is much more expensive to factor than one with entries near the diagonal.</p>
<p dir="ltr">Jack</p>
<div class="gmail_quote">On Dec 20, 2012 1:01 PM, "Thomas Witkowski" <<a href="mailto:Thomas.Witkowski@tu-dresden.de">Thomas.Witkowski@tu-dresden.de</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jack, I also considered this problem. The 4 MPI tasks of each coarse space matrix should run all on one node (each node contains 4 dual core CPUs). I'm not 100% sure, but I discussed this with the administrators of the system. The system should schedule always the first 8 ranks to the first node, and so on. And the coarse space matrices are build on ranks 0-3, 4-7 ...<br>
<br>
I'm running at the moment some benchmarks, where I replaced the local LU factorization from using UMFPACK to MUMPS. Each matrix and the corresponding ksp object are defined on PETSC_COMM_SELF and the problem is perfectly balanced (the grid is a unit square uniformly refined). Lets see...<br>
<br>
Thomas<br>
<br>
Zitat von Jack Poulson <<a href="mailto:jack.poulson@gmail.com" target="_blank">jack.poulson@gmail.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Thomas,<br>
<br>
Network topology is important. Since most machines are not fully connected,<br>
random subsets of four processes will become more scattered about the<br>
cluster as you increase your total number of processes.<br>
<br>
Jack<br>
On Dec 20, 2012 12:39 PM, "Thomas Witkowski" <<a href="mailto:Thomas.Witkowski@tu-dresden.de" target="_blank">Thomas.Witkowski@tu-dresden.<u></u>de</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I cannot use the information from log_summary, as I have three different<br>
LU factorizations and solve (local matrices and two hierarchies of coarse<br>
grids). Therefore, I use the following work around to get the timing of the<br>
solve I'm intrested in:<br>
<br>
MPI::COMM_WORLD.Barrier();<br>
wtime = MPI::Wtime();<br>
KSPSolve(*(data->ksp_schur_**<u></u>primal_local), tmp_primal, tmp_primal);<br>
FetiTimings::fetiSolve03 += (MPI::Wtime() - wtime);<br>
<br>
The factorization is done explicitly before with "KSPSetUp", so I can<br>
measure the time for LU factorization. It also does not scale! For 64<br>
cores, I takes 0.05 seconds, for 1024 cores 1.2 seconds. In all<br>
calculations, the local coarse space matrices defined on four cores have<br>
exactly the same number of rows and exactly the same number of non zero<br>
entries. So, from my point of view, the time should be absolutely constant.<br>
<br>
Thomas<br>
<br>
Zitat von Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>>:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are you timing ONLY the time to factor and solve the subproblems? Or<br>
also the time to get the data to the collection of 4 cores at a time?<br>
<br>
If you are only using LU for these problems and not elsewhere in the<br>
code you can get the factorization and time from MatLUFactor() and<br>
MatSolve() or you can use stages to put this calculation in its own stage<br>
and use the MatLUFactor() and MatSolve() time from that stage.<br>
Also look at the load balancing column for the factorization and solve<br>
stage, it is well balanced?<br>
<br>
Barry<br>
<br>
On Dec 20, 2012, at 2:16 PM, Thomas Witkowski <<br>
thomas.witkowski@tu-dresden.**<u></u>de <<a href="mailto:thomas.witkowski@tu-dresden.de" target="_blank">thomas.witkowski@tu-dresden.<u></u>de</a>>> wrote:<br>
<br>
In my multilevel FETI-DP code, I have localized course matrices, which<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
are defined on only a subset of all MPI tasks, typically between 4 and 64<br>
tasks. The MatAIJ and the KSP objects are both defined on a MPI<br>
communicator, which is a subset of MPI::COMM_WORLD. The LU factorization<br>
of the matrices is computed with either MUMPS or superlu_dist, but both<br>
show some scaling property I really wonder of: When the overall problem<br>
size is increased, the solve with the LU factorization of the local<br>
matrices does not scale! But why not? I just increase the number of local<br>
matrices, but all of them are independent of each other. Some example: I<br>
use 64 cores, each coarse matrix is spanned by 4 cores so there are 16 MPI<br>
communicators with 16 coarse space matrices. The problem need to solve 192<br>
times with the coarse space systems, and this takes together 0.09 seconds.<br>
Now I increase the number of cores to 256, but let the local coarse space<br>
be defined again on only 4 cores. Again, 192 solutions with these coarse<br>
spaces are required, but now this takes 0.24 seconds. The same for 1024<br>
cores, and we are at 1.7 seconds for the local coarse space solver!<br>
<br>
For me, this is a total mystery! Any idea how to explain, debug and<br>
eventually how to resolve this problem?<br>
<br>
Thomas<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote></div>