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

From: Leonid Gibiansky <lgibiansky_at_quantpharm.com>
Date: Fri, 4 May 2018 13:15:35 -0400

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>> 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>
>> <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>
>> > 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.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
>

Received on Fri May 04 2018 - 13:15:35 EDT

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