NONMEM Users Network Archive

Hosted by Cognigen

Re: [NMusers] Potential bug in NM 7.3 and 7.4.2

From: Leonid Gibiansky <lgibiansky_at_quantpharm.com>
Date: Tue, 20 Nov 2018 10:01:39 -0500

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 http://www.sgs.com/en/Terms-and-Conditions.aspx
>

Received on Tue Nov 20 2018 - 10:01:39 EST

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to: nmusers-request_at_iconplc.com. Once subscribed, you may contribute to the discussion by emailing: nmusers_at_globomaxnm.com.