NONMEM Users Network Archive

Hosted by Cognigen

Steady-state (SS) and $DES veeeery slow

From: Paolo Denti <paolo.denti>
Date: Wed, 18 May 2016 12:15:52 +0200

Dear NMUsers (and developers),
I am trying to speed up our run times when using SS in ADVAN13 models (user=
 defined differential equations), and I would like to share some thoughts t=
o get some feedback.

We work on steady-state PK data, so ideally we would like to use the SS opt=
ion, but the run times whenever we use ADVAN13 become unfeasibly long (even=
 20 times more), and this even for models that should reach steady state in=
 2-3 doses.
As an alternative we end up using ad-hoc "patch-up" solutions, like initial=
ising compartments, or just adding 4-5 doses "manually" in the dataset, but=
 this is a bit tedious/tricky.
I am writing to see if there is a way to speed up the SS feature.

I decided to look into what was going on by asking NONMEM to simulate a SS =
PK profile and print out all the temporary iterations.
It seems like NONMEM first opens a separate "SS session" used to work out t=
he SS amounts in each compartment. The model is taken to SS by repeatedly g=
iving doses every II, until the system is deemed to have reached steady-sta=
te. At this point, NONMEM goes back to the "main session", initialises all =
compartments to the amounts found in the "SS session", gives the final dose=
, and moves on with the analysis.

Nothing surprising here, and it's understandable that things take longer wi=
th SS, cuz the calculation of these SS amounts implies solving the differen=
tial equations for all the extra time of the "SS session". What I found odd=
 though, is that the number of doses that NONMEM uses to reach steady-state=
 seems to me much higher than needed. In my test I used a simple 1-cmpt KA =
model coded in ADVAN13 and a drug with a half-life of 3.5 hours, so I was e=
xpecting 2 dosing intervals (48 hours) to be more than enough to get to ste=
ady state, as maths says the amounts should be 99.993% there. NONMEM instea=
d used 13 doses in the example below.

The amounts are reported in the table below. After iteration 3 the amount i=
n AA2 just changes by tiny values, arguably comparable to numerical noise.

0 0 0 0
1 0 24 4.114874
2 0 48 4.148738
3 0 72 4.149017
4 0 96 4.149017
5 0 120 4.149017
6 0 144 4.149019
7 0 168 4.149019
8 0 192 4.149019
9 0 216 4.149019
10 0 240 4.149019
11 0 264 4.149019
12 0 288 4.149019
13 0 312 4.149019

Does anyone know what stopping criterion NONMEM uses to call it SS and move=
 on? Is there a way to relax it? I think 0.1% would be fine in most practic=
al cases - at least for preliminary runs - and in this example it would sav=
e 80% of the run time. Plus if one keeps in mind that this is a numerical s=
olver, it is not clear how "real" the wee digits are, obviously depending o=
n TOL.

The other tricky thing I found is that the amount in the absorption compart=
ment AA1 is literally numerical noise after II hours, meaning that for some=
 entries it is even negative (e.g. -2.08038E-15) and jumps between positive=
 and negative. Could it be that this is what is tricking NONMEM's stopping =
criterion to detect SS? Maybe if the stopping criterion only asks for a rel=
ative change <TOL, it will struggle to achieve that with values that change=

Any settings that may help speed things up? Something like tinkering with T=
OL and ATOL?
Or maybe is it possible to set a maximum to the number of doses that NONMEM=
 tests to reach steady-state?

Sorry for the nerdy topic, and thanks for any advice!

PS And big thanks to our PhD student Maxwell who ran all the tedious simula=

Paolo Denti, PhD
Pharmacometrics Group
Division of Clinical Pharmacology
Department of Medicine
University of Cape Town

K45 Old Main Building
Groote Schuur Hospital
Observatory, Cape Town
7925 South Africa
phone: +27 21 404 7719
fax: +27 21 448 1989
email: paolo.denti

Disclaimer - University of Cape Town This e-mail is subject to UCT policies=
 and e-mail disclaimer published on our website at
ut/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. If this e-=
mail is not related to the business of UCT, it is sent by the sender in an =
individual capacity. Please report security incidents or abuse via csirt

Received on Wed May 18 2016 - 06:15:52 EDT

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to:

Once subscribed, you may contribute to the discussion by emailing: