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.de...@uct.ac.za <mailto:paolo.de...@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-nmus...@globomaxnm.com
    <mailto:owner-nmus...@globomaxnm.com>
    <owner-nmus...@globomaxnm.com>
    <mailto:owner-nmus...@globomaxnm.com> On Behalf Of Leonid Gibiansky
    > Sent: Thursday, May 3, 2018 7:59 PM
    > To: nmusers@globomaxnm.com <mailto:nmusers@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>(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.de...@uct.ac.za <mailto:paolo.de...@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


Reply via email to