<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 10, 2016 at 9:54 PM, Harshad Ranadive <span dir="ltr"><<a href="mailto:harshadranadive@gmail.com" target="_blank">harshadranadive@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi All,<div><br></div><div>I have currently added the PETSc library with our CFD solver. </div><div><br></div><div>In this I need to use KSPSolve(...) multiple time for the same matrix A. I have read that PETSc does not support passing multiple RHS vectors in the form of a matrix and the only solution to this is calling KSPSolve multiple times as in example given here:</div><div><a href="http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/ksp/examples/tutorials/ex16.c.html" target="_blank">http://www.mcs.anl.gov/petsc/<wbr>petsc-current/src/ksp/ksp/<wbr>examples/tutorials/ex16.c.html</a><br></div><div><br></div><div>I have followed this technique, but I find that the performance of the code is very slow now. I basically have a mesh size of 8-10 Million and I need to solve the matrix A very large number of times. I have checked that the statement KSPSolve(..) is taking close to 90% of my computation time.</div><div><br></div><div>I am setting up the matrix A, KSPCreate, KSPSetup etc just once at the start. Only the following statements are executed in a repeated loop</div><div><br></div><div><i>Loop begin: (say million times !!)</i></div><div><i><br></i></div><div><i>   loop over vector length</i></div><div><i>       VecSetValues( ....)</i></div><div><i>   end</i></div><div><i><br></i></div><div><i>   VecAssemblyBegin( ... )</i></div><div><i>   VecAssemblyEnd (...)</i></div><div><i><br></i></div><div><i>    KSPSolve (...)</i></div><div><i><br></i></div><div><i>    VecGetValues</i></div><div><i><br></i></div><div><i>Loop end.</i></div><div><br></div><div>Is there an efficient way of doing this rather than using KSPSolve multiple times?</div><div><br></div><div>Please note my matrix A never changes during the time steps or across the mesh ... So essentially if I can get the inverse once would it be good enough?  It has been recommended in the FAQ that matrix inverse should be avoided but would it be okay to use in my case?</div><div><br></div><div>Also could someone please provide an example of how to use MatLUFactor and MatCholeskyFactor<span style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium">() to find the matrix inverse... the arguments below were not clear to me.</span></div><div><span style="color:rgb(0,0,0)"><i>IS row </i></span></div><div><span style="color:rgb(0,0,0)"><i>IS col</i></span></div><div><span style="color:rgb(0,0,0)"><i>const MatFactorInfo *info</i></span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><font color="#000000">Apologies for a long email and thanks to anyone for help.</font></div></div></blockquote><div><br></div><div>1) For any questions, we NEED to see the output of -log_view for all cases you are asking about</div><div><br></div><div>2) You could try factoring your matrix</div><div><br></div><div>  -pc_type lu -pc_factor_mat_solver_package <mumps,superlu_dist></div><div><br></div><div>and it would be reused across solves, but for large matrices you can run out of memory.</div><div><br></div><div>3) You can factor subdomains with BJacobi or ASM and they would be reused, but this might be a crap preconditioner.</div><div><br></div><div>4) For any questions about convergence, we need to see the output of</div><div><br></div><div>  -ksp_view -ksp_monitor_true_residual -ksp_converged_reason</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><font color="#000000">Regards</font></div><span class="HOEnZb"><font color="#888888"><div><font color="#000000">Harshad</font></div></font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>