Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Wiring frb buffers with plot_window #1877

Closed
wants to merge 26 commits into from

Conversation

cphyc
Copy link
Member

@cphyc cphyc commented Jul 3, 2018

PR Summary

This wires the FixedResolutionBuffer objects to their parent plot_window (if any) so that the addition of a filter results in the invalidation of the plot window.

The PR also modified the apply_gauss_beam filter to use https://docs.scipy.org/doc/scipy-0.16.1/reference/generated/scipy.ndimage.filters.gaussian_filter.html.

PR Checklist

  • Code passes flake8 checker
  • New features are documented, with docstrings and narrative docs
  • Adds a test for any bugs fixed. Adds tests for new features.

Example script

import yt
from yt.testing import fake_amr_ds

ds = fake_amr_ds(fields=["density", "temperature"])

fields = ['density', 'temperature']
p = yt.SlicePlot(ds, 'x', fields)
p.save('/tmp/', suffix='unsmoothed')

p.frb.apply_gauss_beam(sigma=10) # pixels
p.save('/tmp/', suffix='smoothed')

p.frb.apply_white_noise()
p.save('/tmp/', suffix='smoothed+whitenoise')

amrgriddata_slice_x_temperature unsmoothed
amrgriddata_slice_x_temperature smoothed
amrgriddata_slice_x_temperature smoothed whitenoise

amrgriddata_slice_x_density unsmoothed
amrgriddata_slice_x_density smoothed
amrgriddata_slice_x_density smoothed whitenoise

@cphyc cphyc requested a review from ngoldbaum July 3, 2018 22:02
@cphyc
Copy link
Member Author

cphyc commented Jul 3, 2018

There is a lot of room for improvement in this PR and I don't really like the way it is wired now, because the frb should in principle be independent of the plot window.

One way to improve that would be to expose the frb-bound filters at the plot window level, and invalidate the data and call the subsequent frb filter from the plot window instead of relying on the filter to invalidate the data.

# We need to invalidate the data to force the plot window to
# take the filter into account.
if frb.plot_window:
frb.plot_window._data_valid = False
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if FixedResolutionBuffer instances had a _data_valid attribute. We would need to refactor PlotWindow to store that state on the frb attribute but I think it would be a straightforward refactor.

