More fun with the all-sky HI data... sort of.
Recently I posted what the data looks like if you assume velocity is the same as distance. Of course it isn't really, but transforming it into true distance isn't so easy.
The data from the telescope consists of maps of the sky each one at a slightly different line-of-sight velocity. Knowing the position and velocity of each point in the map, it's possible to convert this into distance with some fairly ugly trigonometry.
There are some intrinsic limitations to this that can't be avoided. For instance, if the gas is closer to the centre of the Galaxy than the Sun, the equations give two equally valid solutions and there's no easy way to decide which is correct. So that data has to be chucked out. Another is that if you've looking directly towards or away from the Galactic centre, you don't get meaningful velocity information - we can only measure velocity along our line of sight, but at those angles gas is moving entirely across the sky except for some small random motions. So data at angles close to the centre and anti-centre needs to be thrown out too.
Then there's the problem of how to display the data. Previously I tried to convert the raw velocity cube to a distance cube by applying the equations to each pixel in the original data. So knowing position, velocity and intensity of any point gives a corresponding position, distance and intensity in the new data cube.
This creates an extra problem. Although the original data is fully sampled (that is, each map of the sky at each velocity channel is complete - every pixel has measured values), that isn't automatically the case for the output distance cube. To simplify, imagine that position x,y corresponds to i,j in the new data set. The problem is essentially that position x+1,y+1 corresponds to something like i+2,j+2 - there are gaps. You could try interpolating the missing values, but it's not so easy - and you still lose data, because in some regions in turns out that multiple points in the original coordinates correspond to the same point in the new coordinates. You need the resolution to be adaptive.
Which is where this funky geometry comes in. What we have here are a series of planes in Blender, each one corresponding to a different velocity channel. By transforming the vertices to the corresponding distance, the faces between them automatically interpolate the missing regions. The animation just overlays each successive velocity channel converted into distance.
.... or at least that's the idea. I'm really not sure if this is working correctly. The funky shape might be a consequences of the non-trivial equations, or I might have set something wrong. It's very hard to visualise what the equations look like in 3D, which is what this is supposed to help with. This requires further thought, but it's quite nice to watch (the flickering dark shadows are Blender rendering artifacts).
It is
ReplyDelete