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
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
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
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
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
Quoted reply history
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
Leonid Gibiansky
Sent: Thursday, May 3, 2018 7:59 PM
To: [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
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
Hi Bob,
You may find the “finedata” program in the /util subdirectory convenient for
this purpose. It was introduced with v7.3 and expanded in v7.4.
Cheers… Brian
Quoted reply history
From: [email protected] [mailto:[email protected]] On
Behalf Of Bob Leary
Sent: Friday, May 04, 2018 11:02 AM
To: Leonid Gibiansky; [email protected]
Subject: RE: [NMusers] Cmax/Tmax in the DES block
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:
http://cognigencorp.com/nonmem/current/2007-December/4125.html
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
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
Quoted reply history
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
>
>
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
Quoted reply history
On Fri, May 4, 2018 at 11:03 AM, Paolo Denti <[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] <[email protected]>
> <[email protected]> On Behalf Of Leonid Gibiansky
> > Sent: Thursday, May 3, 2018 7:59 PM
> > To: [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(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
> >
> >
> >
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
>
>
This is interesting overshoot problem. As the infusion on/off causes the solver
discontinuity problem, the discontinuity will produce the overshoot.
Please find a good report from MIT in the link:
https://ocw.mit.edu/courses/mathematics/18-03-differential-equations-spring-2010/readings/supp_notes/MIT18_03S10_sup.pdf
“Notice the “overshoot” near the discontinuities. “ at Page 77
We have nice solutions from Phoenix to handle the discontinuity issues.
Kevin
Quoted reply history
From: [email protected] [mailto:[email protected]] On
Behalf Of Kyle Baron
Sent: Friday, May 4, 2018 1:21 PM
To: Leonid Gibiansky <[email protected]>
Cc: Paolo Denti <[email protected]>; Bob Leary <[email protected]>;
[email protected]
Subject: Re: [NMusers] Cmax/Tmax in the DES block
Here is some code to reproduce / demonstrate the observation in R:
https://github.com/metrumresearchgroup/mrgsolve/issues/369
I think it captures the essence of what you were doing, Leonid. The comparison
against the analytical solution just shows that the ODEs are still giving the
right answer (the overshoot isn't wrong; just a feature of the solver).
Kyle
On Fri, May 4, 2018 at 12:15 PM, Leonid Gibiansky
<[email protected]<mailto:[email protected]>> wrote:
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]>
<mailto:[email protected]<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]<mailto:[email protected]>>
<[email protected]<mailto:[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]<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
> 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
>
>
>
Thanks!
Looking on ADVAN6 code I cannot figure out whether it has the same problem (with over-shooting the time interval). I guess not, could you confirm?
Thanks
Leonid
Quoted reply history
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
> >> >
> >> >
> >> >
ADVAN6 does not overshoot. The others do. ADVAN8 does not have an option
available to avoid overshoot (at least I could not find one looking through the
code). ADVAN9, ADVAN13, ADVAN14 and ADVAN15 (all from Livermore Labs), have
the ITASK option to control overshoot behavior, and I can have this option
controlled at the control stream level.
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: Leonid Gibiansky [mailto:[email protected]]
Sent: Saturday, May 05, 2018 9:00 AM
To: Bauer, Robert; [email protected]<mailto:[email protected]>
Subject: Re: [NMusers] Cmax/Tmax in the DES block
Thanks!
Looking on ADVAN6 code I cannot figure out whether it has the same
problem (with over-shooting the time interval). I guess not, could you
confirm?
Thanks
Leonid
I take the post-hoc PK parameters table, read them into SAS and execute the ODE
model with small time steps using proc model.
Sort the results by Cmax descending and select first observation for Cmax and
Tmax.
Precision is based solely on the number of time points in the data step. The
table of parameters can be expanded to include other summary measures, and is
saved as a CSV file for SAS dataset for further reporting.
Kind regards,
Daren
Daren Austin
GSK Senior Fellow
Senior Director, Clinical Pharmacology
Clinical Pharmacology Modelling & Simulation
Quantitative Sciences
GSK
Stockley Park West, 1-3 Ironbridge Road, Uxbridge, Middlesex, UB11 1BT, UK
Email [email protected]
Mobile +44 7712 670097
Tel +44 20 89903689
gsk.com | Twitter | YouTube | Facebook | Flickr
Quoted reply history
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Leonid Gibiansky
Sent: 04 May 2018 00:59
To: [email protected]
Subject: [NMusers] Cmax/Tmax in the DES block
EXTERNAL
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
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
GSK monitors email communications sent to and from GSK in order to protect GSK,
our employees, customers, suppliers and business partners, from cyber threats
and loss of GSK Information. GSK monitoring is conducted with appropriate
confidentiality controls and in accordance with local laws and after
appropriate consultation.
________________________________
This e-mail was sent by GlaxoSmithKline Services Unlimited
(registered in England and Wales No. 1047315), which is a
member of the GlaxoSmithKline group of companies. The
registered address of GlaxoSmithKline Services Unlimited
is 980 Great West Road, Brentford, Middlesex TW8 9GS.