This HTML automatically generated with rman for NEMO
Table of Contents


rvstack - extract Radius-Velocity diagram from a data cube with selected



rvstack in=cube out=map [parameter=value]


rvstack takes all points within a (narrow) wedge around the major or minor axis of an assumed galaxy disk data cube, and stacks these data to construct a two-dimensional Radius-Velocity map, centered on the galaxy in position and velocity. The intent is to show the rotation curve along the major axis, or (Z-axis) outflow along the minor axis. If there is signal at negative velocities, either there are leading spiral arms, or there is inflow.

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.


The following parameters are recognized in order; they may be given in any order if the keyword is also given. Use --help to confirm this man page is up to date.
input data cube, in standard image(5NEMO) format. The third axis must be velocity, or at least match the units used in the vlsr= keyword below. [No default]
output R-V map. [No default]
position angle along which the wedge is taken. This is normally the major axis receding side (with mode=rotation) or the minor axis near side (for mode=outflow), in order get a positive velocity signal in the RV map. When gscale=t is set, will there be a difference how the radius and velocity are scaled.
inclination angle of the disk [45]
systemic velocity [0]
rotation center (in pixel units, where 0,0=lower left). If not supplied, the reference pixel will be used. Default: reference pixel.
full angle around the position angle pa= around which points are accumulated into the R-V plot. [Default: 10]
Value of the blank pixel to be ignored. [Default: 0.0]
Scaling factor for radius. This would be used to stack galaxies based on some physical (e.g. kpc) scaling, not geometry, see gscale= below. [Default: 1]
Scaling factor for velocity. This would be used to stack galaxies based on a mass scaling, not geometry, see gscale= below. [Default: 1]
A boolean if to scale for (inclination and position angle based) geometry. If selected, rotation is scaled by 1/sin(i), outflow by 1/cos(i). Radius is not scaled for rotation, but by 1/cos(i) for outflow. Small position angle in the disk plane ("theta") based corrections are also applied. [Default: f]
Select output mode: rotation (r) or outflow (o) . [Default: r]
By default it will stack both sides (0), but this option will allow you to stack one (1) or the other (-1) side. [Default: 0]
(debugging) write a test table. [Default: f]
Debugging spreading signal. Don’t use.


Code is still under developement, in particular dealing with units is unresolved.

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.


An example using our standard NGC 6503 cube given in km/s velocity units.

  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
  rvstack ngc6503_83.ccd rvmi_83.ccd pa=30  inc=75 vsys=27 center=129,128

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

See Also

ccdstack(1NEMO) , ccdzshift(1NEMO) , ccdmath(1NEMO) , image(5NEMO) , rotcur(5NEMO)



scripts/csh/mk_cone - example script to create PPV cubr of disk + conic
outflow along Z  (old 1983 VLA
https://...   (TBD - new data)


Peter Teuben

Update History

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

Table of Contents