A 3D example of KSPSolve?

[Shi Jin]

MatGetRow are used to build the right hand side
vector.
We use it in order to get the number of nonzero cols,
global col indices and values in a row.

The reason it is time consuming is that it is called
for each row of the matrix. I am not sure how I can
get  away without it.
Thanks.

Shi
--- Barry Smith <bsmith at mcs.anl.gov> wrote:

> 
>   What are all the calls for MatGetRow() for? They
> are consuming a
> great deal of time. Is there anyway to get rid of
> them?
> 
>    Barry
> 
> 
> On Fri, 9 Feb 2007, Shi Jin wrote:
> 
> > Sorry that is not informative.
> > So I decide to attach the 5 files for
> NP=1,2,4,8,16
> > for 
> > the 400,000 finite element case.
> > 
> > Please note that the simulation runs over 100
> steps.
> > The 1st step is first order update, named as stage
> 1.
> > The rest 99 steps are second order updates. Within
> > that, stage 2-9 are created for the 8 stages of a
> > second order update. We should concentrate on the
> > second order updates. So four calls to KSPSolve in
> the
> > log file are important, in stage 4,5,6,and 8
> > separately.
> > Pleaes let me know if you need any other
> information
> > or explanation.
> > Thank you very much.
> > 
> > Shi
> > --- Matthew Knepley <knepley at gmail.com> wrote:
> > 
> > > You really have to give us the log summary
> output.
> > > None of the relevant
> > > numbers are in your summary.
> > > 
> > >  Thanks,
> > > 
> > >    Matt
> > > 
> > > On 2/9/07, Shi Jin <jinzishuai at yahoo.com> wrote:
> > > >
> > > > Dear Barry,
> > > >
> > > > Thank you.
> > > > I actually have done the staging already.
> > > > I summarized the timing of the runs in google
> > > online
> > > > spreadsheets. I have two runs.
> > > > 1. with 400,000 finite elements:
> > > >
> > >
> >
>
http://spreadsheets.google.com/pub?key=pZHoqlL60quZeDZlucTjEIA
> > > > 2. with 1,600,000 finite elements:
> > > >
> > >
> >
>
http://spreadsheets.google.com/pub?key=pZHoqlL60quZcCVLAqmzqQQ
> > > >
> > > > If you can take a look at them and give me
> some
> > > > advice, I will be deeply grateful.
> > > >
> > > > Shi
> > > > --- Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > >
> > > > >
> > > > >   NO, NO, don't spend time stripping your
> code!
> > > > > Unproductive
> > > > >
> > > > >   See the manul pages for
> > > PetscLogStageRegister(),
> > > > > PetscLogStagePush() and
> > > > > PetscLogStagePop(). All you need to do is
> > > maintain a
> > > > > seperate stage for each
> > > > > of your KSPSolves; in your case you'll
> create 3
> > > > > stages.
> > > > >
> > > > >    Barry
> > > > >
> > > > > On Fri, 9 Feb 2007, Shi Jin wrote:
> > > > >
> > > > > > Thank you.
> > > > > > But my code has 10 calls to KSPSolve of
> three
> > > > > > different linear systems at each time
> update.
> > > > > Should I
> > > > > > strip it down to a single KSPSolve so that
> it
> > > is
> > > > > > easier to analysis? I might have the code
> dump
> > > the
> > > > > > Matrix and vector and write another code
> to
> > > read
> > > > > them
> > > > > > into and call KSPSolve. I don't know
> whether
> > > this
> > > > > is
> > > > > > worth doing  or should I just send in the
> > > messy
> > > > > log
> > > > > > file of the whole run.
> > > > > > Thanks for any advice.
> > > > > >
> > > > > > Shi
> > > > > >
> > > > > > --- Barry Smith <bsmith at mcs.anl.gov>
> wrote:
> > > > > >
> > > > > > >
> > > > > > >   Shi,
> > > > > > >
> > > > > > >    There is never a better test problem
> then
> > > > > your
> > > > > > > actual problem.
> > > > > > > Send the results from running on 1, 4,
> and 8
> > > > > > > processes with the options
> > > > > > > -log_summary -ksp_view (use the
> optimized
> > > > > version of
> > > > > > > PETSc (running
> > > > > > > config/configure.py --with-debugging=0))
> > > > > > >
> > > > > > >   Barry
> > > > > > >
> > > > > > >
> > > > > > > On Fri, 9 Feb 2007, Shi Jin wrote:
> > > > > > >
> > > > > > > > Hi there,
> > > > > > > >
> > > > > > > > I am tuning our 3D FEM CFD code
> written
> > > with
> > > > > > > PETSc.
> > > > > > > > The code doesn't scale very well. For
> > > example,
> > > > > > > with 8
> > > > > > > > processes on a linux cluster, the
> speedup
> > > we
> > > > > > > achieve
> > > > > > > > with a fairly large problem
> size(million
> > > of
> > > > > > > elements)
> > > > > > > > is only 3 to 4 using the Congugate
> > > gradient
> > > > > > > solver. We
> > > > > > > > can achieve a speed up of a 6.5 using
> a
> > > GMRes
> > > > > > > solver
> > > > > > > > but the wall clock time of a GMRes is
> > > longer
> > > > > than
> > > > > > > a CG
> > > > > > > > solver which indicates that CG is the
> > > faster
> > > > > > > solver
> > > > > > > > and it scales not as good as GMRes. Is
> > > this
> > > > > > > generally
> > > > > > > > true?
> > > > > > > >
> > > > > > > > I then went to the examples and find a
> 2D
> > > > > example
> > > > > > > of
> > > > > > > > KSPSolve (ex2.c). I let the code ran
> with
> > > a
> > > > > > > 1000x1000
> > > > > > > > mesh and get a linear scaling of the
> CG
> > > solver
> > > > > and
> > > > > > > a
> > > > > > > > super linear scaling of the GMRes.
> These
> > > are
> > > > > both
> > > > > > > much
> > > > > > > > better than our code. However, I think
> the
> > > 2D
> > > > > > > nature
> 
=== message truncated ===



 
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com