Issue #941: CutRegionSelector doesn't work with some data types (yt_analysis/yt)
New issue 941: CutRegionSelector doesn't work with some data types https://bitbucket.org/yt_analysis/yt/issue/941/cutregionselector-doesnt-work...
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()
```
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
Instead use an integer index field? Most frontends probably already have them, and those that don't should be encouraged...
Douglas Rudd Scientific Computing Consultant Research Computing Center drudd@uchicago.edu
On Nov 21, 2014, at 3:09 AM, Nathan Goldbaum issues-reply@bitbucket.org wrote:
New issue 941: CutRegionSelector doesn't work with some data types https://bitbucket.org/yt_analysis/yt/issue/941/cutregionselector-doesnt-work...
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()
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:
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.
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 _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Fri, Nov 21, 2014 at 8:20 AM, Douglas Harvey Rudd drudd@uchicago.edu wrote:
Instead use an integer index field? Most frontends probably already have them, and those that don't should be encouraged...
That's the trouble - there isn't an integer index field.
Douglas Rudd Scientific Computing Consultant Research Computing Center drudd@uchicago.edu
On Nov 21, 2014, at 3:09 AM, Nathan Goldbaum issues-reply@bitbucket.org
wrote:
New issue 941: CutRegionSelector doesn't work with some data types
https://bitbucket.org/yt_analysis/yt/issue/941/cutregionselector-doesnt-work...
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()
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:
- 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.
- 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 _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (3)
-
Douglas Harvey Rudd -
Nathan Goldbaum -
Nathan Goldbaum