ratt-ru / CubiCal

A fast radio interferometric calibration suite.
GNU General Public License v2.0
18 stars 13 forks source link

Add "mixed" precision mode #173

Open o-smirnov opened 6 years ago

o-smirnov commented 6 years ago

In the interest of conserving memory, data and model visibilities should be kept in float32 precison, while gains, accumulated terms (J^H.R, J^H.J), and updates should be float64.

o-smirnov commented 6 years ago

Putting this one on the backburner. Cython is just smart enough to handle mixed-type kernels.

See "Fused types and arrays" here: http://cython.readthedocs.io/en/latest/src/userguide/fusedtypes.html. So definining two complex3264 fused types (to get an outer product of variations to be generated) works for memory views, but not for e.g. inlines like:

cdef inline void mat_product_gm(complex3264 * out,const complex3264a *g,const complex3264 *m) nogil:

And replacing one of the arguments with a non-fused type doesn't work, either -- it doesn't know how to multiply e.g. float complex by complex3264. All very annoying.

The way forward may be to stop using fused types entirely, and rewrite all kernels in terms of mixed precision (i.e. single for data/model/JH, double for all else), but I don't have the energy for that now. I'll commit my initial hacks to the branch and leave it for now.

JSKenyon commented 6 years ago

Just commenting here so that I do not forget what I figured out. Fused types cannot be declared as constants unless it happens in the definition of the fused type itself. See this issue. I think the way to get it working for now is to remove constant declarations and define two similar fused types:

ctypedef fused mcmplx1:
    np.complex64_t
    np.complex128_t

ctypedef fused mcmplx2:
    np.complex64_t
    np.complex128_t

This is due to the issue mentioned in @o-smirnov's post above.