self.data = {}
FixedResolutionBuffer.__init__(self, data_source, bounds, buff_size,
antialias, periodic)
super(ParticleImageBuffer, self).__init__(*args, **kwargs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explicitly pass the arguments?

@@ -555,11 +554,9 @@ class ParticleImageBuffer(FixedResolutionBuffer):
buffer.

"""
def __init__(self, data_source, bounds, buff_size, antialias=True,
periodic=False):
def __init__(self, *args, **kwargs):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we explicitly list the arguments?

@@ -240,6 +240,7 @@ def fget(self):
def fset(self, value):
self._frb = value
self._data_valid = True
self._plot_valid = False
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is used anywhere

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is at line 751 of the same file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see, this is a good cleanup then. Sorry for not looking at the whole file, just the diff.

@@ -665,6 +667,9 @@ def __init__(self, *args, **kwargs):
self._splat_color = kwargs.pop("splat_color", None)
PlotWindow.__init__(self, *args, **kwargs)

def data_is_valid(self):
return self._data_valid and self._frb and self._frb._data_valid
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that you've refactored everything into this function, do you think we need both _data_valid and frb._data_valid? Can't we just use frb._data_valid and get rid of the attribute on the plot itself?

I also like to make helpers like this properties so you don't need to append the () every time you use them.

@ngoldbaum
Copy link
Member

Awesome, the latest version is much cleaner!

@cphyc cphyc changed the title [WIP] [Feature] Wiring frb buffers with plot_window [Feature] Wiring frb buffers with plot_window Jul 6, 2018
@cphyc cphyc force-pushed the feature/smoothing branch from 8935c1b to 0e2e8fb Compare July 7, 2018 13:31
@cphyc cphyc mentioned this pull request Jul 8, 2018
3 tasks
@@ -777,3 +777,21 @@ Overplot the Path of a Ray
p.annotate_ray(oray)
p.annotate_ray(ray)
p.save()


Operating on the final image
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would call this "applying filters"

yt/visualization/fixed_resolution_filters.py Show resolved Hide resolved
@@ -659,6 +667,10 @@ def __init__(self, *args, **kwargs):
self._splat_color = kwargs.pop("splat_color", None)
PlotWindow.__init__(self, *args, **kwargs)

@property
def data_is_valid(self):
return self._data_valid and self._frb and self._frb._data_valid
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I commented on this before and I don't think you responded - can you explain why we need both plot._data_valid and _frb._data_valid? I'd prefer to only store this state in one place if possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the code removing plot._data_valid, let's see if the test pass.

@ngoldbaum ngoldbaum mentioned this pull request Jul 10, 2018
@cphyc
Copy link
Member Author

cphyc commented Jul 10, 2018

The logic behind _data_valid is somewhat broken, essentially because it was centered on the plot even though it should be centered on the FixedResolutionBuffer. I think we can either leave it as is (so with a plot._data_valid and a plot._frb._data_valid attributes) and open an issue to clean all this or start a more massive refactoring that will put the data validation steps onto the frb.

@ngoldbaum
Copy link
Member

OK, fair enough. I guess back out that last change? I will try to take a look at this this week sometime and see if there's a way to clean this up. Would you be ok with me pushing directly to this branch?

@cphyc
Copy link
Member Author

cphyc commented Jul 10, 2018

@ngoldbaum it would indeed be enough to revert c3ef894 and 4cead9d and I'm fine with you pushing directly on the branch.

@matthewturk matthewturk added the triage Triage needed label Mar 6, 2019
@matthewturk
Copy link
Member

@cphyc Other than the merge conflict, is this ready to go? I realize it's been a long time.

@matthewturk
Copy link
Member

@cphyc Hey, what do you think about this?

@cphyc
Copy link
Member Author

cphyc commented Mar 30, 2020

I think this is ready to go. I remember having to think thoroughly to make sense of the logic behind the validation process (which would likely require need to be refactored). Let me trigger the tests to check that.

@cphyc
Copy link
Member Author

cphyc commented Mar 30, 2020

@yt-fido test this please.

Copy link
Member

@neutrinoceros neutrinoceros left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some minor comments, obviously this has already been refined a lot and overall it looks great, I would love if we could get this merged for the 4.0 release.
The only change I wish to request is about the gaussian filter refactor and deprecation.

yt/visualization/tests/test_filters.py Outdated Show resolved Hide resolved
yt/visualization/tests/test_filters.py Show resolved Hide resolved
yt/visualization/tests/test_filters.py Show resolved Hide resolved
yt/visualization/tests/test_filters.py Show resolved Hide resolved
doc/source/visualizing/callbacks.rst Outdated Show resolved Hide resolved
yt/visualization/fixed_resolution_filters.py Outdated Show resolved Hide resolved
yt/visualization/fixed_resolution_filters.py Outdated Show resolved Hide resolved
yt/visualization/plot_container.py Outdated Show resolved Hide resolved
@neutrinoceros neutrinoceros added yt-4.0 feature targeted for the yt-4.0 release new feature Something fun and new! viz: 2D and removed triage Triage needed labels Jun 18, 2020
@cphyc cphyc force-pushed the feature/smoothing branch from 6b5cb7f to 275ba01 Compare September 1, 2020 12:43
@cphyc cphyc closed this Feb 15, 2022
@cphyc cphyc deleted the feature/smoothing branch February 15, 2022 13:39
chrishavlin added a commit that referenced this pull request May 2, 2022
ENH: expose FRB filtering API (remake #1877)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature Something fun and new! viz: 2D
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants