From: Xiaofeng Wang -
Subject: [NMusers] some issues about NONMEM
Date: 2/10/2004 10:23 AM

Dear everyone:

Recently I was advised about some tricky issues existing in
NONMEM.  I would like to know more about these issues from you.

1  About NONMEN patches to correct the bugs in NONMEM

   I was informed that NONMEN has several bugs and there are
patches to correct these bugs.  Also, I was advised that FDA will
not accept the results got from NONMEN without being corrected by
these patches.  But these patches are not available to the public
except a few people in this community.  Therefore, my questions
     a)  If FDA will not accept the results, is there any
guideline issued by FDA which patches that a user has to have?
     b)  Has Globomax advised NONMEM users on these patches?
     c)  Could those people who aware these bugs and have patches
make their knowledge public, so the community can be benifited?

2 About FO and FOCE method

   I was also advised to use the results from FOCE, since the
results from FO are not countable (type I error, etc)...  From FO
and FOCE algorithm, it can see that FO is applicable to the
situation where interindividual variability is small, while FOCE
handles the case when inter-individual variability is large.
Therefore, results from both FO and FOCE should be close if the
interindividual variability is small.  Thus, I would like to know
more why results from FO should not be accepted even when
interindividual variability is small.  I have a few publications
discussing about the type I error.  However, when should we
consider the Type I error?  I will read these publications but
wish someone could clarify a little bit more before I start to
  In addition, if results from FO are different from FOCE,
permutation (?) has to be done to check the problem.  I have zero
knowledge about it. What is this permutaion method?  How to
conduct it?

Thank you,


From: "Rombout, Dr. Ferdinand" -
Subject: [NMusers] some issues about NONMEM
Date: 2/10/2004 10:51 AM

Dear all,

I can do nothing else than fully agree with the remarks about patches.
Recently I lost an email from the discussion group about one patch. Luckely
I remembered seeing this email and could get some information from Globomax.
However my own search in the stored messages did not lead to any finding!!
If I had not read the email, I would not have been aware.
In light of 21CFRpart11 requirements from the FDA this is not acceptable.
Globomax should have the obligation to notify each person having a valid
NONMEM licens about any need for changes and they should do so in writing to
each individual separate (I think we users have that right by having the
yearly license fee). They should also advice users whether revalidation of
systems/previous results are needed.


Ferdie Rombout

From: Nick Holford -
Subject Re: [NMusers] some issues about NONMEM
Date: 2/11/2004 2:30 PM


NONMEM patches --  the silence from Maryland is deafening.

You can find some information about methods for determining the
null distribution of objective function differences here 

Note that these methods can only guide you in making model building
decisions based on P value criteria. They cannot diagnose nor fix
problems with bias or imprecision in parameter estimates that might
arise from any NOMMEM estimation method such as FO or FOCE. You can
use simulation (parametric bootstrap) to explore the possible bias
in estimation. Confidence intervals in parameter estimates can be
obtained using the non-parametric bootstrap (
All these methods are time consuming (and often impractical) because
they typically involve hundreds if not thousands of runs for each
model you want to test.

Before assuming (based only on advice from your colleagues) that FDA will
not accept results I suggest you try talking to FDA. If you can talk to a
pharmacometrician at FDA you should get practical and helpful advice
tailored to your particular problem.

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

From: Diane R Mould -
Subject: Re: [NMusers] some issues about NONMEM
Date: 2/11/2004 4:59 PM

Dear All

I agree that it would be very good to have a repository where all the
relevant patches and fixes were readily available for users.  The fixes
have all been posted to NMUSERS and should be available in the NMUSER
archives, but because they are not stored together, they are not easily
retrievable. A set of test kits to help the user make certain that the
patch was correctly installed and works would also be nice to have as

As to the quality of work done on a system that has not been upgraded
and maintained, I think that it is important to make sure that software
is running as well as it can when doing work for regulatory purposes.
Some of the patches reported by GLOBOMAX have dealt with errors that
could result in substantial differences if runs were done on unpatched
systems versus patched systems (e.g. the nested if-then-else bug).  I
would hope that all the regulatory authorities (not just the FDA) would
be making a similar effort to maintain NONMEM to the best standards
recommended by the vendor.  Therefore, it is important that both sides
maintain any system to the best standards possible to minimize potential

But perhaps more importantly, this issue has more to do with the
analysis and the science then the acceptability of the work by the
regulatory authorities.  It seems to me that ignoring recommended fixes
is just not good science, particularly because many of the patches have
dealt with aspects of modeling that many users could encounter during
the course of regular work.  


From: "Gastonguay, Marc" -
Subject: Re: [NMusers] some issues about NONMEM
Date: 2/11/2004 8:21 PM

Dear nmusers,

As Diane points out, it would be nice to have an official central repository
of recommended NONMEM updates/patches and, unfortunately, posts to nmusers
describing NONMEM patches are not easily retrievable. I don't think that any
end-users would intentionally ignore recommended fixes; the problem seems to
be a lack of awareness and a less than optimal method of communicating these

In an effort to help the user community identify the necessary patches, I am
sharing an UNOFFICIAL list of recommended NONMEM code patches (for supported
NONMEM routines) that I have accumulated since NONMEM V level 1.1 was
released. I think that all of these have been announced by the NONMEM
Project Group over nmusers, and I would suggest that this list should be
used as a checkpoint for keywords to search the nmusers archive for the
original posting. Please do not use my list as the source for your code
patches. I cannot verify that this list is complete, but in the absence of
an official list, this should provide some practical guidance.

Please keep in mind that some of these fixes will have little or no impact
on some problems. Details are usually provided with each patch announcement.
If you are concerned that you have missed any of these, you should probably
test the impact of these code changes on any prior analyses that you think
might have been affected.

I hope that this is useful and that it does not cause any additional
confusion. I would, of course, be grateful for any corrections or additions
to this list.

In my opinion, the best solution would be an official, vendor-supported
patch repository on the web.


Marc R. Gastonguay, Ph.D.
Gastonguay Consulting LLC
3 Winterset Lane
Simsbury, CT 06070
Tel: 860.651.5318

Unofficial list of NONMEM V level 1.1 source code changes:

1. Check Y2K settings (year 00 = 2000)

NOTE: On newer releases of NONMEM V 1.1, this has already been changed.
Licenses released prior to (some date?) will require the following
code change:



2. Fix data truncation bug (use WIDE option on $DATA) and make source

In C:\NMV\TR\:
  Locate this line in READ3.FOR:
  Replace with:

Locate and delete  the following statement in READF.FOR:
    IF (INOBS.GT.9999.AND.WIDE.EQ.'Y') CALL ERRMSG(283,' ',1)


There are four affected lines of code.


1) Changes to subroutine CPYOLD.FOR
   Note that character "X" must be in column 6 of the Fortran source


