Error: node stack overflow

[hiroshi-in-uk]

This is my first ever use of GitHub. Please help me resolve the following Nimble problem.

In the attached Nimble code, "Error: node stack overflow" happens at "conf <- configureMCMC(Rmodel, thin=1,..." (LL165-175).

I am working on linux Amazon WorkSpacex, and the memory size is the following.

$ free -m total used free shared buff/cache available Mem: 8062756 1797848 5336268 60636 928640 5952080 Swap: 12094132 2012 12092120

Nimble_PBPKD.zip

Thank you.

Hiroshi

[hiroshi-in-uk]

Further to my original post - this Nimble code seems to run OK on a native Linux machine, but not on Windows machine, Windows Linux sub-system or AWS emulated Linux machine with same available memory. Hiroshi

[paciorek]

Hi Hiroshi,

When I try to run your code, there is some sort of mismatch in dimensionality. The output of the ode call is of length 3 (and with two NaN values) but 'y' is of length 2.

It's probably not related to the error you are reporting, but we'd need to fix this before trying to figure out the stack overflow.

> Rmodel <- nimbleModel(myNimbleCode, constants, data, inits)  # interpreted
Defining model
Building model
Setting data and initial values
Running calculate on model
  [Note] Any error reports that follow may simply reflect missing values in model variables.
DLSODA-  At T (=R1), too much accuracy requested  
      for precision of machine..  See TOLSF (=R2) 
In above message, R1 = 0.25, R2 = nan
 
