Re: Potential bug in NM 7.3 and 7.4.2
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
Quoted reply history
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