Hi,
Thank you for all you help and explanation. I tried with MTIME,MNEXT, and
MPAST. However, I got warning :(WARNING 80) $PK SETS MTIME BUT NOT MTDIFF.
WHEN AN ELEMENT OF MTIME IS RESET, THEN $PK SHOULD ALSO SET MTDIFF=1.
I would like to separate 0-24 hr period to 3 parts, each represented by
a Kin equation.
Here is my codes:
$PK
TMIN = THETA(3)*EXP(ETA(3)) ; time at minimum
TGAP = THETA(4)*EXP(ETA(4)) ; time from Tmin to Tmax
MTIME(1) = TMIN
MTIME(2) = TMIN+TGAP
$DES
T1 = T-24*INT(T/24) ;convert time to 0-24 hr period
FLAG1 = 1-MNEXT(1) ; =1 only during 0-Tmin period
FLAG2 = MPAST(1)-MPAST(2) ; =1 only during Tmin-Tmax period
FLAG3 = 1-MNEXT(2) ; =1 only during Tmax-24 period
DADT(1)= KIN1*FLAG1+KIN2*FLAG2+KIN3*FLAG3-KOUT*A(1)
Is there any mistakes in my coding?. I don't think I need to set MTDIFF=1 as
I don't want to reset MTIME for each individual, am I right?
For MNEXT(1), it will =1 until time past Tmin, right?
Thanks.
Li Li
On Fri, Jun 3, 2011 at 2:44 PM, Alison Boeckmann <
alisonboeckm...@fastmail.fm> wrote:
> My comments are attached in file luann.txt
>
> On Wed, 01 Jun 2011 17:57 -0400, "Luann Phillips"
> <luann.phill...@cognigencorp.com> wrote:
> > Alison,
> >
> > Thank you for the additional information. Especially the part about $DES
> > computing at the event time in a data record for output to the $TABLE. I
> > would like to make sure that I understand a specific point correctly.
> >
> > During a step from t=T1 to t=T2, NONMEM may still take on a value of
> > t=T2+i (i=a tiny number) and compute the equations at this time point.
> > When it is done, it goes back and computes the values at t=T2 for output
> > to the table file.
> >
> > So if you have an expression like the following in your $DES block,
> > would you still need to set flags to 'help' processing along at t=T2.
> > (context of example from a previous note from Li Li)
> >
> > Example:
> > integrating from TIME=T1 to TIME=T2 (which = a multiple of 24)
> >
> > RM=THETA(1)
> >
> > $DES
> >
> > TS=T-24*INT(T/24)
> > KIN=TS*RM
> > DADT(1) = -KIN*A(1)
> >
> > This function for Kin creates a cusp at every multiple of 24. So the
> > limit of Kin as you approach a multiple of 24 from the left is a maximum
> > and as you approach from the right the limit of Kin=0 (similar if not
> > same situation that occurs for an absorption alag). So if an integral
> > step of size h (within the advance from T1 to T2) encompasses a multiple
> > of 24 should flags be set to allow the integration routine to use
> > TS=T- 24*INT(time at beginning of interval h/24) for the full step?
> >
> > Or in terms of the an ALAG situation:
> >
> > What happens if NONMEM is taking a step (size h within an advance from
> > T1 to T2) that encompasses the value of ALAG?
> >
> > Does it use DADT(1) = 0*A(1) until t=ALAG and then switch to
> > DADT(1)=-Ka*A(1) at t >= ALAG (creating a cusp within the interval h)?
> >
> > or
> >
> > Does it use DAD(1) = 0 until t=end of the h interval (even though it's a
> > small bit past ALAG) and then switch to DADT(1)=-Ka*A(1) at the end of
> > the h interval?
> >
> > I really appreciate that you take the time to continue expanding our
> > knowledge about NONMEM.
> >
> > Best Regards,
> >
> > Luann Phillips
> > Director PK/PD
> > Cognigen Corporation
> > (716) 633-3463 ext. 236
> >
> >
> >
> >
> >
> >
> > Alison Boeckmann wrote:
> > > Here is a little background on how it works.
> > >
> > > ADVAN routines such as ADVAN6 use a subroutine from third party sources
> > > to do the integration. For example, ADVAN6 calls DVERK from IMSL,
> > > ADVAN13 calls LSODA, etc. These subroutines are the ones that call DES.
> > > They call DES with various values of T during the integration
> > > ("advance") from T1 to T2. (T1 and T2 are beginning and ending event
> > > time. Typically, these are the times on a pair of event records.) The
> > > integrating subroutine may decide it has enough information after a
> call
> > > with a value of T that is not exactly T2 (might be a little less or a
> > > little more.)
> > >
> > > A change was made with NONMEM V so that, after an advance, DES is
> called
> > > by the ADVAN routine itself (i.e., $DES statements are evaluated) at
> the
> > > exact value of the event time.
> > >
> > > From the NONMEM V Supplemental Guide of March 1998 (guides/supp.pdf):
> > > 39. Displayed DES-defined Items
> > > DES-defined items may be displayed in tables or scatterplots and are
> > > computed at the event time in the data record. With previous versions
> > > of PREDPP, the displayed items might have been computed at a slightly
> > > different time and might have had slightly different values.
> > >
> > > This fixes the difficulty that Luann mentioned.
> > >
> > > Paul says:
> > > A related caveat is that during integration between two time points,
> > > the value of data items (in the $DES block) are set to the values
> > > defined at the end time, not the start time. I'm afraid that I can't
> > > give you a good explanation for this design decision.
> > >
> > > Every variable displayed via $TABLE has the value that was calculated
> by
> > > the last call to DES with the current event record. This is not a
> design
> > > decision; it is inevitable. Values created by PREDPP for display by
> > > NONMEM are stored in a common area (formerly COMMON NMPRD4; now MODULE
> > > NMPRD4). To display values at the start time would require PREDPP to
> > > save the values and to restore that part of NMPRD4. This could be
> rather
> > > difficult. Also, Stuart Beal preferred to see DES-computed values at
> > > the end time and that is why the change for a final call to DES at the
> > > event time was made.
> > >
> > > This also explains why the values for the first event record of the
> > > individual are those from the last event record of the previous
> > > individual. If there is no advance in time, then there is no call to
> > > the integrating subroutine, and no call to DES, so the values in NMPRD4
> > > are unchanged. Warning 48 was new with NONMEM V in 1998. Why did we
> not
> > > at that time add a call to DES from the ADVAN routine with the first
> > > event record? I can't remember. Stuart Beal may have been afraid that
> > > some of the computations in a complicated DES might fail with values
> > > from the first event record, whereas they were ok with values from the
> > > second and subsequent event records.
> > >
> > >
> > >
> > > On Thu, 26 May 2011 16:28 -0400, "Luann Phillips"
> > > <luann.phill...@cognigencorp.com> wrote:
> > >> Hi Lili,
> > >>
> > >> In addition to the information Paul provided. DDTI for a specific row
> > >> should be the last value of T (continuous time) that the integration
> > >> step took. This may not match the event time identically. As NONMEM is
> > >> performing numerical integration between two event times T is taking
> > >> on many values between the two event times (TIME, discrete). During
> > >> this process, it may actually require taking a step that goes a small
> > >> amount past the 2nd event time.
> > >>
> > >> Best regards,
> > >>
> > >> Luann Phillips Director, PK/PD Cognigen Corporation
> > >> (716) 633-3463 ext. 236
> > >>
> > >> Paul Matthias Diderichsen wrote:
> > >>> Hi Lili,
> > >>>
> > >>> On 5/26/2011 1:52 AM, Li Li wrote:
> > >>> > When I output DDT1, the table will be: Subject Time (hr) DDT1
> > >>> > 1 0 4???
> > >>> [...]
> > >>> > 2 0 5???
> > >>> [...]
> > >>> > Why the DDT1 for subject 1 at first time point is 4 and subject 2
> > >>> > at first time point is 5? Why it holds the last time point value
> > >>> > of each subject?
> > >>>
> > >>> In the output, nonmem tells you that this is going to happen:
> > >>>
> > >>> " (WARNING 48) DES-DEFINED ITEMS ARE COMPUTED ONLY WHEN EVENT TIME
> > >>> INCREASES. E.G., DISPLAYED VALUES ASSOCIATED WITH THE FIRST EVENT
> > >>> RECORD OF AN INDIVIDUAL RECORD ARE COMPUTED WITH (THE LAST ADVANCE
> > >>> TO) AN EVENT TIME OF THE PRIOR INDIVIDUAL RECORD. "
> > >>>
> > >>> A related caveat is that during integration between two time points,
> > >>> the value of data items (in the $DES block) are set to the values
> > >>> defined at the end time, not the start time.
> > >>>
> > >>> I'm afraid that I can't give you a good explanation for this design
> > >>> decision.
> > >>>
> > >>> Kind regards,
> > >>>
> > >
> >
> --
> Alison Boeckmann
> alisonboeckm...@fastmail.fm
>
>
