NONMEM Users Network Archive

Hosted by Cognigen

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

From: Ekaterina Gibiansky <egibiansky_at_quantpharm.com>
Date: Tue, 20 Nov 2018 10:29:06 -0500

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
>>
>
>

Received on Tue Nov 20 2018 - 10:29:06 EST

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to: nmusers-request_at_iconplc.com. Once subscribed, you may contribute to the discussion by emailing: nmusers@globomaxnm.com.