Lawrence,

So yes I am comparing apples to oranges here. The reason I wanted extruded meshes was because the mesh generation from Tetgen is extremely slow. I guess I'll just have to play around with these implementations a little more.

Thanks,
Justin

On Thu, Aug 18, 2016 at 9:47 AM, Lawrence Mitchell <lawrence.mitchell@imperial.ac.uk> wrote:


On 17/08/16 23:37, Justin Chang wrote:
> Attached are the log_views for all 8 cases (4 petsc and 4 firedrake).
>
> The KSPSolve timings for the petsc runs this time are slightly
> difference because I ensured that the solver tolerances and parameters
> matched that of the firedrake case. Still, i see roughly 81%
> efficiency compared to 69%. I also used an extruded mesh for firedrake
> (with 2D triangles as base) whereas PETSc used the
> DMPlexCreateBoxMesh(...)

Hi Justin,

I realise I should have asked for -snes_view as well.

I notice the problems are not quite set up the same, since the petsc
version uses -snes_type newtonls, whereas the firedrake one uses ksponly.

I guess there are a number of things that are going on.  The
connectivity is different between triangular prisms and tetrahedra for
one.  You could compare closer things if you used a UnitCubeMesh in
firedrake.  However, the dof-ordering will still not be the same, and
this may have an effect on the resulting AMG hierarchy (and hence the
scalability).  As you note, basically all the scaling issues come from
application of the ML preconditioner.  That may need a bit of tuning.
 Its application will be bandwidth limited, so the dof ordering and
how fast things coarsen will likely have a big effect.

Cheers,

Lawrence


_______________________________________________
firedrake mailing list
firedrake@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/firedrake