Unexpected behaviour from ADJOINT_CODE

[Mark Clements]

I am getting some unexpected behaviour using ADJOINT_CODE, where a dmatrix object has incremented columns under certain circumstances. Has anyone else seen similar behaviour?

For context, I am fitting accelerated failure models S(t|x)=S0(t exp(-beta^T x)) for time t, covariates x and parameters beta. We model the baseline survival function using log(-log(S0(t*))=N(t*)^T gamma using a natural spline basis N(t*) and parameters gamma. Note that the spline basis is a function of beta. As I have code to calculate the derivatives of the spline basis, I am investigating using ADJOINT_CODE with double splines.

I have attached code in R that runs correctly under ADMB version 12.3. However, on line 235, I need to decrement the columns when q_matrix.colmin()==1 && der==2 -- this is a surprising requirement, because the vectors and matrices are all set as being 0-based (??). Note I did not have any problems when I used similar splines code with dvars.

Can anyone suggest how to begin debugging this? (The code is a bit long, but most of the code is for the SplineBasis, bs and ns spline classes.)

Sincerely, Mark.

När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att behandla dina personuppgifter. Här finns information om hur KI behandlar personuppgifter. 

Sending email to Karolinska Institutet (KI) will result in KI processing your personal data. You can read more about KI’s processing of personal data here. 

[Johnoel Ancheta]

Hi Mark,

The issue is the shifted indexes for input data X and qconst.

When ADMB runs the Procedure_Section, the following happens in this order.

1.  X and qconst are shifted to the zero index.

2.  The function etf_f is called which puts the call to adjoint deriv_eta_f function on the gradient stack.

3.  X and qconst are shifted back to the original 1 index.

Next the gradients are computed.  They are done in reverse starting from the top of the gradient stack.  When the

adjoint function derive_eta_f is called, it depends on that X and qconst were shifted to zero.  Since they were 

re-shifted to 1 at the end of the procedure section, it resulted in index errors for the run.  To resolve this, the shifting

should only be done once.  The prelimary_calcs_section is called only once before the procedure_section.  It can

be used to organize the input model data.  In this case, shifting the indexes. 

The attached tpl shows how it can be used with the model.  Although it can be done in other ways, this is the simplest

and easiest approach.

Also, another neat method is to use save_int_value() and restore_int_value() functions.  If you need to just save and

restore an integer from the stack, this is a more direct approach.  These functions are described in https://api.admb-project.org/.

Let me know if you need more details.

Johnoel

--
To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@admb-project.org.

[Mark Clements]

Johnoel: thank you for your guidance and support.

The accelerated failure time models are a nice example of a model class that can be easily implemented in ADMB with extensions to random effects - but cannot be easily implemented in TMB.

Sincerely, Mark.

---

From: Johnoel Ancheta <joh...@hawaii.edu>
Sent: 28 January 2022 02:22
To: Mark Clements <mark.c...@ki.se>
Cc: us...@admb-project.org <us...@admb-project.org>
Subject: Re: [ADMB Users] Unexpected behaviour from ADJOINT_CODE