Paolo:
From what I can tell in scanning the code of ..\pr\SS13.f90, the TOL setting on 
the $SUBROUTINES record appears to determine the precision of the steady state 
condition.  You can change the TOL value, or, if you wish the SS precision to 
differ from the ODE evaluation precision, you can modify SS13.f90, as it is 
open source to users, by replacing the NRD argument (which contains the TOL 
value submitted by the $SUBROUTINES record) to all calls to ZSPOW1 with an 
alternative value of your choosing.  Recompile SS13.f90, then execute NONMEM 
with nmfe73 script as usual.


Robert J. Bauer, Ph.D.
Vice President, Pharmacometrics R&D
ICON Early Phase
820 W. Diamond Avenue
Suite 100
Gaithersburg, MD 20878
Office: (215) 616-6428
Mobile: (925) 286-0769
robert.ba...@iconplc.com<mailto:robert.ba...@iconplc.com>
www.iconplc.com<http://www.iconplc.com/>

From: owner-nmus...@globomaxnm.com [mailto:owner-nmus...@globomaxnm.com] On 
Behalf Of Paolo Denti
Sent: Wednesday, May 18, 2016 3:16 AM
To: nmusers
Subject: [NMusers] Steady-state (SS) and $DES veeeery slow

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 to get 
some feedback.

We work on steady-state PK data, so ideally we would like to use the SS option, 
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 
initialising 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 the 
SS amounts in each compartment. The model is taken to SS by repeatedly giving 
doses every II, until the system is deemed to have reached steady-state. 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 with 
SS, cuz the calculation of these SS amounts implies solving the differential 
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 expecting 2 dosing 
intervals (48 hours) to be more than enough to get to steady state, as maths 
says the amounts should be 99.993% there. NONMEM instead used 13 doses in the 
example below.

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

#DOSE    T    TOT_TIME    AA2
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 practical cases 
- at least for preliminary runs - and in this example it would save 80% of the 
run time. Plus if one keeps in mind that this is a numerical solver, it is not 
clear how "real" the wee digits are, obviously depending on TOL.

The other tricky thing I found is that the amount in the absorption compartment 
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 relative change 
<TOL, it will struggle to achieve that with values that change sign.

Any settings that may help speed things up? Something like tinkering with TOL 
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!
Ciao,
Paolo

PS And big thanks to our PhD student Maxwell who ran all the tedious 
simulations!



--

------------------------------------------------

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.de...@uct.ac.za<mailto:paolo.de...@uct.ac.za>

------------------------------------------------
Disclaimer - University of Cape Town This e-mail is subject to UCT policies and 
e-mail disclaimer published on our website at 
http://www.uct.ac.za/about/policies/emaildisclaimer/<http://www.uct.ac.za/about/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 cs...@uct.ac.za<mailto:cs...@uct.ac.za>
<br /><br />
ICON plc made the following annotations.
------------------------------------------------------------------------------
This e-mail transmission may contain confidential or legally privileged 
information that is intended only for the individual or entity named in the 
e-mail address. If you
are not the intended recipient, you are hereby notified that any disclosure, 
copying, distribution, or reliance upon the contents of this e-mail is strictly 
prohibited. If
you have received this e-mail transmission in error, please reply to the 
sender, so that ICON plc can arrange for proper delivery, and then please 
delete the message.

Thank You,

ICON plc
South County Business Park
Leopardstown
Dublin 18
Ireland
Registered number: 145835

Reply via email to