Update for NONMEM bug list October 13, 2004
From: "Bachman, William (MYD)" bachmanw@iconus.com
Subject: [NMusers] Update for NONMEM bug list October 13, 2004
Date: Thu, October 14, 2004 8:45 am
Revision of the buglist for NONMEM: October 13, 2004
Changes Made: Bugs XIII and XIV have been added. Please note that these
additions are related to the use of the raw-data data item.
PDF version of file, NONMEMbugs13-10-2004.pdf, may be found at:
ftp://ftp.globomaxnm.com/Public/nonmem/buglist/
or
http://www.globomaxservice.com/products/nonmem.html
nmconsult@globomaxnm.com
GloboMax
The Strategic Pharmaceutical Development Division of ICON plc
7250 Parkway Drive, Suite 430
Hanover, MD 21076
Voice: (410) 782-2205
FAX: (410) 712-0737
___________________________________________________________________________
This is an evolving official list of bugs concerning the
distributed version of the NONMEM software.
Where fixes are given, these may be optionally installed, depending
on whether the licensee desires to correct the problem. It is best if
fixes are installed by an individual familiar with FORTRAN.
If a fix is installed, neither the version nor level number of
the code will be regarded as having been changed.
For some bugs, fixes are not given, rather work-arounds are given.
For some bugs, both fixes and work-arounds are given, and in some cases
neither fixes nor work-arounds are given.
Lists of conditions numbered (1), (2), (3) etc. are to be interpreted
as conjunctions of the numbered conditions ((1) and (2) and (3) etc.) except
where explicitly noted otherwise.
A. Bugs with NONMEM Version V Level 1.1
(I)
Output may be incorrect when
(1) the SUBPROBLEMS option appears on the $SIMULATION record with value
greater than 1
(2) there is no $SCATTERPLOT record
(3) either there are no thetas or no epsilons
If the output is indeed incorrect, there should be a clear indication of
this.
Work-around: Avoid a problem specification as described. If there are
no thetas (epsilons), include a dummy theta (or epsilon, if allowed)
whose initial estimate is fixed to 0.
(II)
The value output for the objective function may be incorrect when
the NUMERICAL and MAXEVALS=0 options appear on the $ESTIMATION record
Fix:
In NONMEM routine OBETA2, after the statement labeled 30, add
NRETA=K
NAETA=NRE1-NRETA
(III)
The output may be incorrect when
(1) a population conditional estimation method is used or posthoc estimates
are obtained
(2) a mixture model is used
(3) the dimension of OMEGA exceeds 4
If the output is indeed incorrect, there should be a clear indication of
this
(there can be an abnormal operating system termination).
Fix:
In NONMEM routine FNLETA, replace the statement
DO 342 I=1,LM1
with
DO 342 I=1,MCMAX
(IV)
A table file will be incorrect when
(1) there is a pair of contiguous problem specifications, each with a $TABLE
record
(2) with the first specification, a FILE option appears on the
last $TABLE record; with the second specification, a FILE option appears on
the first $TABLE record; both FILE options use the same file name
(3) with the second specification, the FORWARD option does not appear on the
first $TABLE record
The first $TABLE record of the second problem specification should be
treated
as though the NOFORWARD option appears on the record, either because the
NOFORWARD option along with the FORWARD option do not appear on the $TABLE
record, and the NOFORWARD option is the default option, or because the
NOFORWARD option explicitly appears on the record. However, due to the bug,
in
circumstances (1)-(3) the $TABLE record will be treated as though the
FORWARD
option appears on the record.
Work-around: Use two different file names with the two FILE options.
Discussion: The following helpful fact is undocumented. There is an
exception as to when the NOFORWARD option is the default option. With a
series of contiguous $TABLE records in a given problem specification, each
having a FILE option that uses the same file name, the second and subsequent
$TABLE records in the series are always treated as though the FORWARD option
appears on these records, because otherwise the presence of these
records makes no sense.
(V)
A table file will be incorrect when
(1) with a given problem specification, there are one or more $TABLE
records,
and the NSUBS option appears on a $SIMULATION record with value 2 or more
(so that there are two or more subproblems)
(2) a FILE option appears on the first and last $TABLE records of the
problem specification, and both FILE options use the same file name
(3) the FORWARD option does not appear on the first $TABLE record
The first $TABLE record of the problem specification should be treated
as though the NOFORWARD option appears on the record, either because the
NOFORWARD option along with the FORWARD option do not appear on the $TABLE
record, and the NOFORWARD option is the default option, or because the
NOFORWARD option explicitly appears on the record. However due to the bug,
in
circumstances (1)-(3), with the second or subsequent subproblems, the $TABLE
record will be treated as though the FORWARD option appears on the record.
Work-around: Probably the user would actually prefer that the $TABLE record
be
treated as though the FORWARD option appears on it (see the discussion
point below). But this is not what is suppose to happen, and if
indeed it is desired that the NOFORWARD option be recognized, then
after the last $TABLE record, insert an additional $TABLE
record using a FILE option with a different file name. This file name
can be that of the system junk file, so that no table is really seen by
the user.
Discussion: The following helpful fact is undocumented. There is an
exception as to when the NOFORWARD option is the default option. With a
series of contiguous $TABLE records in a given problem specification, each
having a FILE option that uses the same file name, the second and subsequent
$TABLE records in the series are always treated as though the FORWARD option
appears on these records, because otherwise the presence of these
records makes no sense. It also really makes no sense to use the
NOFORWARD option with any $TABLE record - regardless of the file name
used by the FILE option - in a problem specification with an NSUBS value of
2
or more. So with NONMEM Version VI, this will constitute another exception
as to when the NOFORWARD option is the default option.
(VI)
When each of two different problems within the scope of a superproblem use
the same file as either a NONMEM data file, Model Specification Input file,
or Model Specification Output file, or table file, an abnormal operating
system
termination may arise. If these circumstances do not lead to such a
termination, the user should not be concerned.
Fix:
Before each of the two instances of the statement
I2=0
in routine SUPER, insert the statement
IF (I2.EQ.1) CLOSE (UN(2))
Before each of the two instances of the statement
I3=0
in routine SUPER, insert the statement
IF (I3.EQ.1) CLOSE (UN(3))
Before each of the two instances of the statement
I4=0
in routine SUPER, insert the statement
IF (I4.EQ.1) CLOSE (UN(4))
Work-around: Avoid such circumstances. An example of where these
circumstances arise may be found in the Help Guide, Superproblem
Example 1. For this example, the file 'simulation' is used as a table
file in problem 2 and as a NONMEM data file in problem 3. This can be
avoided by taking the data set of problem 3 to be the internal data set
created with problem 2 (remove both the $TABLE record of problem 2 and the
$DATA record of problem 3).
(VII)
When a mixture model is used, estimates of etas available to the PRED
routine
during problem finalization (i.e. when ICALL=3) are always those for the
first submodel. With each individual they should be those for the
submodel to which the individual is classified.
(VIII)
The statistic ETABAR and results from the Centering First-Order Conditional
Estimation method are incorrect when
(1) a mixture model is used
(2) the mixture probability of either the first or last subpopulation is set
to 0.
Work-around: Usually, if a mixture probability is being set to 0, this
is being done for all individuals and for all values of the
population parameters. In this case, simply remove any reference to the
first (or last) subpopulation from routine MIX. Otherwise, try to keep
the first and last subpopulation from being one with a mixture probability
equal to 0.
(IX)
NONMEM output will be faulty when an individual exists whose data
(1) are not influenced by a particular eta (eta1)
(2) are influenced by an eta which is correlated (via the OMEGA matrix) with
eta1.
See discussion in the NONMEM Archive :
http://www.cognigencorp.com/nonmem/nm/99nov142002.html
(X)
NONMEM output is faulty when
(1) there are correlated epsilons across L2 record
(2) conditional estimation is used
See discussion in the NONMEM Archive :
http://www.cognigencorp.com/nonmem/nm/99dec042003.html
Fix:
In NONMEM routine OBJ2
Replace the two lines of code:
IQ=0
IF (MODE.EQ.2) THEN
with:
IF (MODE.NE.3) THEN
IQ=0
(XI)
With a mixture model, The ETABAR statistic is not computed correctly.
There is no fix or work-around.
(XII)
During a copying pass with COMACT=1 and with the records of the first
individual, the initially available value of a variable whose values are
stored in the Save Region will be incorrect when
(1) a population conditional estimation method is used or posthoc estimates
are obtained
(2) a mixture model is used
Discussion: During a copying pass values of variables that will be displayed
in scatterplots and tables are computed. With condition (1), eta variables
will often have nonzero values, but during a copying pass with COMACT=1,
eta variables have the values 0. Values of variables defined in abbreviated
code during such a pass are "typical values". During a copying pass with
COMACT=2, the values of the eta variables are the conditional estimates of
the eta variables. There will be as many copying passes with COMACT=1 as
there
are mixture subpopulations, and with each such pass, the value of the
variable
MIXNUM will be incremented. There then follow a set of copying passes with
COMACT=2. Again, there will be as many copying passes with COMACT=2 as
there
are mixture subpopulations, and with each such pass, the value of the
variable MIXNUM will be incremented. By virtue of the specification of the
COMSAV option in the $ABBREVIATED record, the value of a variable may be
stored in the Save Region. (If such a variable is defined in abbreviated
code,
it will be of the form COM(n).) During the second or subsequent copying
pass and with a given record, the value initially available in the Save
Region (i.e. the value used with the very first user-defined computation
involving the variable) will be the final value stored with the same record
during the preceding copying pass. (During any pass, the initially
available
value may be left unaltered.)
Workaround: Make the first individual record a dummy record (the MDV items
of all the data records comprising the individual record should be 1.)
Fix:
In NONMEM routine NP4F, replace the statement
IF (ICOM4.EQ.1.AND.JJ.EQ.1.AND.I.EQ.1) THEN
with
IF (ICOM4.EQ.1.AND.JJ.EQ.1.AND.I.EQ.1.AND.MCALL.EQ.1) THEN
(XIII)
Use of the raw-data data item will lead to generally unpredictable
problems when
(1) the product of the number of data records (n1) and the number of data
items per data record (n2) exceeds lim1*20, where lim1 is the value set for
the
constant LIM1 in file NSIZES at installation time
(2) a data record whose number exceeds lim1*20/n2 is also a template record
Work-around: Move the individual record containing the template record
to the beginning of the data set. Alternatively, reinstall NONMEM,
increasing the value of lim1.
Fix:
In NONMEM routine COMMRG, replace the statement
CALL DAT1 (1,0,0)
preceding statement 210 with
CALL DAT1 (INX+1,0,0)
Discussion: It is always helpful to insert any template records in
the first individual record, and perhaps to insert corresponding comment
records there as well, so that the template records are readily noted upon
examining the data set. If this is done, the work-around described above is
automatically implemented.
(XIV)
When the length of the SAVE region (i.e. the value assigned to COMSAV)
exceeds 20, use of the raw-data data item will lead to generally
unpredictable problems.
Work-around: When the raw-data data item is used, keep COMSAV below 20.
Fix:
In NONMEM routine COMMRG, replace the statements
IF (INIT4.NE.0) THEN
DO 159 K=1,INIT4
preceding statement 159 with
IF (IDAT66.EQ.1) THEN
DO 159 K=1,NP4A
_______________________________________________________________