Replace with:
      IF (LHSTYP(K).EQ.35.AND.


Replace with:
      IF (RHSTYP(J).EQ.35.AND.

2) Changes to subroutine SAVOLD.FOR

      DO 75 J=1,KOLD

Replace with:
    DO 75 J=KOLD,1,-1


Replace with:
      IF (SAVTRU(J).EQ.0) GO TO 80

4. MIXTURE Model subscript bug

find the statement

DO 342 I=1,LM1

replace the variable LM1 with MCMAX:

DO 342 I=1,MCMAX

5. Bug with correlated epsilons across L2 records:


LOCATE the two lines of code:

         IF (MODE.EQ.2) THEN

REPLACE these with:

         IF (MODE.NE.3) THEN

6. Recompile code after source changes made.

7. Bugs/Features with no fixes:

7.1. Non-influentual eta bug does NOT have source code fix - yet. Use
transform in control stream.

7.2. $TABLE bug - FORWARD option is needed on 2nd $TABLE record when
simulating multiple subproblems. FORWARD is not needed for the first
This is not consistent with the documentation.


From: Nick Holford -
Subject Re: [NMusers] some issues about NONMEM
Date: 2/11/2004 10:50 PM


Thanks for your patch list. I would like to add this set of 3 patches to
tr\GENCOM.for which fixes code generating FSUBS with large NM-TRAN LIBRARY
models (Suggested by Stu Beal 11 July 2002).


Fixes bug for emitting BBBBBB() code
C Insert after previous declaration for WORK

Replace following commented code:
C      WRITE (WORK,'(A,I4.4,A)') 'BBBBBB(',I,')'
C      IF (LL.EQ.14) THEN
C      LINE(LL+1:)=WORK
C      LL=LL+12
C      ELSE
C      LINE(LL+1:)=','//WORK
C      LL=LL+13
with this
      WRITE (WORKX,'(A,I5.5,A)') 'BBBBBB(',I,')'
      IF (LL.EQ.14) THEN

C Fixes bug for emitting DIMENSION COM code
Replace following commented code:
C       LL=19
with this

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

From: "Piotrovskij, Vladimir [PRDBE]" -
Subject: Re: [NMusers] some issues about NONMEM 
Date: 2/12/2004 4:19 AM


I presume NONMEM VI will include those bug fixes. Could you confirm please?

Best regards,


From: "Gastonguay, Marc" -
Subject: Re: [NMusers] some issues about NONMEM
Date: 2/12/2004 6:31 AM

I would think so, but I'll leave it up to GloboMax/NONMEM Project Group to
comment on what will be included in NONMEM VI.


From: "Gastonguay, Marc" -
Subject: Re: [NMusers] some issues about NONMEM
Date: 2/12/2004 6:58 AM

Thanks for the addition, Nick. I was unable to find a related post on the
nmusers archive. Could you please provide some guidance about the model/data
conditions requiring the GENCOM fixes? Thank you.


From: Xiaofeng Wang -
Subject: Re: [NMusers] some issues about NONMEM
Date: 2/12/2004 9:35 AM

Thanks both Nick and Marc for providing valuable information and suggestions to
the community.  I would like to thank Nick specially for his advise in his other
email to me, also to Diane.
I am not sure if NMusers would agree with me: maybe Globomax can raise either
liscense fee or maintainace fee to a certain level that the extra revenue can
cover the cost for Globomax to fix the bugs, and to conduct the testing and
validation of NONMEN?



From: Nick Holford -
Subject Re: [NMusers] some issues about NONMEM
Date: 2/12/2004 1:12 PM


This fix was provided to me directly by Stuart after I had reported
a problem to nmconsult. If you need this fix then it will be obvious
because NM-TRAN produces illegal Fortran code and your compiler will
complain. The fix is needed when using very large models which require
larger array dimensions than were originally anticipated in FSUBS. The
patches to GENCOM allow these larger arrays to be emitted by NM-TRAN.
In my case it was triggered by using the $SUBROUTINE LIBRARY option
with ADVAN6 with 50 THETA, 56 ETA and 3 EPS parameters.

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