NONMEM Users Network Archive

Hosted by Cognigen

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

From: Lindauer, Andreas <Andreas.Lindauer>
Date: Tue, 20 Nov 2018 14:46:31 +0000

Dear Ana,
No, the variables that I dropped where not part of the model. In fact, in m=
y case, the issue occurs with the 3rd variable that I drop, but it doesn't =
actually mater which one the third one is. My guess is that with 3 (or more=
) columns less, in this particular case, somehow NONMEM has trouble to find=
 the right data format.

Regards, Andreas.

From: Ruiz, Ana <Ana.Ruiz
Sent: Dienstag, 20. November 2018 15:35
To: Lindauer, Andreas (Barcelona) <Andreas.Lindauer
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?chec=
king the easiest option....

Ana

-------- Original Message --------
From: owner-nmusers
behalf of "Lindauer, Andreas (Barcelona)" <Andreas.Lindauer
Andreas.Lindauer
Date: Tue, November 20, 2018 3:54 AM -0800
To: nmusers
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 NONM=
EM and which appears to me to be an undesired behavior. Since it is confide=
ntial matter I can't unfortunately share code or data.

I have run a simple PK model with 39 data items in $INPUT. After a successf=
ul 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 $I=
NPUT that are not used in a given covariate test run.
I then ran the base model again with DROPPING some variables from $INPUT. A=
nd indeed the run with 3 or more variables dropped (using DROP or SKIP) res=
ulted 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 DROPp=
ed items is different.
In my concrete case the issue only happens when dropping 3 or more variable=
s. 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 u=
sing 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 otherwis=
e 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 th=
e Company. Finally, the recipient should check this email and any attachmen=
ts for the presence of viruses. The Company accepts no liability for any da=
mage caused by any virus transmitted by this email. All SGS services are re=
ndered in accordance with the applicable SGS conditions of service availabl=
e on request and accessible at http://www.sgs.com/en/Terms-and-Conditions.a=
spx
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 otherwis=
e 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 th=
e Company. Finally, the recipient should check this email and any attachmen=
ts for the presence of viruses. The Company accepts no liability for any da=
mage caused by any virus transmitted by this email. All SGS services are re=
ndered in accordance with the applicable SGS conditions of service availabl=
e on request and accessible at http://www.sgs.com/en/Terms-and-Conditions.a=
spx

Received on Tue Nov 20 2018 - 09:46:31 EST

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to: nmusers-request@iconplc.com.

Once subscribed, you may contribute to the discussion by emailing: nmusers@globomaxnm.com.