[yt-dev] Cut Region Failure

Jason Galyardt jason.galyardt at gmail.com
Sat Oct 1 17:33:26 PDT 2016


Hi Nathan,

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!

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.

I've got limited time to work on this, but I'll see if I can make progress
using the morton idea next week.

Cheers,
Jason



On Sat, Oct 1, 2016 at 8:05 PM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

> Hi Jason,
>
> I'm CCing yt-dev here so that this project discussion happens in public. I
> hope that's ok.
>
> 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:
>
> https://bitbucket.org/langmm/cykdtree
>
> 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.
>
> 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.
>
> In fact, I went ahead and took a stab at this after coming up with that
> idea while writing this e-mail:
>
> https://bitbucket.org/yt_analysis/yt/pull-requests/2405
>
> 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.
>
> 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.
>
> 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.
>
> -Nathan
>
> On Sat, Oct 1, 2016 at 4:27 PM, Jason Galyardt <jason.galyardt at gmail.com>
> wrote:
>
>> Hi Nathan,
>>
>> 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 this C implementation
>> <https://github.com/jtsiomb/kdtree>?
>>
>> Thanks,
>> Jason
>>
>>
>> On Sat, Oct 1, 2016 at 3:44 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>>
>>> Hi Jason,
>>>
>>> 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.
>>>
>>> For now I think you're going to need to make this plot in a different
>>> way, without using a cut_region. Perhaps by overplotting contours?
>>>
>>> Nathan
>>>
>>>
>>> On Saturday, October 1, 2016, Jason Galyardt <jason.galyardt at gmail.com>
>>> wrote:
>>>
>>>> Hi Nathan,
>>>>
>>>> Is there a previous version of yt in which compound cut regions work?
>>>>
>>>> Thanks,
>>>> Jason
>>>>
>>>> -----
>>>>
>>>> Hi Jason,
>>>>
>>>> This is a known issue:
>>>>
>>>> https://bitbucket.org/yt_analysis/yt/issues/941/cutregionsel
>>>> ector-doesnt-work-with-some
>>>>
>>>> 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.
>>>>
>>>> -Nathan
>>>>
>>>> On Fri, Sep 30, 2016 at 1:25 PM, Jason Galyardt <
>>>> jason.galyardt at gmail.com> wrote:
>>>> Dear all,
>>>>
>>>> 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:
>>>>
>>>> http://paste.yt-project.org/show/6839/
>>>>
>>>> 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?
>>>>
>>>> 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.
>>>>
>>>> Cheers,
>>>> Jason
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20161001/de0e234b/attachment-0001.htm>


More information about the yt-dev mailing list