Related Link

From: "Ludden, Thomas" 
Subject: [NMusers] NMTRAN data truncation
Date: Fri, 19 Apr 2002 13:23:47 -0400

Dear nmusers:

The following memo regarding data truncation has been provided by Professor 
Stuart Beal, The NONMEM Project Group, UCSF.  

We wish to thank Lynn McFadyen and Nick Holford for bringing this issue to
our attention, to Nick for sending us control streams and a modified data file
that permited diagnosis of the problem, and to Diane Mould for pointing out that
the WIDE option would result in an error message if the number of records
exceeded 9999.

If you have questions or concerns please contact

Tom Ludden

Thomas M. Ludden, Ph.D.
Vice-President, Pharmacometric R&D
GloboMax LLC
7250 Parkway Drive, Suite 430
Hanover, MD 21076
(410) 782-2292
FAX (410) 712-0737
There is a bug in NM-TRAN Version III Level 1.1 (the  version  accompanying
NONMEM  version  V Level 1.1).  It can affect data sets which include clock
times.  Clock times are transformed to elapsed times in hours for the  NON-
MEM data  set  (FDATA).   All  such elapsed times should have two digits to
the right of the decimal point (as with earlier versions of NM-TRAN).  With
Version   III,   unpredictably,   certain elapsed times greater than 999.99
hours (41.6 days) become mistakenly truncated so that they contain only one
digit  to   the  right  of the decimal point.  Such an elapsed time will be
different from what it should have been by up to 5.4 minutes.  For many pro-
blems, this will not produce a practical difference in the results. However,
at the least,it may be an annoyance when with an innocuous change to the NM-
TRAN   data   set  (e.g.  the  dropping  of  a superfluous data item), some
elapsed times become  truncated, and there arises a  small  change  to  the
results.  To avoid this,

  Locate this line in READ3:
  Replace with:

With this change, one's FDATA file may look  different,  not  only  because
mistaken truncation will no longer occur, but there may be other changes as
well.  These changes will have no effect on a NONMEM run.  But care  should
be  taken  if  the  FDATA file is used for purposes other than for input to

However, there are limits to how large an elapsed time can be in  a  NONMEM
data  set  created by NM-TRAN.  With the above change, an elapsed time can-
not be larger than 9999.99 hrs (416.6 days).  The following type  of message
can occur:

  (DATA ERROR)      RECORD  5444, DATA ITEM  5: *******

This message refers to the option WIDE.  With or without the above  change,
an  individual may try  to use the  option WIDE with a large number of data
records and may obtain the message:


If  it is  necessary  to use  the WIDE  option with more than 9999 records,
simply locate and delete  the following statement in READF:

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

and then rerun NM-TRAN.

As always after source code has been changed, it must be  recompiled.   See
the Installation Guide.


From: Nick Holford 
Subject: Re: [NMusers] NMTRAN data truncation
Date: Sat, 20 Apr 2002 12:04:54 +1200


Thanks for posting these 2 suggestions for modifications to NM-TRAN. I have implemented the change
to READ3 and can confirm that it fixes the date truncation issue in the data set I had used to
identify this bug.

I have also implemented the second change in READF but I am puzzled by it. If this removes the
restriction on having more than 9999 records with the WIDE option why was the restriction ever there
in the first place? Am I correct in thinking that deletion of this line had no other effect except
to remove the original arbitrary restriction documented in NMHELP?

Nick Holford, Divn Pharmacology & Clinical Pharmacology
University of Auckland, 85 Park Rd, Private Bag 92019, Auckland, New Zealand tel:+64(9)373-7599x6730 fax:373-7556