I think I have found a work-around, which I post here in case anyone else has encountered a problem similar to mine.<br><br>I tried all the other preconditioner options available in the sparskit version of GetDP. I had been using the default (option #2, ILUTP) preconditioner. This is the one that was requiring 13 to 14 minutes to compute. Option 6 -- simple ILU(0) -- seems to be working for me. It takes less than a second to compute. Judging by the number of GMRES iterations then required by the solver, it is not as good a preconditioner as the ILUTP. (It takes now 300 to 400 iterations instead of less than 100), but these extra iterations take very little time and the solution at the end of them differs by only a few parts per million from the previous solution. It seems a good trade.<br>
<br>None of the other preconditioner options worked well for my situation. Options 0, 7, and 8 took longer and caused GMRES to fail to converge in the allotted 1000 iterations, often with erroneous solution. Option 1 (ILUT) is related to ILUTP. The quality of the result was good, but it required almost as much time. Options 3, 4, and 5 caused the calculation to fail with a "Not enough memory. Buy more RAM!" error message.<br>
<br>I don't know what is the difference between ILUTP and ILU0. I plan to read about them in hopes there are no serious pitfalls in using the latter for my problem.<br><br>For situations such as mine, an option to export and import the preconditioner to and from a file, plus the option to use the imported preconditioner instead of computing a new one would probably be the best of all if it were available. (I report this for what it is worth, having no way myself to judge whether this would be difficult to implement or whether there are many others who would benefit from it and very grateful already to have the existing capabilities at such a good price!)<br>
<br>John<br><br><br><div class="gmail_quote">On Tue, Jan 18, 2011 at 2:14 PM, John_V <span dir="ltr"><<a href="mailto:jvillar.john@gmail.com">jvillar.john@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">Dear Christophe,<br><br>I am attaching an example as you suggested, smaller than usual though maybe not exactly small. (The mesh should be big enough to require at least a few seconds. Otherwise the problem is not illustrated.)<br>
<br>The example represents a single instance of executing GetDP. What differs upon the next instance is only the charge distribution, as described in comments in the <a href="http://sample.pro" target="_blank">sample.pro</a> file.<br>
<br>
The out.txt file lists GetDP output, including the "CPU = xxx s" messages. I interpret these as follows for this example (smaller mesh) and usual case (several million element mesh):<br><br>Step Time fraction this step (this example) Time fraction this step (usual case)<br>
<br>Pre-processing 19.7% 30.7% <br>Generate Sys_Ele 12.9% 2.5%<br>RCMK renumbering 1.0% 0.2%<br>
ILUTP 64.1% 65.7%<br>GMRES 1.9% 0.8%<br>Save 0.3% 0.1%<br>
<br>If my descriptions under "Step" are right, it seems GMRES is very quick. Most of the time is spent in ILUTP (which is preconditioning, right?) followed by pre-processing.<br><br>It seems worth a try to export the preconditioner, then import and re-use it rather than recompute it the next time. Is it possible? <br>
<br>John<br><br><br><br></div><div class="gmail_quote"><div class="im">On Fri, Jan 14, 2011 at 7:58 AM, Christophe Geuzaine <span dir="ltr"><<a href="mailto:cgeuzaine@ulg.ac.be" target="_blank">cgeuzaine@ulg.ac.be</a>></span> wrote:<br>
</div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On 13/01/11 15:20, John_V wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I am using GetDP to repeatedly solve electrostatic problems on the same<br>
mesh. The only thing that changes from one solution to the next is the<br>
distribution of charges. That is, GetDP is solving K.V = S for V, where<br>
the stiffness matrix K is every time the same and only S changes. In<br>
this circumstance it is not in principle necessary to build K from the<br>
mesh every time. It could just be built the first time and then reused.<br>
<br>
I have two questions:<br>
<br>
1. Does GetDP presently implement any mechanism to do this? For example,<br>
is there a way to export the matrix to a file after it is computed, and<br>
then import it for use the next time GetDP is used?<br>
<br>
</blockquote>
<br></div>
Yes (see the Print command), but I don't think it would help, as currently the matrix and the right hand side are assembled during the same process.<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2. Is this likely to save any (or much) time? Each resolution is taking<br>
about 15 to 50 minutes on my computer, but I don't know what fraction of<br>
this is spent building the K matrix and what fraction is actually<br>
solving the system of equations. I know from watching the output that<br>
all of the [0% - 10% - ... 90% - Done] convergence messages appear in<br>
the last minute or so. If those coincide with the solution of the<br>
equations then it may be that a significant amount of the time is spent<br>
computing K, in which case this could lead to a big time savings.<br>
<br>
</blockquote>
<br></div>
For low order interpolation (1st order), solving the linear system should take much longer than assembling the matrix (unless there are some really complex expressions to be evaluated to build the operator).<br>
<br>
To keep the preconditionner from one solution to the other, you can use "SolveAgain" instead of "Solve" in the operations.<br>
<br>
If this does not help, could you send a small example?<br>
<br>
Thanks,<br>
<br>
Christophe<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
John<br>
<br>
<br>
_______________________________________________<br>
getdp mailing list<br>
<a href="mailto:getdp@geuz.org" target="_blank">getdp@geuz.org</a><br>
<a href="http://www.geuz.org/mailman/listinfo/getdp" target="_blank">http://www.geuz.org/mailman/listinfo/getdp</a><br>
<br>
</blockquote>
<br>
<br>
-- <br>
Prof. Christophe Geuzaine<br>
University of Liege, Electrical Engineering and Computer Science<br>
<a href="http://www.montefiore.ulg.ac.be/%7Egeuzaine" target="_blank">http://www.montefiore.ulg.ac.be/~geuzaine</a><br>
</blockquote></div></div></div><br>
</blockquote></div><br>