richteague / gofish Goto Github PK

Hi @richteague,

There is an issue (or my misunderstanding) with a teardrop plot extent. The extent keyword in the matplotlib's imshow sets the location of the image borders, not the location of the image corner pixels' centers.

In your case, rvals are the locations of the bin centers, right? For example, the can be:

 2.01438614 2.3242917  2.63419726 2.94410282 3.25400838 3.56391393
 3.87381949 4.18372505 4.49363061 4.80353617 5.11344173 5.42334729
 5.73325285 6.04315841 6.35306397 6.66296953 6.97287509 7.28278065 

That namely means that the pixel centers are (I will round) 0.15, 0.45, 0.75, ..., with a pixel size 0.3. In this case, the desired extent in the radial coordinate will be from the first rval - 0.15 to the last rval + 0.15.

If you want to keep imshow, the extent should be changed to:

velstep = velax[1] - velax[0]
rstep = rvals[1] - rvals[0]
extent = [velax[0] - velstep / 2, velax[-1] + velstep / 2, 
          rvals[0] - rstep / 2, rvals[-1] + rstep / 2]

The corresponding tutorial: https://matplotlib.org/3.1.1/tutorials/intermediate/imshow_extent.html

I would propose though to use the method pcolormesh, as it also can handle not-uniform coordinate steps. (shading='gourand') can be used if the coordinates are left as is, or the coordinates can be rewritten to correctly match the edges of the pixels.

https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.pyplot.pcolormesh.html

Best,
Greg

Seems like the keyword "rvals" given to _keplerian inside the shifted_cube function is invalid; shouldn't it be rpnts?

The method _readpositionaxis reads the CRPIX value from the fits image header, but it does not use it. Instead, the origin of the axis is assigned to the middle pixel.
Not sure if it is a good idea to actually use the CRPIX value, but if it's not used, it shouldn't be read. Also, I couldn't find an explicit mention in the documentation that the center of the disk is assumed to equal the central pixel of the image (if x0 and y0 are set to 0).

In the function _readpositionaxis, the variable a_ref is assigned the value of the crval from the fits header, but in the next line, a_ref is assigned to 0. So reading crval from the header seems unnecessary.

Currently the function will ignore all other mask parameters (r_min, r_max, etc.) if mask is provided, while other functions (at least average_spectrum) will combine these masks.

In the API of gofish.imagecube (https://fishing.readthedocs.io/en/latest/user/api.html), the parameter clip is not described. Moreover, the parameter velocity_range is described as v_range in the doc string.

In some cubes the xaxis attribute is flipped relative to what GoFish expects (it wants xaxis to decrease with index). This causes issues when trying to cut down to a sub-cube based on the FOV argument. A simple work around now is just to avoid the FOV argument.

Hi @richteague,

I found an issue with the PA of the beam that is used when convolving the keplerian mask. In convolve_with_beam() the beam PA (in degrees) is passed along to astropy.convolution.Gaussian2DKernel, which expects a rotation angle in radians (at least in astropy 5.1.1: https://docs.astropy.org/en/stable/api/astropy.convolution.Gaussian2DKernel.html).
I fixed it by replacing theta=self.bpa with theta=np.deg2rad(self.bpa) , but any similar conversion would do the trick.

Cheers,
Leon

There is a typo at