-
Notifications
You must be signed in to change notification settings - Fork 11
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
1D analysis #159
1D analysis #159
Conversation
This should only be reviewed and merged after #195 is resolved, as that branch was pulled into this one. |
This is excellent!
I would be in favor of doing the converse, but we should have a broader discussion about core objects in the codebase. My reasoning is that the What types of data do you envision these routines to work on? I would think the |
Thanks! And yes that makes sense, I'm happy to change it to require less/no pre-processing for mpol model inputs. I was thinking of images generated by external software, like .fits obs or images from simulations, or observed / simulated visibilities. But it's equally easy to stuff those into cubes as it is to break mpol images out into numpy. |
@iancze I updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks great!
Adds utilities to obtain the 1d (radial) representation of:
- an image (such as that obtained from an MPoL model),
onedim.radialI
- a visibility distribution (such as that obtained from an MPoL model),
onedim.radialV
radialI
expects an image array rather than an ImageCube, andradialV
expects a set of 2D visibility amplitudes rather than a FourierCube. I did this to make the routines immediately accessible for generic numpy arrays, so a bit of preprocessing from cubes is required (if I'd done the converse, a bit of processing for numpy arrays would be required, and I thought it best to keep the functions in this slightly more general design).Note:
Adds
frank
as anEXTRA_REQUIRES
:tests
andanalysis
dependency.Todo:
radialI
radialV
(account for optically thick vs thin)Closes #189
This should only be reviewed and merged after #195 is resolved, as that branch was pulled into this one.