NONMEM Users Network Archive

Hosted by Cognigen

Re: Potential bug in NM 7.3 and 7.4.2

From: Alejandro Pérez Pitarch <alejandroperezpitarch>
Date: Tue, 20 Nov 2018 10:17:11 -0500

Never seen it before. Do you have spaces in any of your variables? I guess
this is not the problem, but you might be dropping variables other than
those ones you want to drop if spaces are shifting your columns.

On Tue, Nov 20, 2018 at 10:11 AM Leonid Gibiansky <lgibiansky

> Never seen it.
> This will not solve the problem, but just for diagnostics, have you
> found out what is "damaged" in the created data files: is the number of
> subjects (and number of data records) the same in both versions
> (reported in the output file)? Among columns used in the base model (ID,
> TIME, AMT, RATE, DV, EVID, MDV), which are different? (can be checked if
> printed out to .tab file)? And which of the data file versions is
> interpreted correctly by the nonmem code, with or without WIDE option?
> Thanks
> Leonid
> On 11/20/2018 6:45 AM, Lindauer, Andreas (Barcelona) wrote:
> > Dear all,
> >
> > I would like to share with the group an issue that I encountered using
> NONMEM and which appears to me to be an undesired behavior. Since it is
> confidential matter I can't unfortunately share code or data.
> >
> > I have run a simple PK model with 39 data items in $INPUT. After a
> successful run I started a covariate search using PsN. To my surprise the
> OFVs when including covariates in the forward step turned out to be all
> higher than the OFV of the base model. I mean higher by ~180 units.
> > I realized that PsN in the scm routine adds =DROP to some variables in
> $INPUT that are not used in a given covariate test run.
> > I then ran the base model again with DROPPING some variables from
> $INPUT. And indeed the run with 3 or more variables dropped (using DROP or
> SKIP) resulted in a higher OFV (~180 units), otherwise being the same model.
> > In the lst files of both models I noticed a difference in the line
> saying "0FORMAT FOR DATA" and in fact when looking at the temporarily
> created FDATA files, it is obvious that the format of the file from the
> model with DROPped items is different.
> > In my concrete case the issue only happens when dropping 3 or more
> variables. I get the same behavior with NM 7.3 and 7.4.2. Both on Windows
> 10 and in a linux environment.
> > The problem is fixed by using the WIDE option in $DATE.
> > I'm not aware of any recommendation or advise to use the WIDE option
> when using DROP statements in the dataset. But am happy to learn about it
> in case I missed it.
> >
> > Would be great to hear if anyone else had a similar problem in the past.
> >
> > Best regards, Andreas.
> >
> > Andreas Lindauer, PhD
> > Agriculture, Food and Life
> > Life Science Services - Exprimo
> > Senior Consultant
> >
> > Information in this email and any attachments is confidential and
> intended solely for the use of the individual(s) to whom it is addressed or
> otherwise directed. Please note that any views or opinions presented in
> this email are solely those of the author and do not necessarily represent
> those of the Company. Finally, the recipient should check this email and
> any attachments for the presence of viruses. The Company accepts no
> liability for any damage caused by any virus transmitted by this email. All
> SGS services are rendered in accordance with the applicable SGS conditions
> of service available on request and accessible at
> >

Received on Tue Nov 20 2018 - 10:17:11 EST

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to:

Once subscribed, you may contribute to the discussion by emailing: