From: "Bachman, William (MYD)" bachmanw@iconus.com
Subject: [NMusers] new buglist for NMTRAN 07FEB2005 
Date: Thu, February 10, 2005 8:54 am

There is a new buglist for NMTRAN.  
Change Made:  For bug XV the description has been revised and the fix has
been changed and expanded to include additional changes to NMTRAN routines.
This is in response to Leonid Gibiansky's recent problem regarding the use
of WIDE and > 9999 records.  
PDF version of file, NMTRANbugs07FEB2005.pdf, may be found at:

ftp://ftp.globomaxnm.com/Public/nonmem/buglist/

or

http://www.globomaxservice.com/products/NMTRANbugs07FEB2005.pdf


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.

C. Bugs with NM-TRAN Version III Level 1.1

(I)
NM-TRAN (and hence NONMEM) output may be incorrect when

(1) the name (N) of a type of data item is listed in the $CONTR record and
is 
used in $MIX abbreviated code
(2) some synonym (A=B) and/or "DATE=DROP" preceeds N in the $INPUT record

If there is only one data item name listed in the $CONTR record, there will
be a
spurious NM-TRAN error message.  If there are two or more data item names
listed in the $CONTR record, there may be a spurious error message, or there

may be no error message and the generated code for MIX will be wrong.

Work-around: 
Construct a new data set such that (2) above will not happen.
That is, the new data set will be exactly like the old data set, except
for having a new column that is exactly like the column in the original
data set with the N-type data items (column C), and the new column will be 
placed before the columns with the A-type data items and/or the DATE data
items.
Actually column C itself can be deleted, but if it is not, use N=DROP.

Work-around:
Avoid using the synonym A=B.

(II)
NM-TRAN (and hence NONMEM) output is incorrect when

(1) ADVAN12 is used
(2) the variable SC is defined in $PK abbreviated code

SC should be interpreted as the scale parameter for compartment 2 (the
central compartment).  Due to the bug, it is interpreted as the scale
parameter for compartment 1 (the drug depot).

Work-around:  Use the variable S2, rather than SC.

(III)
Generated $DES ($AES) code can be incorrect when a condition in a
conditional 
statement in $DES ($AES) involves ICALL.EQ.4.

Work-around:  Such a conditional statement in $DES ($AES) should be avoided.
(It will not be permitted by NM-TRAN Version VI.)

(IV)
The objective function can be incorrectly computed when

(1) the NM-TRAN Library PK routine is used
(2) a ALAG parameter is modeled with an eta
(3) DOSTIM is used as a right-hand quantity in an assignment statement in
$PK
(4) the Laplacian estimation method is used

Most PK codes only use DOSTIM in a condition in a conditional statement
(and not in an assignment statement), and in such a case no problem arises

Work-around: Avoid the use of the NM-TRAN Library and/or the Laplacian
estimation method.
  
(V)
The values of PK parameters will not be simulated when

(1) the PK parameters to be simulated are defined in a simulation block
of $PK
(2) the block ends with a RETURN statement

Work-around: 
(1) Use the ONLYSIMULATION option on the $SIMULATION record and thus avoid 
using the simulation block, or
(2) Place the simulation block at the end of $PK, and thus avoid using
the RETURN statement. 

(VI)
NM-TRAN translation of abbreviated code will be faulty when
a random variable is defined in an ELSE and then redefined in another ELSE
which is nested within the first ELSE.
See discussion in the NONMEM Archive :
http://www.cognigencorp.com/nonmem/nm/99aug272000.html
discussant Alison Boeckmann


(VII)
The error message:
 202  FORTRAN SYNTAX IS INCORRECT OR INAPPROPRIATE IN THIS CONTEXT.

appears - but it should not appear - when

(1) A WRITE or PRINT statement is used in abbreviated code
(2) the next line of abbreviated code is an assignment statement for a
variable whose name contains both letters and numbers

Work-around:  Avoid using a variable name such as S1 as the left-hand
quantity in such an assignment statement.

(VIII)
The error message:
 469  RANDOM VARIABLE MAY NOT BE REDEFINED IN SAME "THEN" OR "ELSE" BLOCK.
may not appear - but it should appear - when

(1) a random variable is conditionally defined
(2) the variable is redefined in the same THEN or ELSE block in which
it was defined
E.g.

     IF (NEWIND.LE.1) THEN
        SUM=ETA(2)
        SUM=SUM+.25
     ENDIF

(IX)
The error message:
 137 $SUBROUTINES: THIS SS CANNOT BE USED WITH THIS ADVAN.
