Bug(s?) in `test_Bayesian_inference_DDH.ipynb`

[svisak]

In the last step in the notebook mentioned in the title, I get an error in the last step ("Inference"). Here's the traceback:

ValueError                                Traceback (most recent call last)
Cell In[5], line 5
      1 step = 2 * len(parameters)
      2 live_point = 2000
      3 
      4 max_calls = 500000
----> 5 samples = sampler.UltranestSampler(parameters,likelihood_transform,prior_transform,step,live_point,max_calls)

File ~/repos/referee/CompactObject/CompactObject/InferenceWorkflow/BayesianSampler.py:52, in UltranestSampler(parameters, likelihood, prior, step, live_points, max_calls)
     32 def UltranestSampler(parameters,likelihood,prior,step,live_points,max_calls):
     33     """UltraNest based nested sampler by given likelihood prior, and parameters.
     34     
     35     Args:
   (...)     50         
     51     """
---> 52     sampler = ultranest.ReactiveNestedSampler(parameters, likelihood, prior,log_dir='output')
     53     sampler.stepsampler = ultranest.stepsampler.SliceSampler(
     54         nsteps=step,
     55         generate_direction=ultranest.stepsampler.generate_mixture_random_direction,
     56         # adaptive_nsteps=False,
     57         # max_nsteps=400
     58     )
     60     result = sampler.run(min_num_live_points=live_points,max_ncalls= max_calls)

File ~/repos/referee/CompactObject/pipenv/lib/python3.14/site-packages/ultranest/integrator.py:1215, in ReactiveNestedSampler.__init__(self, param_names, loglike, transform, derived_param_names, wrapped_params, resume, run_num, log_dir, num_test_samples, draw_multiple, num_bootstraps, vectorized, ndraw_min, ndraw_max, storage_backend, warmstart_max_tau)
   1213 self.ndraw_max = ndraw_max
   1214 self.build_tregion = transform is not None
-> 1215 if not self._check_likelihood_function(transform, loglike, num_test_samples):
   1216     assert self.log_to_disk
   1217     if resume_similar and self.log_to_disk:

File ~/repos/referee/CompactObject/pipenv/lib/python3.14/site-packages/ultranest/integrator.py:1277, in ReactiveNestedSampler._check_likelihood_function(self, transform, loglike, num_test_samples)
   1273 p = transform(u) if transform is not None else u
   1274 assert np.shape(p) == (num_test_samples, self.num_params), (
   1275     "Error in transform function: returned shape is %s, expected %s" % (
   1276         np.shape(p), (num_test_samples, self.num_params)))
-> 1277 logl = loglike(p)
   1278 assert np.logical_and(u > 0, u < 1).all(), (
   1279     "Error in transform function: u was modified!")
   1280 assert np.shape(logl) == (num_test_samples,), (
   1281     "Error in loglikelihood function: returned shape is %s, expected %s" % (np.shape(logl), (num_test_samples,)))

File ~/repos/referee/CompactObject/pipenv/lib/python3.14/site-packages/ultranest/utils.py:137, in vectorize.<locals>.vectorized(args)
    135 def vectorized(args):
    136     """Vectorized version of function."""
--> 137     return np.asarray([function(arg) for arg in args])

Cell In[3], line 19, in likelihood_transform(para)
     15     m_rho = 763 / oneoverfm_MeV
     16     rho0 = para[-1]
     17 
     18     # Calculate the density-dependent coupling factors
---> 19     gsf, gwf, grf, dgsf, dgwf, dgrf = DDH.Function(type='Malik22', couplings=para)
     20     theta = np.array([m_sig, m_w, m_rho, gsf, gwf, grf, dgsf, dgwf, dgrf, rho0])
     21 
     22 

File ~/repos/referee/CompactObject/CompactObject/EOSgenerators/RMF_DDH.py:92, in Function(type, couplings)
     88 elif type == 'Malik22':
     89     """
     90     https://doi.org/10.3847/1538-4357/ac5d3c
     91     """
---> 92     if couplings == "Default":
     93         # DDBm model
     94         as_, av, ar, gs0, gv0, grho0, rho0 = [0.086372, 0.054065, 0.509147, 9.180364, 10.981329, 3.826364*2, 0.150]
     95     else:

ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

The notebook runs well up until that point. However, I noticed that my output from the "Test log_likelihood function" section differs somewhat from what's in the online documentation. My version gives

-5.759871011413044
-5.744103553160343
-5.779624740149276
-5.768465293900378
-5.774649605509163
-5.779624740149276
-5.768465293900378
-5.772171289494696
1min 12s ± 258 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

compared to

-5.739301623110369
-5.739301623110369
-5.739301623110369
-5.739301623110369
-5.739301623110369
-5.739301623110369
-5.739301623110369
-5.739301623110369
614 ms ± 2.09 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Could you confirm whether this is an error or just minor numerical differences? Also, I assume that the difference in runtime is because I haven't been able to install NumbaMinpack?

Part of the JOSS review

[ChunHuangPhy]

Thank you for reporting this issue. We confirmed that the final inference failure was a bug. DDH.Function compared the NumPy coupling array directly with the string "Default", producing the ambiguous truth-value error. We replaced this with a type-safe check that only performs the string comparison when the argument is a string. We also added a regression test covering the Malik22 model with a NumPy coupling array.

The differing likelihood values were not simply floating-point round-off. The previous pQCD likelihood randomly sampled the renormalization scale during every evaluation, so repeated evaluations of identical parameters could return different values. We replaced this stochastic calculation with deterministic midpoint quadrature over the same log-uniform range. Repeated evaluations are therefore now reproducible, although small platform-dependent numerical differences may remain.

The runtime difference is not caused by the absence of NumbaMinpack. That optional package accelerates only the fastRMF_EoS implementation and is not used by this DDH likelihood. Its runtime is dominated by the DDH EOS and TOV calculations and can vary substantially with Python/SciPy versions and hardware. We removed the old, non-portable timing result from the notebook and clarified this point in the documentation.

Finally, the corrected notebook is now executed as part of CI up to the direct likelihood test, while the computationally expensive full UltraNest sampling step is explicitly marked as long-running. Thank you for helping us identify and resolve these issues.