Spergel stepk has two powers of the scale radius

[beckermr]

It appears that galsim has two factors of r0 being applied when computing the stepk for the Spergel profile.

The first power is here:

GalSim/src/SBSpergel.cpp

Lines 101 to 102 in 120eab3

	double SBSpergel::SBSpergelImpl::calculateFluxRadius(double f) const
	{ return _info->calculateFluxRadius(f) * _r0; }

but then the scale radius is applied again here:

GalSim/galsim/spergel.py

Lines 206 to 211 in 120eab3

	@property
	def _stepk(self):
	R = self.calculateFluxRadius(1.0 - self.gsparams.folding_threshold) * self._r0
	# Go to at least 5*hlr
	R = max(R, self.gsparams.stepk_minimum_hlr * self.half_light_radius)
	return math.pi / R

I compared to the implementation in jax-galsim, and I can only get them to agree if I use a second factor of r0 within jax-galsim like this

    @property
    def _stepk(self):
        R = calculateFluxRadius(1.0 - self.gsparams.folding_threshold, self.nu)
        R *= self._r0**2
        # Go to at least 5*hlr
        R = jnp.maximum(R, self.gsparams.stepk_minimum_hlr * self.half_light_radius)
        return jnp.pi / R

Note that the jax-galsim calculateFluxRadius function is in normalized units, and so should have only one factor of r0.

[beckermr]

cc @rmjarvis @jmeyers314

[rmjarvis]

I concur. Looks like this error was introduced when trying to move more of the implementation up to python. The pure C++ code looks right, but the python code has a spurious extra r0. And we apparently didn't have a test that would catch the change.

[jmeyers314]

Yep. Tests pass either way. Maybe we should check stepk /propto scale_radius.

[rmjarvis]

propto 1/scale_radius. But yeah, we should add a test about this.