Re: Cmax/Tmax in the DES block

On 5/4/2018 2:57 PM, Bauer, Robert wrote: > Leonid and Kyle: > > The code of ..\pr\ADVAN13.f90 (LSODA) is viewable and modifiable to the user, and it shows that ITASK=1 is always set. While for the short term you can change this setting and recompile ADVAN13, for the long term, I will look into adding an option at the control stream level, where the user may be able to set a different behavior (ITASK value) for a particular time interval. I suspect it might be inefficient for ITASK to always be set to 4. > > Robert J. Bauer, Ph.D. > > Senior Director > > Pharmacometrics R&D > > ICON Early Phase > > 820 W. Diamond Avenue > > Suite 100 > > Gaithersburg, MD 20878 > > Office: (215) 616-6428 > > Mobile: (925) 286-0769 > > [email protected] <mailto:[email protected]> > > www.iconplc.com http://www.iconplc.com/ > > *From:* [email protected] [ mailto: [email protected] ] *On Behalf Of *Leonid Gibiansky > > *Sent:* Friday, May 04, 2018 10:16 AM > *To:* Kyle Baron; Paolo Denti > *Cc:* Bob Leary; [email protected] > *Subject:* Re: [NMusers] Cmax/Tmax in the DES block > > Interesting links. > > So looks like one can provide tcrit=TIME (where TIME is the next EVENT > time) to LSODA, and this will fix the over-shoot problem (as in > ITASK=4). I wonder whether ADVAN13 and ADVAN6 use different settings for > tcrit (or the difference in the results is just the difference in the > amount of over-shooting) > > Leonid > > On 5/4/2018 12:58 PM, Kyle Baron wrote: > > I agree with Paolo's explanation, but I suspect it isn't something > > specific to NONMEM. When LSODA integrates up to the time of the > > end of the infusion, there is no guarantee that it will never go > > past that time. Rather, it's likely that it will "overshoot" that > > time and interpolate back to the place where it was supposed to > > stop (the end of the infusion). That might be why Leonid is seeing the > > bias. > > > > I couldn't find the docs that specifically discuss this, but maybe > > NONMEM uses ITASK 1 when it advances the system? > > > > > https://github.com/metrumresearchgroup/mrgsolve/blob/master/src/opk_dlsoda_mrg.f#L378-L381 > > > > > You can also see the overshoot discussed in the deSolve docs: > > > > > https://www.rdocumentation.org/packages/deSolve/versions/1.20/topics/lsoda > > > > > (see the tcrit argument) > > > > Kyle > > > > On Fri, May 4, 2018 at 11:03 AM, Paolo Denti <[email protected] > <mailto:[email protected]%20%0b>> <mailto:[email protected]>> wrote: > > > > Dear all, > > Very interesting, just adding my two cents, but not sure it's 100% > > relevant. > > > > When I played with ADVAN13 before and asked NONMEM to print out all > > the steps in a file, I could see that the time (T) was not always > > going forward, but sometimes NONMEM was taking some steps back in > > time and then proceeding again. > > > > Not sure if this is because of how LSODA is implemented in NONMEM. I > > remember - but I am happy to stand corrected - that some DES work in > > such a way that they rework the size of the time steps dynamically > > when they solve the ODEs and if the TOL (precision) criterion is not > > met, they go back and retry with a small step size. So I was > > thinking that maybe the difference in Cmax could be from one of > > those "faux pas" when NONMEM has overshot the solution and then it > > would take a step back? > > > > Just an idea on something to check. But I guess the NONMEM > > developers may have a quick answer to this one (hint hint). > > > > Paolo > > > > > > On 2018/05/04 17:32, Leonid Gibiansky wrote: > >> The procedure described in the original post is working without extra > >> points. It is working fine, just have a small bias, and the bias > >> seems > >> to be zero with ADVAN6. For all the practical purposes it can be used > >> without extra points. I was just surprised that it is not exact in > >> some > >> cases, so extra check is warranted each time when it is used (may > >> be we > >> can switch to ADVAN6 rather than ADVAN13 when computing Cmax/Cmin > >> in the > >> DES block). > >> > >> Latest NONMEM versions have "finedata" Utility Program that can be > >> used > >> to add extra points to the dataset (nm741.pdf, page 237). > >> > >> Leonid > >> > >> > >> On 5/4/2018 11:01 AM, Bob Leary wrote: > >> > One of the problems with all of this is that the user must > >> manually enter artificial time points (or at least in 2007 had to > >> do this - I don't know if this has been fixed in > >> > The latest NM versions) in the data set in order to evaluate the > >> fitted model over more grid points than are in the original data. > >> > To get a fine grid and good resolution on Cmax and Tmax > >> > You have to enter a lot of extra time points., which is a pain > >> in the neck. The various ODE routines are also remarkably > >> sensitive to how the grid is set up. > >> > > >> > Much better would be to have a grid generator within NMTRAN that > >> lets you just specify beginning and end points and number of > >> points in the grid. > >> > I would point out that Phoenix NLME PML has always had this > >> capability. > >> > Bob Leary > >> > > >> > -----Original Message----- > > >> > From: [email protected] < mailto: [email protected] > > > >> <mailto:[email protected]> > >> <[email protected] <mailto:[email protected]>> > >> <mailto:[email protected]> On Behalf Of Leonid Gibiansky > >> > Sent: Thursday, May 3, 2018 7:59 PM > > >> > To: [email protected] < mailto: [email protected] > < mailto: [email protected] > > > >> > Subject: [NMusers] Cmax/Tmax in the DES block > >> > > >> > Interesting experience concerning computation of Cmax and Tmax > >> (and probably other stats) in the DES block. We used to use this way: > >> > > >> > http://cognigencorp.com/nonmem/current/2007-December/4125.html > >> https://protect-za.mimecast.com/s/L8T-CAnX51ilA2ops83Si8 > >> > > >> > Specifically, reserved the place in the memory: > >> > > >> > $ABB COMRES=2 > >> > > >> > Set these values to zero for each new subject: > >> > $PK > >> > IF(NEWIND.LE.1) THEN > >> > COM(1)=0 > >> > COM(2)=0 > >> > ENDIF > >> > > >> > and computed Cmax/TMAX as > >> > $DES > >> > IF(CONC.GT.COM http://CONC.GT.COM http://CONC.GT.COM(1)) THEN > >> > COM(1)=CONC > >> > COM(2)=T > >> > ENDIF > >> > > >> > $ERROR > >> > CMAX=COM(1) > >> > TMAX=COM(2) > >> > > >> > Recently I applied the same procedure to compute Cmax following > >> 1 hr IV infusion. Unexpectedly, Tmax was estimated at times > 1 > >> hr, and Cmax was higher than 1-hr concentration (true Cmax is at 1 > >> hr). > >> > > >> > After some experiments, the explanation was that Nonmem computes > >> concentration-time course (with infusion ON) for longer than 1 hr, > >> and resulting Cmax/Tmax are at the end of the "computation window" > >> rather than at 1 hr. > >> > > >> > Turns out that the results also depend on ADVAN routine. The > >> largest deviation (still small, 1-3 percents) was for ADVAN8, > >> ADVAN9, and ADVAN13. ADVAN15 was better but still off. ADVAN14 was > >> almost perfect but still slightly (0.01%) off. ADVAN6 provided > >> correct answer (up to the precision of the output). So, the > >> discrepancy is small but if 1-2% difference is important, one has > >> to be careful when using DES block computations. > >> > > >> > Thanks > >> > Leonid > >> > > >> > > >> >