Maximum number of radial grid points produces all Nan solution

[STBadman]

Describe the bug

Consistently finding that increasing number of grid points in the radial direction (nrho) above 192 causes all nan outputs to the solution.

To Reproduce

import astropy.constants as const
import astropy.units as u
import matplotlib.pyplot as plt
import numpy as np
import sunpy.map
from astropy.coordinates import SkyCoord

from sunkit_magex import pfss

###############################################################################
# Load a GONG magnetic field map.

gong_fname = pfss.sample_data.get_gong_map()
gong_map = sunpy.map.Map(gong_fname)

###############################################################################
# The PFSS solution is calculated on a regular 3D grid in (phi, s, rho), where
# rho = ln(r), and r is the standard spherical radial coordinate. We need to
# define the number of rho grid points, and the source surface radius.

nrho = 35
rss = 2.5

###############################################################################
# From the boundary condition, number of radial grid points, and source
# surface, we now construct an Input object that stores this information.

pfss_in = pfss.Input(gong_map, 193, rss)
pfss_out = pfss.pfss(pfss_in)
pfss_out.source_surface_br.plot()

Screenshots

Output of plotting source surface br with 193 radial grid points. All values are Nan (also can be verified that the output.bcgrid of field vector values is Nan everywhere

System Details

General
#######
OS: Ubuntu (22.04, Linux 6.5.0-25-generic)
Arch: 64bit, (x86_64)
sunpy: 5.1.0
Installation path: /home/sbadman/anaconda3/lib/python3.9/site-packages/sunpy-5.1.0.dist-info

Required Dependencies
#####################
astropy: 5.3.4
numpy: 1.24.3
packaging: 23.1
parfive: 2.0.1

sunkit-magex current github main branch (also most recent version of pfsspy)

Installation method

git checkout

[wtbarnes]

You likely already know this, but just adding that I found this to be the case with pfsspy as well, so this is independent of any changes that were made when moving to this new package.

[STBadman]

yeah noted it in the issue but quite low down - maybe we can flag "inherited" issues to distinguish?

[wtbarnes]

Oops completely missed that! Yeah that's not a bad idea. Could just use a label.