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: [email protected]<mailto:[email protected]> ------------------------------------------------ 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/ 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 [email protected]