NONMEM Users Network Archive

Hosted by Cognigen

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

From: Leonid Gibiansky <lgibiansky_at_quantpharm.com>
Date: Fri, 4 May 2018 14:55:37 -0400

I am not sure that this example is similar. There is no over-shoot in
the solution in Nonmem case. This is only visible/relevant when we hack
inside of the $DES block, and look over the extremes over the
integration interval that it happens to be larger than the interval of
interest for the solution. In effect, we are catching max/min over
intermediate computations instead of the final solution.
Leonid


On 5/4/2018 1:56 PM, Kevin Feng wrote:
> 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
>
> *From:*owner-nmusers_at_globomaxnm.com
> [mailto:owner-nmusers_at_globomaxnm.com] *On Behalf Of *Kyle Baron
> *Sent:* Friday, May 4, 2018 1:21 PM
> *To:* Leonid Gibiansky <lgibiansky_at_quantpharm.com>
> *Cc:* Paolo Denti <paolo.denti_at_uct.ac.za>; Bob Leary
> <Bob.Leary_at_certara.com>; nmusers_at_globomaxnm.com
> *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
> <lgibiansky_at_quantpharm.com <mailto:lgibiansky_at_quantpharm.com>> 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
> <paolo.denti_at_uct.ac.za <mailto:paolo.denti_at_uct.ac.za>
> <mailto:paolo.denti_at_uct.ac.za <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
> <mailto:owner-nmusers_at_globomaxnm.com>>
>     <owner-nmusers_at_globomaxnm.com
> <mailto: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 <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:email%3Apaolo.denti_at_uct.ac.za>
> <mailto: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
>
>
>
> --
>
> Kyle Baron, PharmD, PhD
>
> Senior Scientist
> Metrum Research Group
>

Received on Fri May 04 2018 - 14:55:37 EDT

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to: nmusers-request_at_iconplc.com. Once subscribed, you may contribute to the discussion by emailing: nmusers@globomaxnm.com.