Re: Potential bug in NM 7.3 and 7.4.2

On Tue, Nov 20, 2018 at 8:21 PM Leonid Gibiansky <[email protected]> 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: > > @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 > > > > @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. > > > > @Alejandro > > No I don't have spaces in my variables. Neither in the name nor in the > record itself > > > > @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 <[email protected]> > > Sent: Dienstag, 20. November 2018 16:29 > > To: Leonid Gibiansky <[email protected]>; Lindauer, Andreas > (Barcelona) <[email protected]>; [email protected] > > 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 > > > > >