does not appear - but it should appear - when SS6 is used with ADVAN9.

(X) 
When a line of abbreviated code contains "END" (which is not allowed)
instead of "ENDIF", the error message indicates the wrong line of
abbreviated 
code.

(XI) 
An incorrect NM-TRAN data file may be used when

(1) there are multiple problem specifications
(2) with the second or subsequent problem specification (B) either $DATA *
(i.e. asterisk) is used, or what is equivalent, the $DATA record is 
omitted (indicating that with this problem, the NONMEM data set will be
the one stored internally with the previous problem)
(3) the problem specifications immediately before B (A) and after B (C)
have $DATA records with different filenames.
The data file used with C may be incorrect

Fix:
In routine GENERC replace the line

     PINFNM=INFNAM

with

     IF (INFNAM.NE.' '.AND.INFNAM.NE.'*') PINFNM=INFNAM

(XII)
A compiler error occurs when with $PRED, the argument of any of the 
functions: LOG, LOG10, EXP and SQRT is a data item, and a PRED routine is 
generated (in contrast to the NM-TRAN Library PRED routine being used).

Work-around:  Use code such as

D=DV
A=LOG(D)

(XIII)
Steady-state kinetics will not be computed when

(1) there are multiple problem specifications
(2) with the second or subsequent problem specification SS is listed first
in the $INPT record
(3) an SS routine is not listed in the $SUBROUTINES record

Work-around:
Construct a new data set such that (2) above will not happen.
That is, the new data set will be exactly like the old data set, except
for having a new column that is exactly like the first column in the
original
data set, and the new column will be placed after the first column.
Actually the first column itself can be deleted, but if it is not, use DROP
with the first column.

Work-around:
Include the name of the SS routine in the $SUBROUTINES record.


(XIV)
NM-TRAN translation of clock times to elapsed times can be faulty.
All elapsed times resulting from clock-time translation should have two
digits
to the right of the decimal point.  Certain elapsed times greater than
999.99
hours (41.6 days) are unpredictably and mistakenly truncated so that
they contain only one digit to the right of the decimal point.
See discussion in the NONMEM Archive :
http://www.cognigencorp.com/nonmem/nm/99apr192002.html

Fix:
In routine READ3 replace the line

       ELSEIF (VALUE(KK+J).GE.1000.0.AND.WIDE.NE.'Y') THEN

with

       ELSEIF (VALUE(KK+J).GE.1000.0.AND.WIDE.NE.'Y'.AND.NSP.EQ.1) THEN

(XV)
The error message:
  $DATA: WIDE CANNOT BE USED - FILE CONTAINS MORE THAN 9999 RECS.
may appear - but it should not appear - when 

(1) the WIDE option appears on the $DATA record
(2) there are more than 9999 records in the data set
(3) the control stream consists of a single problem

Fix:
In routine READF insert these two statements anywhere among the other 
declaration statements

      COMMON/COMEND/ENDFIL
      LOGICAL ENDFIL

and change the statement

      IF (INOBS.GT.9999.AND.WIDE.EQ.'Y') CALL ERRMSG(283,' ',1)

to

      IF (INOBS.GT.9999.AND.WIDE.EQ.'Y'.AND..NOT.ENDFIL)
     X CALL ERRMSG(283,' ',1)

In routine GETITM insert this statement anywhere among the other 
declarations

      COMMON/COMEND/ENDFIL

In routine CHKDAT change the statement

      IF (MKFDAT.AND.INOBS.GT.K9999) THEN

to

      IF (MKFDAT.AND.INOBS.GT.K9999.AND.WIDE.NE.'Y') THEN

(XVI)
NM-TRAN translation of TIME data items is faulty when

(1) NM-TRAN infers that the data are single-subject data
(2) the name ID is listed in the $INPUT record (as ID or ID=L1)
(3) some synonym (A=B) and/or "DATE=DROP" preceeds ID in the $INPUT record

Time translation occurs when either clock times are present in the
NM-TRAN data set or DATE items appear.  Usually, when time translation
occurs 
with single-subject data, 'ID' does not appear in the $INPUT record
(though 'L1' may appear), in which case the TIME data item on the first 
record of the data set is translated to 0, and subsequent TIME data items
are 
translated to times relative to 0.  When ID is listed in the $INPUT record, 
with every data record where the ID data item changes value, the TIME data 
item is translated to 0, and subsequent TIME data items (up to the next
change
in ID value) are translated to times relative to 0.  Due to the bug, if ID
is listed near the beginning of the $INPUT record, different data from the
ID 
data items are used in the process of time translation.  If the ID is
listed near the end of the $INPUT record, the ID data items are
ignored in the process of time translation (i.e. all TIME data items 
subsequent to the one on the first data record are translated to times 
relative to 0.)

