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

From: Schaedeli Stark, Franziska <franziska.schaedeli_stark_at_roche.com>
Date: Tue, 20 Nov 2018 20:49:41 +0100

Dear Andreas

I think your issue needs to be addressed through the PsN configuration, I
don't think it is a NONMEM issue.
When running scm with PsN you need to specify in the command file the
columns that you want/need to keep with a command like
do_not_drop = C,RACE,WGT

Please refer to the PsN users guides or the Uppsala Pharmacometric Group
for more information.

Kind Regards,
Franziska


*Franziska Schaedeli Stark, PhD*Senior Pharmacometrician
Senior Principal Scientist
Pharmaceutical Sciences - Clinical Pharmacology
Roche Pharma Research & Early Development (pRED)

Roche Innovation Center Basel

F. Hoffmann-La Roche Ltd
Grenzacherstrasse 124
Bldg 1 - Floor 17 - Office N661

4070 Basel

Phone: +41 61 688 5819
Mob +41 79 773 12 61
mailto: franziska.schaedeli_stark_at_roche.com


On Tue, Nov 20, 2018 at 8:21 PM Leonid Gibiansky <lgibiansky_at_quantpharm.com>
wrote:

> Thanks!
> One more question: in the "bad" model, if you look on output (tab) file,
> can you detect the differences, or it is different inside but output
> correct DV values to tab file? I think you describe it in the email
> below (that output is "bad") but I just wanted to be 100% sure. Then at
> least we can compare output with the true data (say, in R, read the tab
> file and csv file and compare) and detect the problem not looking on FDATA.
> Thanks
> Leonid
>
> On 11/20/2018 1:53 PM, Lindauer, Andreas (Barcelona) wrote:
> > _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
> using the WIDE option, DVs show up in sdtab as they are in the input file.
> While 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 than 300. I just did a quick test with keeping all lines <80 chars
> and the issue remains.
> >
> > _at_Alejandro
> > No I don't have spaces in my variables. Neither in the name nor in the
> record 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
> reproducible 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
> (Barcelona) <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
> 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 - 14:49:41 EST

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