RE: Cmax/Tmax in the DES block
Paolo and Kyle are correct on this point. ODE solving can be complicated, and
each algorithm has its own method, calling the DES routine at will at various
times T (which varies to a finer degree than TIME from the data set), sometimes
carrying out an iterative process, until it has the satisfied precision for the
grid times that it was asked to evaluate (in NONMEM’s case, values at TIME from
the data set, or MTIME positions). Hence, the need sometimes for fine grid
points in a data set that may be embellished by the finedata utility, if you
want to find a position near when a peak occurs, or some other event. This
process is not a function of NONMEM, but of the particular ODE solver used.
In Leonid’s case, things are a little easier in that an exact evaluation at the
end of infusion is desired. The finedata utility can calculate the specific
time at end of infusion and add the record, if it is a hard-coded position that
can be determined from the data set, and not one that might be evaluated from a
model parameter. This will make the results at a particular position available
as a record in a $TABLE file.
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]>
http://www.iconplc.com/
Quoted reply history
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Paolo Denti
Sent: Friday, May 04, 2018 9:03 AM
To: Leonid Gibiansky; Bob Leary;
[email protected]<mailto:[email protected]>
Subject: Re: [NMusers] Cmax/Tmax in the DES block
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]>
> <[email protected]><mailto:[email protected]> On Behalf
> Of Leonid Gibiansky
> Sent: Thursday, May 3, 2018 7:59 PM
> To: [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:
>
> 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(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
>
>