[NMusers] Potential bug in NM 7.3 and 7.4.2

From: Lindauer, Andreas (Barcelona) <"Lindauer,>
Date: Tue, 20 Nov 2018 11:45:57 +0000

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


Received on Tue Nov 20 2018 - 06:45:57 EST

This archive was generated by hypermail 2.3.0 : Fri Sep 27 2019 - 17:01:37 EDT