Work-around:
Construct a new data set such that (3) above will not happen.
That is, the new data set will be exactly like the old data set, except
for having a new column that is exactly like the column in the original
data set with the ID data items (column C), and the new column will be 
placed before the columns with the A-type data items and/or the DATE data
items.
Actually column C itself can be deleted, but if it is not, give this
column a name N different from ID and use N=DROP.

Work-around:
Avoid using the synonym A=B.

(XVII)
The constant LNP4 in files TSIZES is set at installation time to the default

value of 1000.  An error occurs during compilation of generated code when 
LNP4 is set to a value greater than 9999.  However, a value greater
than 9999 is of little practical value.

When the option COMRES=n, n>0, is used in the $ABBREVIATED record
or when verbatim code is used, and when LNP4 is set to a value greater than
1000, an error occurs during compilation of generated code.

Fix:
In routine GENCOM replace the two lines of code:

       WRITE(LINE,'(A,I4.4,A)') 'DIMENSION COM(',COMMAX,')'
       LL=19

with:

       WRITE(LINE,'(A,I6.6,A)') 'DIMENSION COM(',COMMAX,')'
       LL=21

(XVIII)
The data may be mistakenly interpreted as single-subject data when

(1) there are multiple problem specifications
(2) in the second or subsequent problem specification, a $MSFI record
appears without the NPOP option

With the problem specification where the $MSFI record appears without the 
NPOP option, the data are misinterpreted as single-subject data.
An error message will make it clear that the data are being misinterpreted.

Work-around:  Include the NPOP option.

(XIX)
Fatal error message 386 spuriously arises when abbreviated code such as

IF (condition) statement

is used, where

(1) the condition includes a test of ICALL or COMACT, and either
(2a) the statement is a WRITE/PRINT statement that uses either ICALL or
COMACT 
in the output list, or
(2b) the statement is an assignment statement that uses either ICALL or
COMACT as a right-hand quantity

Work-around:
Instead of the above IF statement, use

IF (condition) THEN
statement
ENDIF

(XX)
There arises a faulty end-of-record condition when

(1) a superproblem is used
(2) the data set is too large

Work-around:  Try reinstalling NONMEM, setting LIM1 (the size of buffer 1)
to a value large enough that for each of the problems in the superproblem,
the entire data set for the problem can be stored in computer memory
throughout
the NONMEM run.  (See Guide III, chapter III, section 2.9.4.)

(XXI)
A constant used in abbreviated code may not be translated into a double 
precision constant when

(1) neither the SP nor LIBRARY options appear in the $SUBROUTINE statement
(2) a statement of form

IF (condition1.AND.condition2) ...
or
IF (condition1.OR.condition2) ...

is used in abbreviated code
(3) condition1 is a test of an integer-valued reserved variable
(4) condition2 does not involve an integer-valued reserved variable
(5) condition2 involves a constant

The constant in condition2 may not be translated into a double precision
constant.  Regardless of the presence of this bug, it is unadvisable to
use a constant in condition 2 other than one which is integer-valued or has
a 
"short" exact binary representation.  If indeed the constant is
integer-valued
or has a short exact binary representation, then the bug will not present
any 
problem.

(XXII)
NM-TRAN translation of abbreviated code such as the following will be
faulty.

  IF (ICALL.EQ.4) X=A
  IF (ICALL.EQ.2) X=B

where with a test with condition ICALL.EQ.4, a variable X is
defined via expression A that involves eta or epsilon variables, and with a 
subsequent test with condition ICALL.EQ.2, again X is defined, this time via

an expression B that involves eta or epsilon variables.  
More specifically, when ICALL.EQ.4 is true, X will be 0.  

Work-around:  It is more usual to write code such as the above as follows:

  X=B
  IF (ICALL.EQ.4) X=A

so that with analysis - when the condition ICALL.EQ.2 is true - X is set
to B, and it is only when the Simulation Step is being implemented -
when the condition ICALL.EQ.4 is true - that one might want to take care to 
define X differently.  With this code, there is no bug.  Or use:

  IF (ICALL.EQ.2) X=B
  IF (ICALL.EQ.4) X=A

(XXIII)
NM-TRAN translation of abbreviated code such as the following can be faulty.

  IF (ICALL.EQ.4) X=A
  IF (ICALL.EQ.2.AND.IPROB.EQ.1) X=B
  IF (ICALL.EQ.2.AND.IPROB.EQ.2) X=C

