On 2013-12-16 13:23, Nico Schlömer wrote:
I did some timings here and found that whenever the Jacobian is
constructed, most of the computational time goes into the cell
iteration in Assembler::assemble_cells(...). Specifically (in units of
seconds)
Not surprising. It's where all the work is done.
ufc.get_cell_integral: 00:00:00.006977
ufc.update 00:00:01.133166
get local-to-global dof maps: 00:00:00.009772
integral->tabulate_tensor: 00:00:03.289413
add_to_global_tensor: 00:00:01.693635
How did you do the timing? Some of these calls involve so little work
that they are hard to time.
I'm not entirely sure what the purpose of all of these call is, but I
guess that tabulate_tensor does the actual heavy lifting, i.e., the
integration. Besides this, the ufc.update
There are some optimisations for UFC::update(...) in
https://bitbucket.org/fenics-project/dolfin/pull-request/73/
UFC::update(...) copies some data unnecessarily (e.g. topology data).
and the addition to the
global tensor take a significant amount of time.
Since I'm solving a series of linear problems (in fact, a (time)
series of nonlinear problems) very similar in structure, I think the
one or the other call might be cached away. The mere caching of the
sparsity structure as done in the CahnHilliard demo doesn't do much.
Preserving the sparsity structure makes a significant difference, but I
believe that you'll see the difference when GenericMatrix::apply() is
called.
Does anyone have more insight into what might be worth exploiting here
for speedup?
There is limit scope for speed up of this step (if you want to solve
Ax=b). I have a plan for some mesh data reordering that can speed up
insertion through improved data locality. One reason the insertion looks
relatively costly is that the tabulate_tensor function is highly
optimised. From numbers I've seen about, it can be several times faster
than for other codes.
It is possible to assemble into a different sparse matrix data
structures, but my experience is that this pushes the time cost further
down the line, i.e. to the linear solver. You can try assembling into a
dolfin::STLMatrix.
Garth
Cheers,
Nico
On Mon, Jun 3, 2013 at 8:54 PM, Garth N. Wells <[email protected]> wrote:
On 3 June 2013 19:49, Nico Schlömer <[email protected]> wrote:
Hi all,
when solving nonlinear problems, I simply went with
# define F
J = derivative(F, u)
solve(F1 == 0, u, bcs, J)
for now (which uses Newton's method).
I noticed, however, that the computation of the Jacobian,
nonlinear_problem.J(*_A, x);
takes by the most time in the computation.
Is there some caching I could employ? I need to solve a similar
nonlinear
system in each time step.
Use the lower-level NewtonSolver class. You then have complete control
over how J is computed/supplied/cached.
The Cahn-Hilliard demo illustrates use of the NewtonSolver class.
Garth
--Nico
_______________________________________________
fenics-support mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics-support
_______________________________________________
fenics-support mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics-support
