Non-profile galaxies run on CPU only

[craigwarner-ufastro]

There are times when profile galaxy is False and it is run on CPU. This happens 925 times in the sub-brick compared to 2010 where the GPU code is called. Weirder still, if I return [] in these examples (thinking I could remove them for speed testing purposes), we now have 2584 times the GPU code is called.

        if not (tr.isParamFrozen('images') and
                (len(tr.catalog) == 1) and
                isinstance(tr.catalog[0], ProfileGalaxy)):
            fname = "bad_nonprofile.pickle"
            if not os.access(fname, os.F_OK):
              f = open(fname,'wb')
              import pickle
              pickle.dump(tr, f)
              f.close() 
            if self._gpumode >= 10:
                print ("Skipping non-profile galaxy")
                return []
            print ("Running CPU version, frozen = ", tr.isParamFrozen('images'), "len = ", len(tr.catalog), " profile = ", isinstance(tr.catalog[0], ProfileGalaxy))
            #p = self.ps
            #self.ps = None
            t = time.time()
            R = super().getSingleImageUpdateDirections(tr, **kwargs)
            tt[0] += time.time()-t
            tct[0] += 1
            #self.ps = p
            return R

Line 208 in factored_optimizer.py. If I use a _gpumode > 10 then I return [] rather than calling R = super().getSingleImageUpdateDirections(tr, **kwargs). I do not understand why returning [] rather than calling the CPU code results in the GPU code being called 574 additional times.

Additionally, in line 131 of factored_optimizer.py, in getLinearUpdateDirection we have a block

        if image_thawed:
            tct[6] += 1
            cat_frozen = tr.isParamFrozen('catalog')
            if not cat_frozen:
                tr.freezeParam('catalog')
            x_imgs = super().getLinearUpdateDirection(tr, **kwargs)

[dstndstn]

I believe this in when the point-source models are getting fit --

the derivative-getting code for point sources is here,
https://github.com/dstndstn/tractor/blob/main/tractor/pointsource.py#L168

and the overall process is going to be the same - filling up the A matrix column with derivatives, but the only derivatives will be the positions and brightness -- eg https://github.com/dstndstn/tractor/blob/craig_factored_merge/tractor/factored_optimizer.py#L1301

it might work to use the same code path, with img_derivs only containing the current position and no derivatives.

What will be different is the part that computes the mod0 -- instead of the FFT or MoG galaxy rendering that produces G, this will simply take a pixel-space representation of the PSF (the PSF image that we take the FFT of for the FFT method), and do the sub-pixel lanczos shift on it.

That's a terse description, I'm happy to expand that explanation as needed!