where with some test involving ICALL.EQ.4, a variable X is
defined (by expression A), and with tests involving ICALL.EQ.2, again
X is defined, and as a random variable (by expressions B and C).
More specifically, the partial derivatives of X (using B and C) with respect

to the involved etas or epsilons can be incorrect.

Work-around:  If a Simulation Step need not be performed in problems
1 and 2, then this code can be rewritten

  IF (ICALL.EQ.4) X=A
  IF (IPROB.EQ.1) X=B
  IF (IPROB.EQ.2) X=C

Otherwise, rewrite the code using indicator variables: 
X1=A
X2=B
X3=C
Q1=0
Q2=0
Q3=0
IF (ICALL.EQ.4) Q1=1
IF (ICALL.EQ.2.AND.IPROB.EQ.1) Q2=1
IF (ICALL.EQ.3.AND.IPROB.EQ.2) Q3=1
X=Q1*X1+Q2*X2+Q3*X3

(XXIV)
NM-TRAN translation of all PREDPP abbreviated codes ($PK, $ERROR, $DES,
$AES) are faulty when

1) DATE=DROP is listed in the $INPUT record
and either
2a) The name MDV is not listed in the $INPUT record (NM-TRAN appends
MDV data items to the NONMEM data set)
3a) MDV is used as a right-hand quantity in an assignment statement in 
abbreviated code, or
2b) The name EVID is not listed in the $INPUT record (NM-TRAN appends
EVID data items to the NONMEM data set)
3b) EVID is used as a right-hand quantity in an assignment statement in
abbreviated code

Most codes only use MDV or EVID in a condition of a conditional
statement (and not in an asignment statement), and in such a case no
problem arises.

Fix:
In routine GENERC immediately prior to:

        INTEGER I,J,K,KK,II,IU(99)   

Insert:
        COMMON/COM34/FIXTM,FRSTRC,DROPDT
        LOGICAL FIXTM,FRSTRC,DROPDT

Immediately after:

        RHSPOS(I)=IDRPTR(-RHSPOS(I))

Insert:

        IF (DROPDT) RHSPOS(I)=RHSPOS(I)-2

(XXV)
A run-time error may occur in NM-TRAN Library subroutines
when constants in files TSIZES and LSIZES are increased at installation time
from the default values, in order to allow a larger number of lines of
abbreviated code.

Work-around: When a larger number of lines of abbreviated code than is
allowed by the default installation constants is needed, and if the 
Laplacian estimation method is not used, then in an NM-TRAN control stream 
the option DERIV2=NO can be included in the $ABBREVIATED record, and
this will allow a larger number of lines.

Work-around: Avoid the use of the NM-TRAN Library.


(XXVI)
NM-TRAN translation of abbreviated code such as the following can be faulty.

  IF (condition1) X=A
  IF (condition2) X=B

where with some test a variable X is defined as a nonrandom variable, using 
an expression A that involves the power operator "**", and with a subsequent

test X is defined as a random variable (by expression B).  NM-TRAN may 
produce a warning that the partial derivatives of X (using B) with respect
to 
the involved etas or epsilons may be incorrect, but in fact, the computed 
value of X may also be incorrect.

Work-around:  Rewrite the code using indicator variables: 
X1=A
X2=B
Q1=0
Q2=0
IF (condition1) Q1=1
IF (condition2) Q2=1
X=Q1*X1+Q2*X2

Fix:
In routine CPYOLD locate the three lines of code:

        KSAVE=KKK
        KCOUNT=KCOUNT+1
        GOTO 991

and then insert a statement above and a statement below as follows:

      IF (KIF.EQ.0) THEN
        KSAVE=KKK
        KCOUNT=KCOUNT+1
        GOTO 991
      ENDIF

(XXVII) A constant in abbreviated code involving the characters "E+" or "D+"

(e.g. 1.2E+4, 4D+02) will not be recognized, and an error message will be
issued.  

On the other hand, a constant involving the characters "E-" or "D-" 
(e.g. 1.2E-4, 4D-02) will be properly recognized.

Work-around:  Use instead 1.2E4 and 4D02, i.e. do not include "+".

Fix:
In routine GETTKN locate the two lines of code:

      IF (ITEM2.EQ.'-') THEN
        ITEM(LI+1:)='-'

and replace with:

      IF (ITEM2.EQ.'-'.OR.ITEM2.EQ.'+') THEN
        ITEM(LI+1:)=ITEM2
_______________________________________________________