stacking
By default it will stack the two sides of the galaxy (see also side=), so the radial coordinate will run from 0 to some Rmax, and in velocity it will run from some -Vmax to Vmax. This is done in such a way as to expect positive rotation around the Z-axis, or a positive outflow along the Z axis. For this the position angle (pa=) has been correctly set to the major axis / receding side for rotation, and minox axis / receding (near) side for outflow.
Weak signal rotation and/or bulk outflow could be detected this way, but we offer no guarentee! If you have many like-minded galaxies, stacking these images may beat the noise down even more. For subsequent stacking ccdstack(1NEMO) will need to be used.
Options exist to scale the Radius and Velocity to different units, such that objects can be stacked in a physical space, as opposed to observed space. See rscale= and vscale=.
When
gscale=t is set, the coordinates are geometrically corrected as well, as
follows:
Rotation Outflow -------- --------- R R/sin(inc) V/sin(inc)/cos(theta) V/cos(inc)where theta is the position angle away from the major axis in the plane of the galaxy. The radius R has been corrected for this as well. This can leave some gaps in radius and velocity. See CAVEATS below.
Points along an arc are all accumulated (technically: averaged), and placed on the same radial grid as the pixel size in the input data cube. We might need some trick next neighbor smoothing in order for pixels near the center to have a value.
A wedge has the disadvantage the the noise decreases inversely proportional to the sqrt(radius), but has a matched-filter approach to a conic outflow. An alternative would be to have an option for angle= to be replaced with width=.
The gaps in radius and/or velocity produced with gscale=t can be a nuisance. For stacking many images, for example using ccdstack(1NEMO) , this should disappear, but otherwise some smoothing/interpolation might be needed. Not implemented.
Outflow is hard-coded as outflow along the Z axis. What should the off-axis relationship be? Conical? No theta correction applied here, as we don’t have a model like we have for rotation.
rvstack ngc6503.ccd rvma.ccd pa=-60 inc=75 vsys=27 center=164,123 rscale=3600 rvstack ngc6503.ccd rvmi.ccd pa=30 inc=75 vsys=27 center=164,123 rscale=3600 rvstack ngc6503_83.ccd rvma_83.ccd pa=-60 inc=75 vsys=27 center=129,128 rscale=3600 rvstack ngc6503_83.ccd rvmi_83.ccd pa=30 inc=75 vsys=27 center=129,128 rscale=3600
Here is an example made with mk_cone
$NEMO/scripts/csh/mk_cone out=cone2 rmin=0 vscale=0 outflow=0.5 cone=10 flow=rise noise=1
https://github.com/jbjolly/LineStacker
src/image/rotcur/rvstack.c scripts/csh/mk_cone - example script to create PPV cubr of disk + conic outflow along Z https://www.cv.nrao.edu/fits/data/samples/cubes/ngc6503.fits (old 1983 VLA data) https://... (TBD - new data)
6-may-2021 V0.4 First working version PJT 31-may-2021 V0.7 better geometry correction PJT 3-jun-2021 V0.8a clarify near/far side choice PJT