<div dir="ltr"><div><div><div><div><div>Hi Nathan,<br><br></div>I was in the process of reading in everyone on the yt-dev list when I received your message. Thanks! Also, thanks for taking a stab at the issue, I wasn't expecting that!<br><br></div>I like the morton index idea, in particular; it should be easier to implement and more robust than trying to allow for rounding error in cell position. <br></div><div><br></div>I've got limited time to work on this, but I'll see if I can make progress using the morton idea next week.<br><br></div>Cheers,<br></div>Jason<br><br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 1, 2016 at 8:05 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jason,<div><br></div><div>I'm CCing yt-dev here so that this project discussion happens in public. I hope that's ok.</div><div><br></div><div>Yes, it would be great if you could take a stab at this. Unfortunately the main blocker here is choosing a good, fast, periodic KDTree that can be used easily from within cython. Having this available would be great for many other things besides the CutRegionSelection. We in fact already have a copy of scipy's C KDTree implementation vendored inside yt that we'd like to get rid of. I believe there are plans to either add a dependency on or vendor a fast cython kdtree that Meagan Lang has been working on:</div><div><br></div><div><a href="https://bitbucket.org/langmm/cykdtree" target="_blank">https://bitbucket.org/langmm/<wbr>cykdtree</a></div><div><br></div><div>Earlier today I took a stab at implementing a naive O(N^2) search in CutRegionSelector.select_cell. Unfortunately it's very, very slow to do this so we're going to need some sort of acceleration in order to realistically accomplish this, either via .a tree approach or by using a hash search like we're currently doing via python's builtin set object.</div><div><br></div><div>An alternate way around this that maintains the O(1) speed of the current hashmap-based approach would be to compute unique integer indexes for each cell inside the cut_region and save those instead of just saving the floating point position of each cell. When I originally wrote the CutRegionSelector there wasn't anything like that in yt, but since then we've added a way to compute morton indices for each cell, which should do the trick.</div><div><br></div><div>In fact, I went ahead and took a stab at this after coming up with that idea while writing this e-mail:</div><div><br></div><div><a href="https://bitbucket.org/yt_analysis/yt/pull-requests/2405" target="_blank">https://bitbucket.org/yt_<wbr>analysis/yt/pull-requests/2405</a></div><div><br></div><div>And unfortunately it still doesn't work perfectly - I still see artifacts (although they're less severe) in the image produced by the test script in the issue.</div><div><br></div><div>I think my attempt in PR 2405 might be going on the right track - you could try to poke around with it, or test it with your data.</div><div><br></div><div>Sorry to not have a satisfactory answer here. I was very excited about initially being able to implement cut_region data sources for SlicePlots, but the issue with FLASH data has been an annoying thorn in my side for a while, it would be great if we could figure out a way to fix it once and for all.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Nathan</div></font></span><div><div class="h5"><div><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 1, 2016 at 4:27 PM, Jason Galyardt <span dir="ltr"><<a href="mailto:jason.galyardt@gmail.com" target="_blank">jason.galyardt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>Hi Nathan,<br><br></div>Unfortunately, contours won't be enough for me -- I need the actual data region to do analysis on the gas contained within (i.e. more than visualization). I'm not very familiar with the yt codebase, but I'd like to see whether it's worth my time to work on this issue. I'm not very familiar with the yt codebase or Cython, but my programming skills are decent; how much work do you think this would take? Could I use an existing KDTree library, such as the one in SciPy or <a href="https://github.com/jtsiomb/kdtree" target="_blank">this C implementation</a><code>? <br><br></code></div><code>Thanks,<br></code></div><code>Jason<br></code><div><div><code><br></code></div></div></div><div class="m_1679657566851366079gmail-HOEnZb"><div class="m_1679657566851366079gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 1, 2016 at 3:44 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jason,<div><br></div><div>Unfortunately no. I think I might be able to come back to this issue soonish, we're going to be introducing a new fast periodic KDTree which could be exploited here.</div><div><br></div><div>For now I think you're<span></span> going to need to make this plot in a different way, without using a cut_region. Perhaps by overplotting contours?</div><span class="m_1679657566851366079gmail-m_-2056896066610442086HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="m_1679657566851366079gmail-m_-2056896066610442086HOEnZb"><font color="#888888">Nathan</font></span><div><div class="m_1679657566851366079gmail-m_-2056896066610442086h5"><br><br>On Saturday, October 1, 2016, Jason Galyardt <<a href="mailto:jason.galyardt@gmail.com" target="_blank">jason.galyardt@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Nathan,<br><br></div><div>Is there a previous version of yt in which compound cut regions work?<br><br></div><div>Thanks,<br></div><div>Jason<br></div><div><div><div><br>-----<br><br><div dir="ltr">Hi Jason,<div><br></div><div>This is a known issue:</div><div><br></div><div><a href="https://bitbucket.org/yt_analysis/yt/issues/941/cutregionselector-doesnt-work-with-some" target="_blank">https://bitbucket.org/yt_analy<wbr>sis/yt/issues/941/cutregionsel<wbr>ector-doesnt-work-with-some</a><br></div><div><br></div><div>Unfortunately
 fixing it will require a modification to the cut_region implementation 
to do a better job of searching for cells that belong to the region for 
chained selectors.</div><div><br></div><div>-Nathan</div></div><br>On Fri, Sep 30, 2016 at 1:25 PM, Jason Galyardt <span dir="ltr"><<a>jason.galyardt@gmail.com</a>></span> wrote:<br><div><div><div><div><div>Dear all,<br><br></div>I
 would like to generate a compound cut region for a FLASH simulation, 
but the output I'm getting is odd. I've pasted my simple script here:<br><br><a href="http://paste.yt-project.org/show/6839/" target="_blank">http://paste.yt-project.org/sh<wbr>ow/6839/</a><br><br></div>It
 loads a simulation file, creates a compound cut_region (1e4 K < T 
< 1e6 K), and applies it to a slice plot. The resulting image is 
banded, as you can see by the attached plots. Am I missing something, or
 is this a problem related to yt?<br><br></div>FYI, I get the same 
behavior when I use a projection plot or only one of the conditionals 
(e.g. T < 1e6 K). I've tried both the stock 3.3.1 version, as well as
 the self-contained development version that I installed earlier this 
afternoon using install_script.sh. Let me know if any other info is 
useful.<br><br></div>Cheers,<br></div>Jason<br><br></div></div></div></div>
</blockquote></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>