<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi all,<div><br></div><div>As you may know, yt was originally written to handle outputs from cosmological simulations produced by the Enzo code.  Due to this pedigree, yt assumes internally in a number of places that the simulation box has periodic boundary conditions.  </div><div><br></div><div>In the last couple of years, we've been working on improving support for both non-cosmological simulations and datasets produced by codes besides Enzo.  This effort has come a long way, but until recently the nature of the boundary conditions has received relatively little development attention.  However, as yt becomes commonly used by people outside of the enzo community, the lack of proper support for general periodic or non-periodic boundary conditions is starting to be felt.  A particularly nasty case is the radius field, which in the current codebase assumes periodic boundary conditions, producing incorrect results when someone tries to profile a field versus radius in a simulation that assumed some sort of isolated boundary conditions.</div><div><br></div><div>Recently, Matt Turk came up with a summary of our strategy for improving support general boundary conditions, summarized in YTEP-0006: <a href="https://bitbucket.org/yt_analysis/ytep/src/tip/source/YTEPs/YTEP-0006.rst">https://bitbucket.org/yt_analysis/ytep/src/tip/source/YTEPs/YTEP-0006.rst</a></div><div><br></div><div>The main take-away points are that each of the code frontends will need to define a periodicity attribute that hangs off of each of the StaticOutput class.  This way, one can check the periodicity of a parameter file by doing something like:</div><div><br></div><div>>>> pf = load(filename)</div><div>>>> print pf.periodicity</div><div>(True, True, True)</div><div><br></div><div>Here, pf.periodicity is a tuple, from which one can read off that the simulation is periodic along all three directions.  We intend to fully support simulations that have arbitrary mixed periodic and isolated boundary conditions.  We will then use the new periodicity attribute to modify the places in the code where we need to worry about boundary conditions.</div><div><br></div><div>I've gone ahead and added the periodicity attribute for most of the code frontends.  I've also enhanced the Radius and ParticleRadius fields to properly handle the periodicity.  These modifications are included in Pull Request #410: <a href="https://bitbucket.org/yt_analysis/yt/pull-request/410/first-pass-at-ytep-6-closes-484">https://bitbucket.org/yt_analysis/yt/pull-request/410/first-pass-at-ytep-6-closes-484</a></div><div><br></div><div>At this point, the PR is more or less ready to go.  However, since this is a somewhat invasive change that might temporarily break code frontends if there is a bug somewhere, it would be great if some of you would check to make sure that everything works correctly for your datasets.  In particular, I need help figuring out how to set the periodicity for the orion, chombo (i.e. pluto and orion2), maestro, and nyx frontends.  It would also be great to hear from users who commonly work with 1D or 2D data, as these sorts of datasets have caused trouble in the past.</div><div><br></div><div>I'll also note that if you're interested in helping out with yt development, finishing up YTEP-0006 would be an excellent starter project.  If you run into trouble, please send a message to the yt-users or yt-dev mailing lists or, if you're looking for low-latency discussion, stop by on our IRC channel (#yt on freenode, or use the web chat interface: <a href="http://yt-project.org/irc.html">http://yt-project.org/irc.html</a>).</div><div><br></div><div>Cheers,</div><div><br></div><div>Nathan Goldbaum</div><div><br></div><div><br></div></body></html>