Hi,
I have a question about calculation process in $DES block.
Suppose I have 2 subjects, subject 1 has time point from 0-4hr, subject 2
has time point from 0-5hr.
Suppose I have NONMEM codes as follows:
$DES
DDT1=T
DADT(1)=-Kin*A(1)
When I output DDT1, the table will be:
Subject Time (hr) DDT1 1 0 4??? 1 1 1 1 2 2 1 3 3 1 4 4 2 0 5??? 2
1 1 2 2 2 2 3 3 2 4 4 2 5 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?
Thank you.
lili
Question regarding Calculation Process in $DES BLOCK
Hi Lili,
Quoted reply history
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,
--
Paul Matthias Diderichsen, PhD
Quantitative Solutions B.V.
+31 624 330 706
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,
>
Quoted reply history
> 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,
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.
Quoted reply history
On Thu, 26 May 2011 16:28 -0400, "Luann Phillips"
<[email protected]> 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
[email protected]
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.
>
Quoted reply history
> On Thu, 26 May 2011 16:28 -0400, "Luann Phillips"
> <[email protected]> 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,
Thanks for these helpful explanations of some of the mysterious behaviour of NONMEM.
The call to $DES at the time of the event record makes sense so that the value reported for a $DES variable is the same as the same value if it was calculated in $ERROR.
Would you please confirm that the only reason why NONMEM reports the value of a variable in a $DES block from a previous individual in the first individual record is because "Stuart Beal may have been afraid that some of the computations in a complicated DES might fail with values from the first event record, "?
Given the extensive 'validation' efforts that go into every release of NONMEM both by IDS and by many groups using NONMEM isn't it worth a try to call $DES at TIME=0 before so that the correct result is produced for the TABLE file? If the code is in fact too complicated for anyone to understand anymore at least one can have an empirical attempt to see if this change has any effect -- other then producing the correct value in the TABLE file.
Nick
Quoted reply history
On 2/06/2011 5:29 a.m., 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"
> <[email protected]> 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,
--
Nick Holford, Professor Clinical Pharmacology
Dept Pharmacology& Clinical Pharmacology
University of Auckland,85 Park Rd,Private Bag 92019,Auckland,New Zealand
tel:+64(9)923-6730 fax:+64(9)373-7090 mobile:+64(21)46 23 53
email: [email protected]
http://www.fmhs.auckland.ac.nz/sms/pharmacology/holford
Nick,
I can't confirm anything about why we did or didn't do something
in 1998.
I may easily have forgotten something important.
I think Stuart's concern was that a DES block might contain
code such as
A=B/C
where B and C are data items, and that C might be 0 on the first
event record.
It would put a burden on the user to change the data file.
Or maybe the denominator would be a compartment amount.
Should the call to DES be made before or after bolus doses have
been applied by PREDPP?
The user would probably expect to see values from DES that are
post dose.
Then there is also the issue of Initial Steady State doses.
The user might expect to see values from DES that are at the
initial steady state.
Doses are entered into the system by PREDPP after the advance to
a new time.
PREDPP might have to make a call to the ADVAN routines post dose,
which it does not do right now.
Any change to PREDPP requires a lot of thought.
Its not that the code is too complicated to understand.
Its just that there are so many features that one must think it
all through carefully.
It is up to Bob Bauer and his team to make the change. I asked
Bob about this and he said:
"changing the DES/PREDPP path can
affect user's legacy control stream runs and offer unpleasant surprises.
One way to deal with this is to add an option (you know me, I am into
options), that the user deliberately sets so the PREDPP/DES call
sequence can be altered without affecting the default action."
So we can ask Bob to put this on his list of changes for the next
release.
Quoted reply history
On Fri, 03 Jun 2011 03:24 +1200, "Nick Holford"
<[email protected]> wrote:
Alison,
Thanks for these helpful explanations of some of the mysterious
behaviour of NONMEM.
The call to $DES at the time of the event record makes sense so
that the value reported for a $DES variable is the same as the
same value if it was calculated in $ERROR.
Would you please confirm that the only reason why NONMEM reports
the value of a variable in a $DES block from a previous
individual in the first individual record is because "Stuart Beal
may have been afraid that some of the computations in a
complicated DES might fail with values from the first event
record, "?
Given the extensive 'validation' efforts that go into every
release of NONMEM both by IDS and by many groups using NONMEM
isn't it worth a try to call $DES at TIME=0 before so that the
correct result is produced for the TABLE file? If the code is in
fact too complicated for anyone to understand anymore at least
one can have an empirical attempt to see if this change has any
effect -- other then producing the correct value in the TABLE
file.
Nick
On 2/06/2011 5:29 a.m., 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"
[1]<[email protected]> 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,
--
Nick Holford, Professor Clinical Pharmacology
Dept Pharmacology & Clinical Pharmacology
University of Auckland,85 Park Rd,Private Bag 92019,Auckland,New Zealand
tel:+64(9)923-6730 fax:+64(9)373-7090 mobile:+64(21)46 23 53
email: [2][email protected]
[3] http://www.fmhs.auckland.ac.nz/sms/pharmacology/holford
References
1. mailto:[email protected]
2. mailto:[email protected]
3. http://www.fmhs.auckland.ac.nz/sms/pharmacology/holford
--
Alison Boeckmann
[email protected]
My comments are attached in file luann.txt
Quoted reply history
On Wed, 01 Jun 2011 17:57 -0400, "Luann Phillips"
<[email protected]> 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"
> > <[email protected]> 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
[email protected]
Luann,
For ALAG parameters, PREDPP creates an event time. It advances
the system (integrates the differential eqns) to the event time.
Even if the model describes an abrupt change at the event time, the
same values of DADT should be used across the change point. The
integrating subroutine may go a little past the end time to refine
its value at the end point. It should not be getting a sudden change
from DES. That will confuse it, and is inappropriate. The derivatives
at the event time are left hand deriviatives, as if the DADT stayed
the same.
You ask:
--------
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?
-------
Basically the latter. However, I can't understand what model you
are describing. At ALAG, KA changes from 0 to a non-zero value. Is
this a case where there is no absorption till ALAG, and then the
absorption process starts? Or, iF you are thinking of a bolus dose
at time ALAG, then the equations are
DADT(1)=-KA*0 till t=ALAG (because A1 is 0)
DADT(2)=-KA*A(1) when t>=ALAG
PREDPP does not add the dose into the compartment while the first
advance (to ALAG1) is in process. It waits till the advance is
finished, applies the dose, and then starts a new advance to the
next event time. That is why I can use t=ALAG in both equations;
the end point of the first advance is the starting point of the
next advance, though PREDPP has changed A(1). (With $DES, read
"integration interval" for "advance")
Now about Li Li's original model with INT function. In general, I
don't comment on complicated PK/PD models; there are many people
on the nmusers list who are far more experienced than I am at
modelling and I am unfamiliar with the physiology of the models.
However, abrupt changes in DADT values at time points that depend
on thetas and etas reminds me of models for EHC (Entero Hepatic
Clearance). As I recall, the best way to handle abrupt changes was
to model the change times as event times. Originally ALAG times
were used for this; as I recall the MTIME (model event time) feature
was provided to do the same thing, but avoid the need for artificial
compartments and doses.
I think LiLi's model should be using MTIMEs for TMIN and TGAP.
There should be no IF/THEN statements in $DES. Instead, use the
MPAST and MNEXT indicator variables in DADTs to select different
terms (i.e., compute different values of DADT depending on values
of T) . During the integration to an event time, values of MPAST
and MNEXT will not change, even if the integrating subroutine goes
a little past the end time.
Maybe some one among the users can supply an example of EHC or a
model that uses MTIME for a similar purpose, or can give suggestions
tailored to Li Li's model.
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
Quoted reply history
On Fri, Jun 3, 2011 at 2:44 PM, Alison Boeckmann <
[email protected]> wrote:
> My comments are attached in file luann.txt
>
> On Wed, 01 Jun 2011 17:57 -0400, "Luann Phillips"
> <[email protected]> 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"
> > > <[email protected]> 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
> [email protected]
>
>
Li Li,
Li,
I think, you can avoid using MTIME (that is more useful for the ADVANs with
analytical solutions) and use something like:
$DES
T1 = T-24*INT(T/24) ;convert time to 0-24 hr period
KIN = KIN3
IF(T1.LE.TMAX) KIN=KIN2 ;24 > TMAX > TMIN defined in PK block
IF(T1.LE.TMIN) KIN=KIN1
DADT(1)= KIN-KOUT*A(1)
....
Leonid
Original Message:
-----------------
Quoted reply history
From: Li Li [email protected]
Date: Fri, 3 Jun 2011 17:04:09 -0400
To: [email protected], [email protected],
[email protected], [email protected]
Subject: Re: [NMusers] Question regarding Calculation Process in $DES BLOCK
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 <
[email protected]> wrote:
> My comments are attached in file luann.txt
>
> On Wed, 01 Jun 2011 17:57 -0400, "Luann Phillips"
> <[email protected]> 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"
> > > <[email protected]> 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
> [email protected]
>
>
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://link.mail2web.com/mail2web