round_parameterlimits (viz.py) throws "cannot convert NaN to int" error

[alexteachey]

• UltraNest version: 3.4.4
• Python version: 3.8.12
• Operating System: Mac OS Big Sur (11.6)

Description

I'm attempting to fit a model with 15 parameters to a time series, but most every time I tried to start the run I was getting a breakdown where the code is trying to convert a NaN to an integer. The source of the error is in viz.py, in the function "round_parameterslimits()", line 71:

fmt = '%%+.%df' % (max(0, -int(np.floor(log10(phi[i] - plo[i])))))

I have been unable to figure out why the NaN is popping up in the first place, but as far as I can tell, this is just for printing purposes, and it's not clear to me that the int needs to be there at all. When I removed it, the code starts running as expected.

Here's the traceback:

  File "/Users/hal9000/Documents/Software/MoonPy/mp_fit.py", line 493, in mp_ultranest
    sampler.run(min_num_live_points=nlive)
  File "/opt/miniconda3/envs/moonpy_with_pandora/lib/python3.8/site-packages/ultranest/integrator.py", line 2173, in run
    for result in self.run_iter(
  File "/opt/miniconda3/envs/moonpy_with_pandora/lib/python3.8/site-packages/ultranest/integrator.py", line 2406, in run_iter
    viz_callback(
  File "/opt/miniconda3/envs/moonpy_with_pandora/lib/python3.8/site-packages/ultranest/viz.py", line 108, in nicelogger
    plo_rounded, phi_rounded, paramformats = round_parameterlimits(plo, phi, paramlimitguess=info.get('paramlims'))
  File "/opt/miniconda3/envs/moonpy_with_pandora/lib/python3.8/site-packages/ultranest/viz.py", line 72, in round_parameterlimits
    fmt = '%%+.%df' % (max(0, -int(np.floor(log10(phi[i] - plo[i])))))            
ValueError: cannot convert float NaN to integer
>>> quit()

Often I'm met with a different error, an AssertionError, shortly after the run starts -- it seems somewhere the parameters start running off to infinity. I guess this is something I'm doing wrong, but the traceback doesn't offer much in the way of hints:

[ultranest] Sampling 1000 live points from prior ...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/hal9000/Documents/Software/MoonPy/_mp_manipulation.py", line 216, in fit
    mp_ultranest(times=fit_times, fluxes=fit_fluxes, errors=fit_errors, param_dict=self.param_uber_dict, nlive=nlive, targetID=self.target, model="M", modelcode='Pandora', resume=ultranest_resume, show_plot='y')
  File "/Users/hal9000/Documents/Software/MoonPy/mp_fit.py", line 493, in mp_ultranest
    sampler.run(min_num_live_points=nlive)
  File "/opt/miniconda3/envs/moonpy_with_pandora/lib/python3.8/site-packages/ultranest/integrator.py", line 2173, in run
    for result in self.run_iter(
  File "/opt/miniconda3/envs/moonpy_with_pandora/lib/python3.8/site-packages/ultranest/integrator.py", line 2385, in run_iter
    region_fresh = self._update_region(
  File "/opt/miniconda3/envs/moonpy_with_pandora/lib/python3.8/site-packages/ultranest/integrator.py", line 1949, in _update_region
    f = tregion.compute_enlargement(
  File "ultranest/mlfriends.pyx", line 1385, in ultranest.mlfriends.WrappingEllipsoid.compute_enlargement
  File "ultranest/mlfriends.pyx", line 367, in ultranest.mlfriends.bounding_ellipsoid
AssertionError: (array([[ 8.26438934e+016, -2.99370074e+005, -1.02789141e+009, [....] 
  2.04755382e+179, -2.00954729e+151, -1.97270683e+151,
        -7.72451251e+150,  3.83882523e+149,              inf]])

Hard to track down why that is occurring. Might it be because the samples are initializing too close to the edge of the parameter space? Is there a way to avoid this?

[alexteachey]

The second error above appears to to occur when restarting a job after modifying parameters -- resume files all should be cleared before restarting. (Makes sense! But anyway it's not necessarily obvious from the AssertionError).

[JohannesBuchner]

That line of code figures out how many digits to print. It builds a format string, "%.3f", for example.

[JohannesBuchner]

But yes, it is just for printing.

Is it possible that your transform made some infinites? It looks like the values are getting extremely large (1e150).

[JohannesBuchner]

Closing, please reopen if the issue still persists