From: "Bachman, William (MYD)" bachmanw@iconus.com
Subject: [NMusers] New NMTRAN bug list with a new Bug # XXVIII
Date: Thu, February 17, 2005 4:17 pm
There is a new buglist for NMTRAN.
Change Made: new bug XXVIII
PDF version of file, NMTRANbugs17FEB2005.pdf, may be found at:
ftp://ftp.globomaxnm.com/Public/nonmem/buglist/
or
http://www.globomaxservice.com/products/NMTRANbugs17FEB2005.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
(XXVIII)
NM-TRAN (and hence NONMEM output) is incorrect when
(1) there is a conditional block of code with a compound condition,
i.e. a condition with more than one instance of .AND. or .OR.
(2) one of the variables tested in the compound condition is redefined in
later code, and this variable is either
(2a) on the right side of some instance of .AND. or .OR.
other than the last instance, or
(2b) on the left side of some instance of .AND. or .OR.
other than the first or second instance
(3) a random variable is defined in the conditional block
(4) the Laplacian estimation method is used without the NUMERICAL option
Work-around: Restructure the code so as to avoid (2).
New NMTRAN bug list with a new Bug # XXVIII
From: "Nick Holford"
Subject: Re: [NMusers] New NMTRAN bug list with a new Bug # XXVIII
Date: Thu, February 17, 2005 5:45 pm
Bill,
Can you or someone else provide an illustrative example of this complex set of
conditions. It is this kind of sets of complex conditions that causes the bugs in
NM-TRAN. Who can guess what Stuart was thinking when he wrote this?
Nick
--
Nick Holford, Dept Pharmacology & Clinical Pharmacology
University of Auckland, 85 Park Rd, Private Bag 92019, Auckland, New Zealand
email:n.holford@auckland.ac.nz tel:+64(9)373-7599x86730 fax:373-7556
http://www.health.auckland.ac.nz/pharmacology/staff/nholford/
_______________________________________________________