[Users] Benchmarking results for McLachlan rewrite

[Erik Schnetter]

On Sat, Jul 25, 2015 at 5:46 AM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:

>
> On 25 Jul 2015, at 12:26, Frank Loeffler <knarf at cct.lsu.edu> wrote:
>
> Am 25. Juli 2015 11:35:27 MESZ, schrieb Ian Hinder <ian.hinder at aei.mpg.de
> >:
>
>
> On 25 Jul 2015, at 10:35, Frank Loeffler <knarf at cct.lsu.edu> wrote:
>
> If I remember correctly, the default is zero dissipation, so by
>
> default it already is effectively off now.
>
> I'm referring to parameter files which set the McLachlan dissipation
> parameter.  Those will fail if we disable dissipation (at Kranc time).
>
>
> I didn't think you mean at Kranc time. I would think we shouldn't do that.
> Rerunning Kranc shouldn't be necessary to enable something like dissipation.
>
>
> Actually I do.  On the rewrite branch, McLachlan has a switch to enable
> dissipation at Kranc time.  Once enabled, it is unconditionally computed at
> run time, which takes a certain amount of time.  This cannot currently be
> disabled at run time.  Erik was asking (I think) whether this Kranc-time
> dissipation should be disabled, since in the case that users want to use
> dissipation from the Dissipation thorn, they incur an unavoidable
> performance penalty (dissipation terms will be computed twice, though one
> of them will be multiplied by zero).
>

To implement dissipation efficiently, it is calculated at the same time as
other derivatives. This avoids having multiple loops over the grid
functions. Previously, McLachlan applied the dissipation in a routine of
its own that could easily be scheduled or not. Now, it is applied when the
RHS is calculated, and Kranc does not offer a mechanism that would avoid
calculating the dissipation stencils based on a parameter. It would easily
be possible to add a parameter that skips adding dissipation to the RHS,
but this is essentially the same as setting the dissipation strength to
zero. However, even if it is not added, the stencils is still calculated.
Hence this decision needs to be made at Kranc time, until Kranc is extended
to offer this functionality.

In principle, calculating the dissipation terms while the RHS is calculated
should be faster. This also seems to be the case currently -- old ML
without dissipation + extra dissipation is slightly slower than new ML with
dissipation. However, this is not the case which interests Ian; Ian wants
to use an external dissipation mechanism. Hence I now created ML_BSSN_ND
(No Dissipation) that can be used to test this. I don't think this should
be the default; rather, we should ask people to give this a try and measure
performance, and we should also add missing features if necessary.

-erik

Dissipation can be provided:
>
> 1. By the Dissipation thorn, which provides several useful (needed)
> features, such as being able to control the dissipation strength on a given
> refinement level, the dissipation order, as well as having some options for
> excision masks (which I have never used, but others might); or
> 2. By McLachlan, which is more limited, but which Erik expects to be faster
>
> The pre-rewrite version of McLachlan had very slow dissipation, but it was
> not executed if the dissipation strength was set to 0 at runtime, so this
> problem did not arise.
>
> --
> Ian Hinder
> http://members.aei.mpg.de/ianhin
>
>


-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150725/fd664d0f/attachment.html