Compilation error on rstan

fit$init() hopefully works: https://mc-stan.org/cmdstanr/reference/fit-method-init.html

@bbbales2 Thanks. It did work.

I am running into a very strange error while sampling in CMDStan.

Exception: Exception: Exception: Exception: gradient_of_f: The gradient of f is nan for parameter 4 (in 'models/asm/asm_working.stan', line 439, column 4 to column 17) 

Here is the full model and fake data used for fitting ā€“
asm_working.stan (15.2 KB)
artf_data.csv (1.4 KB)
Of course I use .json file when sampling in CMDStan.

Do you know what may cause this? All the functions evaluate fine when used with expose_stan_functions. In fact, the artf_data.csv file is generated using this model in R by exposing the stan functions, evaluating them at the given time points, and adding some error to it. All the functions work with a wide range of parameter values. I fail to understand where exactly is the sampler encountering error.

Thanks for all the help so far. I need to nail this down.

The code thatā€™s throwing this error is:

var fx = f(x, xc, theta_var, x_r, x_i, msgs);
fx.grad();
gradient = theta_var[n].adj();
if (is_nan(gradient)) {
  if (fx.val() == 0) {
    gradient = 0;
  } else {
    throw_domain_error("gradient_of_f", "The gradient of f", n,
                       "is nan for parameter ", "");
  }
}

return gradient;

So if the function is f(\theta_1, \theta_2, ...), \frac{\partial f}{\partial \theta_4} is evaluating to NaN (probably due to an overflow) and f is evaluating to something non-zero. Itā€™s pretty common for gradients to be NaN at limits of integration, but as long as f is zero we ignore it. My first reaction was to look for integrations with infinite limits, but since this is nested finite integrals I donā€™t know where to start looking either.

One of your comments says PDE solution. What PDE is this solving? Is there a way to discretize this spatially and solve it with the ODE solver?

Otherwise itā€™s probably rather crude but just do the integrals with the ODE solver. This problem happened yesterday: Difference in behavior between integrate_1d and integrate - #11 by bbbales2 . I think we need to do something different for our integration. This quadrature just blows up too much and itā€™s nigh impossible to debug.

1 Like

What PDE is this solving?

\frac{\partial u}{\partial t} + \frac{\partial u}{\partial a} - \beta k \frac{\partial u}{\partial k} = - (\rho + \delta(a)) \, u(a, k, t)

I think the problem is in the solution to one of the boundary conditions.

Otherwise itā€™s probably rather crude but just do the integrals with the ODE solver.
I managed to use the ODE solver to do the integration and it works like magic. Everything is working fine now and quite fast too. Thanks for all the help. The solution to integrals matches with what I get in R and python.

I think the integrate_1d function in stan is not correctly interpreting the error messages from boost library integrators.

Thanks again @bbbales2 for taking the time and helping me solve this!!!

Best, Sanket.

2 Likes

Thereā€™s been a small pile of people reporting problems with integrate_1d. It feels like something isnā€™t quite right. (Edit: and small pile for a feature that isnā€™t used a lot seems like a lot)

We investigated and found a problem with how the tolerances were working in the integrator. So this error:

integrate: error estimate of integral above zero 5.00586e-09 exceeds the given relative tolerance times norm of integral above zero (in '/tmp/RtmpAnWvKa/model-3fad4361b76ae.stan', line 254, column 4 to column 19) 

will hopefully go away in the future (thereā€™s a patch in develop now but itā€™ll be another couple months before it goes out in the a release, see here for details: https://github.com/boostorg/math/issues/449).

Anyway thanks for reporting the problem!

2 Likes

Release is out that fixes this: Release of CmdStan 2.26.0

3 Likes