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

_______________________________________________________________