[yt-dev] Issue #941: CutRegionSelector doesn't work with some data types (yt_analysis/yt)

Nathan Goldbaum issues-reply at bitbucket.org
Fri Nov 21 01:09:07 PST 2014


New issue 941: CutRegionSelector doesn't work with some data types
https://bitbucket.org/yt_analysis/yt/issue/941/cutregionselector-doesnt-work-with-some

Nathan Goldbaum:

It turns out the `CutRegionSelector` I recently added doesn't work so well for FLASH data:


```
#!python

import yt

ds = yt.load("GasSloshing/sloshing_nomag2_hdf5_plt_cnt_0150")

dd = ds.all_data()
dd = dd.cut_region("obj['density'] > 1e-27")

slc = yt.SlicePlot(ds, 2, 'density', data_source=dd)
slc.set_zlim('density', 1e-30, 1e-25)
slc.set_figure_size(5)
slc.save()

```

![sloshing_nomag2_hdf5_plt_cnt_0150_Slice_z_density.png](https://bitbucket.org/repo/BXbAb/images/3572484347-sloshing_nomag2_hdf5_plt_cnt_0150_Slice_z_density.png)

This is happening because `CutRegionSelector` is using a fragile exact comparison between floats. It does this to take advantage of an efficient hashing algorithm, but it looks like this comes at the cost of maintaining bitwise identicality between two different ways of calculating cell positions.

The fix is either:

1. Figure out why the FLASH cell position fields are not bitwise identical to the cell positions calculated inside `SelectorObject.fill_mask`.  It seems Enzo data is unaffected by the round-off artifacts we see with FLASH data, so we know that means it is possible to rely on the cell positions matching exactly at some level.

2. Use a more forgiving data structure to retrieve matching cell positions.  A KD-tree seems like a natural choice, but I'm unsure if there's a ready-to-use KD-tree library available.

Responsible: ngoldbaum



More information about the yt-dev mailing list