On Fri, Sep 14, 2012 at 1:53 AM, Birendra jha <span dir="ltr"><<a href="mailto:bjha7333@yahoo.com" target="_blank">bjha7333@yahoo.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear developers<br>
<br>
I simplified my problem setup to see if no. of KSP iterations goes down. There are 46552 nodes, 42525 hex elements in a box. In this very simple setup, both ASM and ML preconditioner takes ~90 iterations for convergence.<br>
Attached are the cfg files and stdout from LU and ML preconditioners. ASM stdout is not attached.<br></blockquote><div><br></div><div>Something in your setup is causing the problem to be nearly or actually singular. Its either bad elements in</div>
<div>the mesh, or an inconsistent boundary condition I think.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why does the run with LU crash? I just used following 2 lines to use LU:<br>
[pylithapp.petsc]<br>
pc_type = lu<br>
Is it incorrect?<br></blockquote><div><br></div><div>This is interesting. Can you run in the debugger --petsc.start_in_debugger and get a stack trace?</div><div><br></div><div> Thanks,</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">
For both ASM and ML, the solution looks correct in Paraview. It's just the time taken in integrating residual that I would like to reduce.<br>
<br>
Another question: when Pylith is running on a single multicore machine, can it use OpenMPI instead of MPI (I am assuming it's using MPI by default)?<br>
<br>
Thanks and regards<br>
Birendra<br>
<br>
--- On Tue, 9/4/12, Brad Aagaard <<a href="mailto:baagaard@usgs.gov">baagaard@usgs.gov</a>> wrote:<br>
<br>
> From: Brad Aagaard <<a href="mailto:baagaard@usgs.gov">baagaard@usgs.gov</a>><br>
> Subject: Re: Change in dt means new Jacobian<br>
> To: "Birendra jha" <<a href="mailto:bjha7333@yahoo.com">bjha7333@yahoo.com</a>><br>
> Cc: <a href="mailto:cig-short@geodynamics.org">cig-short@geodynamics.org</a><br>
> Date: Tuesday, September 4, 2012, 7:59 PM<br>
> On 09/03/2012 08:54 PM, Birendra jha<br>
> wrote:<br>
> > 3. How do I utilize multiple cores on a single machine?<br>
> Sorry if this<br>
> > question is already answered somewhere. I found<br>
> instructions on<br>
> > running parallel using a batch system but don't know<br>
> how to run on 1<br>
> > node and use multiple cores. Does this require<br>
> re-building Pylith?<br>
><br>
> To run in parallel all you have to do is add the command<br>
> line argument --nodes=NUM_CORES. You do not need to<br>
> rebuild.<br>
><br>
> > 4. For HDF5 output, is it correct that the I have to<br>
> wait until<br>
> > finish to get the xmf file which is needed to load h5<br>
> files in<br>
> > Paraview? Manual says "This file is written when PyLith<br>
> closes the<br>
> > HDF5 file at the end of the simulation".<br>
><br>
> The Xdmf file is written when PyLith closes the HDF5 file at<br>
> the end of a simulation. There is a python script included<br>
> with PyLith called pylith_genxdmf that will generate the<br>
> Xdmf file given an HDF5 file. This is handy if a simulation<br>
> did not finish or you add additional fields to an existing<br>
> HDF5 file. Generating the Xdmf file in the middle of a<br>
> simulation can work but it is risky because the HDF5 file<br>
> can get corrupted if multiple processes try to access the<br>
> file simultaneously.<br>
><br>
> pylith_genxdmf --file=HDF5_FILE<br>
><br>
> Brad<br>
><br>_______________________________________________<br>
CIG-SHORT mailing list<br>
<a href="mailto:CIG-SHORT@geodynamics.org">CIG-SHORT@geodynamics.org</a><br>
<a href="http://geodynamics.org/cgi-bin/mailman/listinfo/cig-short" target="_blank">http://geodynamics.org/cgi-bin/mailman/listinfo/cig-short</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>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<br>