Re: Question regarding Calculation Process in $DES BLOCK
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