<div dir="ltr">On Sat, Jul 25, 2015 at 5:46 AM, Ian Hinder <span dir="ltr"><<a href="mailto:ian.hinder@aei.mpg.de" target="_blank">ian.hinder@aei.mpg.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>On 25 Jul 2015, at 12:26, Frank Loeffler <<a href="mailto:knarf@cct.lsu.edu" target="_blank">knarf@cct.lsu.edu</a>> wrote:</div><br><blockquote type="cite">Am 25. Juli 2015 11:35:27 MESZ, schrieb Ian Hinder <<a href="mailto:ian.hinder@aei.mpg.de" target="_blank">ian.hinder@aei.mpg.de</a>>:<span class=""><br><blockquote type="cite"><br>On 25 Jul 2015, at 10:35, Frank Loeffler <<a href="mailto:knarf@cct.lsu.edu" target="_blank">knarf@cct.lsu.edu</a>> wrote:<br><br><blockquote type="cite">If I remember correctly, the default is zero dissipation, so by<br></blockquote>default it already is effectively off now. <br><br>I'm referring to parameter files which set the McLachlan dissipation<br>parameter. Those will fail if we disable dissipation (at Kranc time).<br></blockquote><br>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.<br></span></blockquote><div><br></div>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).</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-erik</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Dissipation can be provided:</div><div><br></div><div>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 </div><div>2. By McLachlan, which is more limited, but which Erik expects to be faster</div><div><br></div><div>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. </div><span class=""><div><br></div><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div>-- </div><div>Ian Hinder</div><div><a href="http://members.aei.mpg.de/ianhin" target="_blank">http://members.aei.mpg.de/ianhin</a></div></div></div></div></div>
</div>
<br></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div>
</div></div>