Error in model$Conc[getNodeFunctionIndexedInfo(INDEXEDNODEINFO_, 1), 1:getNodeFunctionIndexedInfo(INDEXEDNODEINFO_,  : 
  number of items to replace is not a multiple of replacement length

R_ode(Rmodel$y[1:2],
                                        Rmodel$times[i, 1:constants$ntimes[i]],
                                        c(constants$dose[i], Rmodel$P2[i], Rmodel$P6,  Rmodel$P7, Rmodel$P4,
                                          Rmodel$P5, Rmodel$P9, Rmodel$P66[i], Rmodel$Gj[i],
                                          Rmodel$Rw[i], Rmodel$Zx[i], Rmodel$Rh[i],
                                          Rmodel$Uu[i], Rmodel$P1_scaled[i], Rmodel$P11))
DLSODA-  At T (=R1), too much accuracy requested  
      for precision of machine..  See TOLSF (=R2) 
In above message, R1 = 1, R2 = nan
 
[1]   0 NaN NaN
Warning messages:

[hiroshi-in-uk]

Thank you Christopher for spotting another issue, which I did not see on my linux AmazonWorkspaces.

Please can you use the new zipped folder attached instead. Only PBPKD.c was revised (the whole folder is attached, as I found that *.c file cannot be attached to this message).

I think the dimensions-mismatch problem does not appear with this new one. Nimble_PBPKD.zip

[paciorek]

Thanks, I'm able to reproduce this and am investigating. I expect to provide a work-around shortly.

Notes to the development team so far: issue seems to be in conjugacy checking.

1. The deparse warning is occurring because the linearityCheckExpr is long:

Browse[3]> linearityCheckExpr
structureExpr(nimble_ode(y[1:2], times[3, 1:11], nimC(1775, P2[3], 
    P6, P7, P4, P5, P9, 0.6 * pow(0.008 * pow(BM[3], 0.4) * pow(Ft[3], 
        0.7), 1.1), P3[3] * BM[3] - 0.6 * pow(0.008 * pow(BM[3], 
        0.4) * pow(Ft[3], 0.7), 1.1) * P9/P5, 0.1 * (0.008 * 
        pow(BM[3], 0.4) * pow(Ft[3], 0.7) * 50 * (2 - 0.01 * 
        (Load[3] - 20))), 0.15 * (0.008 * pow(BM[3], 0.4) * pow(Ft[3], 
        0.7) * 50 * (2 - 0.01 * (Load[3] - 20))) + 0.1 * (0.008 * 
        pow(BM[3], 0.4) * pow(Ft[3], 0.7) * 50 * (2 - 0.01 * 
        (Load[3] - 20))), 0.15 * (0.008 * pow(BM[3], 0.4) * pow(Ft[3], 
        0.7) * 50 * (2 - 0.01 * (Load[3] - 20))), (130 - Load[3]) * 
        70/(0.7 * P14) * 1.5/(0.008 * pow(BM[3], 0.4) * pow(Ft[3], 
        0.7))/100 * P13, P1[3] * P10 * P12 * 1e-05, P11)))

2. The overflow seems to occur when checking the C_plasma_obs[13,1] dependency of P5.

nimble:::conjugacyRelationshipsObject$conjugacys$dnorm$checkConjugacyOneDep(Rmodel, 'P4', 'C_plasma_obs[13, 1]', FALSE)

Note that things seem ok for other dependencies in C_plasma_obs (those in rows before the 13th row.

In doing so the structureExpr expansion seems to go out of control when running `cc_expandDetermNodesInExpr(model, linearityCheckExprRaw, targetNode = targetNode):

Browse[2]> linearityCheckExpr
structureExpr(nimble_ode(y[1:2], structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(
<<SNIP>>
structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr(structureExpr()))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))), 
    nimC(1054, P2[13], P6, P7, P4, P5, P9, 0.6 * pow(0.008 * 
        pow(BM[13], 0.4) * pow(Ft[13], 0.7), 1.1), P3[13] * BM[13] - 
        0.6 * pow(0.008 * pow(BM[13], 0.4) * pow(Ft[13], 0.7), 
            1.1) * P9/P5, 0.1 * (0.008 * pow(BM[13], 0.4) * pow(Ft[13], 
        0.7) * 50 * (2 - 0.01 * (Load[13] - 20))), 0.15 * (0.008 * 
        pow(BM[13], 0.4) * pow(Ft[13], 0.7) * 50 * (2 - 0.01 * 
        (Load[13] - 20))) + 0.1 * (0.008 * pow(BM[13], 0.4) * 
        pow(Ft[13], 0.7) * 50 * (2 - 0.01 * (Load[13] - 20))), 
        0.15 * (0.008 * pow(BM[13], 0.4) * pow(Ft[13], 0.7) * 
            50 * (2 - 0.01 * (Load[13] - 20))), (130 - Load[13]) * 
            70/(0.7 * P14) * 1.5/(0.008 * pow(BM[13], 0.4) * 
            pow(Ft[13], 0.7))/100 * P13, P1[13] * P10 * P12 * 
            1e-05, P11)))

@danielturek let me know if you're up for taking a look given the issue seems to be in the structureExpr stuff / linearity checking.

[paciorek]

@hiroshi-in-uk this appears to be a bug in our conjugacy processing.

To avoid the issue you can stop Nimble from checking conjugacy. In this model I don't see any conjugacy anyway, so the check is not actually useful.

Try this:

conf <- configureMCMC(Rmodel, thin=1, useConjugacy = FALSE,
                      monitors=c("Load", "BM", "P1_pop", "P2_pop",
                                 "P3_pop", "P1_popSD", "P2_popSD",
                                 "P3_popSD",
                                 "P4", "P5", "P6", "P7",
                                 "P9", "P10", "P12",
                                 "P11", "P13", "P14",
                                 "b0", "b1",
                                 "P1", "P2", "P3", 
                                 "P66", "Gj",
                                 "Rw", "Zx", "Rh", "Uu", "P1_scaled"))

[paciorek]

Actually, I realized that this seems to be the issue that @danielturek fixed in commit b1bd64a8a. @danielturek we should look into the safeDeparse warnings, which still occur after the fix. I can do that since I have been the one mostly working on the line length/deparse stuff.

@hiroshi-in-uk - the work-around I suggested in my previous message should work fine. But the issue is actually fixed in the devel branch of nimble and will be fixed in our next release. You can ignore the safeDeparse warnings.

[danielturek]

@paciorek Thanks for looking into this. Confirming that this infinite recursion case was recently fixed, and this current example fails on the most recent release, but passes on current devel branch.

@paciorek Let me know if my looking at or fixing anything with conjugacy would be helpful. I'm happy to if that's the case. Or let me know if you want me to troubleshoot the repeated safeDeparse messages that we're seeing. (I just pushed a minor change which correctly handles the trailing "s" in the output message)

[hiroshi-in-uk]

I can confirm that by adding "useConjugacy = FALSE" in configureMCMC(), "Error: node stack overflow" has disappeared on my linux AWS. Thank you very much @paciorek

[paciorek]

I'm addressing the deparse issue in an issue in our internal issue tracker, so closing this.