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 <egibian...@quantpharm.com>
Sent: Dienstag, 20. November 2018 16:29
To: Leonid Gibiansky <lgibian...@quantpharm.com>; Lindauer, Andreas (Barcelona)
<andreas.linda...@sgs.com>; nmusers@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
