<html>#2288: Lean's boundary condition setting for BSSN constraints only fills in a single ghostzone
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Zach Etienne</td></tr>
<tr><td style='text-align:right'> Status:</td><td>open</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>bug</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>major</td></tr>
<tr><td style='text-align:right'>Component:</td><td>EinsteinToolkit thorn</td></tr>
</table>
<p>Comment (by Roland Haas):</p>
<p>Hell Miguel,</p>
<p>yes, tying the request boundary size to your codes stencil rather than the boundary size in the parfile is fine (done eg by GRHydro). In some sense better (you are actually asking for what you need), in some sense worse (there may not be enough boundary points in the parfile, or if there are too many then some will be left uninitialized).</p>
<p>I am just about to create new point release for ET_2020_05 so if your fixes are in master than I can included them (only the fixes though, no new features).</p>
<p>Since you are hosting Lean_public in your own repository and not one owned by the ET, there is very little that the ET (can) enforce as far as your group handling commits goes. If you are internally developing in in a “development” branch and then, after some internal review, you merge to master then you are already doing fine as far as I am concerned. “master” in the ET is explicitly marked as “this will break your code occasionally” (ie closer to a typical “development” branch). </p>
<p>If there is too much “bad” stuff in master at the time of the next release then the release branch will not update to master and stay stuck at the last release. If master becomes too much broken (or ends up having code that is deemed inappropriate for the ET) then we will either cherry pick from master what we want (lots of work for me so this will only happen if there is manifest interest in the code), not update the release branch (annoying if there are bugfixes), or fork the repo and run a separate ET fork (this would qualify as the “nuclear option” as it is most time consuming) essentially having a “stable” master and a “devel” master (happened to GRHydro vs. Zelmani for a while). Before that happens you can expect emails from the maintainers about “master” being a mess so there should be time to avoid this happening.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2288/leans-boundary-condition-setting-for-bssn'>https://bitbucket.org/einsteintoolkit/tickets/issues/2288/leans-boundary-condition-setting-for-bssn</a></p>
</html>