RE: [EXTERNAL] Potential bug in NM 7.3 and 7.4.2

From: Ruiz, Ana (Clinical Pharmacology) <[email protected]> Sent: Dienstag, 20. November 2018 15:35 To: Lindauer, Andreas (Barcelona) <[email protected]> Subject: Re: [EXTERNAL] [NMusers] Potential bug in NM 7.3 and 7.4.2 Hi Andreas, Do you have Body weight or any other variable in the base model other than DV ?did you include in the config file that variable using do not drop?checking the easiest option.... Ana -------- Original Message -------- From: [email protected]<mailto:[email protected]> on behalf of "Lindauer, Andreas (Barcelona)" <[email protected]<mailto:[email protected]>> Date: Tue, November 20, 2018 3:54 AM -0800 To: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] [NMusers] Potential bug in NM 7.3 and 7.4.2 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 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