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

Reintroduce Perley-Polyhedron Gridder #222

Merged
merged 7 commits into from
Sep 23, 2020

Conversation

bennahugo
Copy link
Collaborator

Reverts #220

@bennahugo bennahugo added the wip Work in progress label Sep 23, 2020
@bennahugo
Copy link
Collaborator Author

Need to try and undo the mess created by the revert. I will be basing off this branch to make the necessary workaround for the numba 0.5 bug

@bennahugo bennahugo marked this pull request as draft September 23, 2020 08:55
@o-smirnov
Copy link
Contributor

Nothing like a revert of a revert to pervert one's brain!

@sjperkins
Copy link
Member

@bennahugo Would you not prefer to work from #219 whose point was to retain the state of the PR prior to the revert?

@sjperkins
Copy link
Member

Whatever works though, this has green lights on the test suite.

@bennahugo
Copy link
Collaborator Author

@sjperkins that has rather large changes with SanitaryLiterals. I think the issue is not in the use of SanitaryLiterals but in the way the new numba compiler handles literals. It seems you cannot create a stack of nested literals in a jit function called by another jit function. All literally calls must take place in the first jit function the compiler encounters on the stack, so I strongly suspect this is a compiler bug in numba >=0.5

@sjperkins
Copy link
Member

@sjperkins that has rather large changes with SanitaryLiterals. I think the issue is not in the use of SanitaryLiterals but in the way the new numba compiler handles literals. It seems you cannot create a stack of nested literals in a jit function called by another jit function. All literally calls must take place in the first jit function the compiler encounters on the stack, so I strongly suspect this is a compiler bug in numba >=0.5

All good!

@sjperkins
Copy link
Member

I think the numba version needs changing in the setup.py?

@bennahugo
Copy link
Collaborator Author

woops sorry you are right. I only upgraded locally

@sjperkins
Copy link
Member

Well that was easy enough! Green lights. Let me give it a quick once over, unless there's more you wish to do?

@bennahugo
Copy link
Collaborator Author

Sure go ahead. The issue is simplified to the simplest possible reproducer that mimics this issue in numba/numba#6274

@sjperkins
Copy link
Member

@bennahugo I'm a bit confused. Were you intending to post this on the related issue #219?

This is the PR reintroducing the gridder.

@sjperkins
Copy link
Member

Happy to review though.

@bennahugo
Copy link
Collaborator Author

@bennahugo I'm a bit confused. Were you intending to post this on the related issue #219?

This is the PR reintroducing the gridder.

No, I just mentioned the post where I've reproduced the workaround for compiler bug that causes the failure on numba version 0.51.2 in a simpler case if you wanted to comment

@sjperkins
Copy link
Member

@bennahugo I'm a bit confused. Were you intending to post this on the related issue #219?
This is the PR reintroducing the gridder.

No, I just mentioned the post where I've reproduced the workaround for compiler bug that causes the failure on numba version 0.51.2 in a simpler case if you wanted to comment

Ah! I'll take a look at that too.

@sjperkins sjperkins self-requested a review September 23, 2020 11:33
@bennahugo bennahugo marked this pull request as ready for review September 23, 2020 11:42
Copy link
Member

@sjperkins sjperkins left a comment

Choose a reason for hiding this comment

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

Some minor nits, but otherwise this is good to go.

HISTORY.rst Outdated
@@ -6,6 +6,8 @@ History
------------------
* Add wrapper for ducc0.wgridder (:pr:204`)
* Correct Irregular Grid nesting in BeamAxes (:pr:`217`)
* Add Perley Polyhedron Faceting Gridder/Degridder (:pr:`202`, :pr:`215`)
Copy link
Member

Choose a reason for hiding this comment

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

Could you start a new version section in the changelog that also mentions this PR? e.g.:

0.2.7 (YYYY-MM-DD)
----------------------------
* Add Perley Polyhedron Faceting Gridder/Degridder (:pr:`202`, :pr:`215`, :pr:`222`)

with a modification of higher order bessels as default, as
this improves the kernel at low number of taps.
"""
autocoeffs = np.polyfit(
Copy link
Member

Choose a reason for hiding this comment

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

Could the definition of this be moved outside the kbsinc function?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Don't think so it is specific for the function (the coefficents are not the same - see the original Jackson paper).

Copy link
Member

Choose a reason for hiding this comment

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

Ok, but you could have _kb_coeffs and _hanning_coeffs globals, for instance. They're constant and private by convention.

autocoeffs = np.polyfit([1.5, 2.0, 2.5, 3.0, 3.5],
[0.7600, 0.7146, 0.6185, 0.5534, 0.5185], 3)
if a is None:
a = np.poly1d(autocoeffs)((W + 2))
Copy link
Member

Choose a reason for hiding this comment

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

Similarly to kbsinc, could the autocoeffs be moved outside?

return res / np.sum(res)


def hanningsinc(W, a=0.5, oversample=5):
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't None be the default value for a?

Suggested change
def hanningsinc(W, a=0.5, oversample=5):
def hanningsinc(W, a=None, oversample=5):

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

well spotted yes will fix

nchan = 128
frequency = da.from_array(np.linspace(1.0e9, 1.4e9, nchan),
chunks=(nchan, ))
wavelength = 299792458.0 / frequency
Copy link
Member

Choose a reason for hiding this comment

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

It's possible to use the lightspeed definition from constants

from africanus.constants import c as lightspeed

pxacrossbeam = 10
nchan = 1024
frequency = np.array(np.linspace(1.0e9, 1.4e9, nchan))
wavelength = np.array([299792458.0 / f for f in frequency])
Copy link
Member

Choose a reason for hiding this comment

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

The np.array and list comprehensions aren't strictly necessary:

from africanus.constants import c as lightspeed

frequency = np.linspace(1.0e9, 1.4e9, nchan)
wavelength = lightspeed / frequency

pxacrossbeam = 10
nchan = 1024
frequency = np.array(np.linspace(1.0e9, 1.4e9, nchan))
wavelength = np.array([299792458.0 / f for f in frequency])
Copy link
Member

Choose a reason for hiding this comment

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

The np.array and list comprehensions aren't strictly necessary:

from africanus.constants import c as lightspeed

frequency = np.linspace(1.0e9, 1.4e9, nchan)
wavelength = lightspeed / frequency

pxacrossbeam = 10
nchan = 16
frequency = np.array(np.linspace(1.0e9, 1.4e9, nchan))
wavelength = np.array([299792458.0 / f for f in frequency])
Copy link
Member

Choose a reason for hiding this comment

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

The np.array and list comprehensions aren't strictly necessary:

from africanus.constants import c as lightspeed

frequency = np.linspace(1.0e9, 1.4e9, nchan)
wavelength = lightspeed / frequency

@sjperkins
Copy link
Member

@bennahugo One final request: Could you rename the lambdas arguments to wavelengths in the gridder and degridder calls? I think its more explicit.

@bennahugo
Copy link
Collaborator Author

Fixes the issues raised apart from the coefficients which are function specific so I don't think they should be moved outside the function?? uvlambda is a common expression for stating uv measured in lambda - which is what was meant in the gridder interface. I've changed it though

@sjperkins sjperkins changed the title Revert "Revert perley polyhedron gridder" Reintroduce Perley-Polyhedron Gridder Sep 23, 2020
@sjperkins sjperkins merged commit 5224520 into master Sep 23, 2020
@sjperkins sjperkins deleted the revert-220-revert-perley-polyhedron-gridder branch September 23, 2020 13:18
@sjperkins
Copy link
Member

Squashed into master. I'm very glad this is now in!

I'm aiming to push a release out today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wip Work in progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants