Re: [NMusers] Cmax/Tmax in the DES block

From: Leonid Gibiansky <lgibiansky_at_quantpharm.com>
Date: Sat, 5 May 2018 12:00:08 -0400

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

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
>
> Robert.Bauer_at_iconplc.com <mailto:Robert.Bauer_at_iconplc.com>
>
> www.iconplc.com <http://www.iconplc.com/>
>
> *From:*owner-nmusers_at_globomaxnm.com
> [mailto:owner-nmusers_at_globomaxnm.com] *On Behalf Of *Leonid Gibiansky
> *Sent:* Friday, May 04, 2018 10:16 AM
> *To:* Kyle Baron; Paolo Denti
> *Cc:* Bob Leary; nmusers_at_globomaxnm.com
> *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 <paolo.denti_at_uct.ac.za
> <mailto:paolo.denti_at_uct.ac.za%20%0b>> <mailto:paolo.denti_at_uct.ac.za>> 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: owner-nmusers_at_globomaxnm.com
> <mailto:owner-nmusers_at_globomaxnm.com>
> >> <mailto:owner-nmusers_at_globomaxnm.com>
> >> <owner-nmusers_at_globomaxnm.com <mailto:owner-nmusers_at_globomaxnm.com>>
> >> <mailto:owner-nmusers_at_globomaxnm.com> On Behalf Of Leonid Gibiansky
> >> > Sent: Thursday, May 3, 2018 7:59 PM
> >> > To: nmusers_at_globomaxnm.com <mailto:nmusers_at_globomaxnm.com>
> <mailto:nmusers_at_globomaxnm.com>
> >> > 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
> >> >
> >> >
> >> > NOTICE: The information contained in this electronic mail
> >> message is intended only for the personal and confidential
> >> > use of the designated recipient(s) named above. This message may
> >> be an attorney-client communication, may be protected
> >> > by the work product doctrine, and may be subject to a protective
> >> order. As such, this message is privileged and
> >> > confidential. If the reader of this message is not the intended
> >> recipient or an agent responsible for delivering it to
> >> > the intended recipient, you are hereby notified that you have
> >> received this message in error and that any review,
> >> > dissemination, distribution, or copying of this message is
> >> strictly prohibited. If you have received this
> >> > communication in error, please notify us immediately by
> >> telephone and e-mail and destroy any and all copies of this
> >> > message in your possession (whether hard copies or
> >> electronically stored copies). Thank you.
> >> >
> >> > buSp9xeMeKEbrUze
> >> >
> >
> > --
> > ------------------------------------------------
> > 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.denti_at_uct.ac.za <mailto:paolo.denti_at_uct.ac.za>
> > ------------------------------------------------
> >
> > Disclaimer - University of Cape Town This email is subject to UCT
> > policies and email disclaimer published on our website at
> > http://www.uct.ac.za/main/email-disclaimer
> > <http://www.uct.ac.za/main/email-disclaimer> or obtainable from +27
> > 21 650 9111. If this email 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
> > https://csirt.uct.ac.za/page/report-an-incident.php
> > <https://csirt.uct.ac.za/page/report-an-incident.php>.
> >
> >
> >
> >
> > --
> > Kyle Baron, PharmD, PhD
> > Senior Scientist
> > Metrum Research Group
> >
>
>
>
> 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
>

Received on Sat May 05 2018 - 12:00:08 EDT

This archive was generated by hypermail 2.3.0 : Fri Sep 27 2019 - 16:59:30 EDT