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

From: Lindauer, Andreas (Barcelona) <"Lindauer,>
Date: Tue, 20 Nov 2018 18:53:14 +0000

_at_Leonid
It is the very DV column that is damaged.
In the 'good' model, the one with less than 3 variables dropped or when usi=
ng the WIDE option, DVs show up in sdtab as they are in the input file. Whi=
le the 'bad' model cuts off the decimals, e.g.
3.17, 3.19, 3.74 in the input data file (and the good sdtab) become 3.0, 3.=
0, 3.0 with the bad model

_at_Katya
Yes, originally I did have lines longer than 80 characters but not longer t=
han 300. I just did a quick test with keeping all lines <80 chars and the i=
ssue remains.

_at_Alejandro
No I don't have spaces in my variables. Neither in the name nor in the reco=
rd itself

_at_Luann
Yes I'm using a csv file. As far as I can see all my variables are numeric,=
 and do not contain special characters. The datafile is correctly opened in=
 Excel and R. But I will double check.

Thanks to all to help detecting the problem. I will try to make a reproduci=
ble example with dummy data that can be shared.

Regards, Andreas.

-----Original Message-----
From: Ekaterina Gibiansky <egibiansky_at_quantpharm.com>
Sent: Dienstag, 20. November 2018 16:29
To: Leonid Gibiansky <lgibiansky_at_quantpharm.com>; Lindauer, Andreas (Barcel=
ona) <Andreas.Lindauer_at_sgs.com>; nmusers_at_globomaxnm.com
Subject: Re: [NMusers] Potential bug in NM 7.3 and 7.4.2

And one more question, do you have long lines - compared to 80 and to
300 characters that become shorter than these thresholds when you drop the =
third variable?

Regards,

Katya

On 11/20/2018 10:01 AM, Leonid Gibiansky wrote:
> 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
>>
>
>
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 - 13:53:14 EST

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