RE: Does inter-CPU variability exist in NONMEM??
Dear all,
Quite frankly it is extremely rare to find two systems that produce
identical results under all conditions. We have an internal test set of 150
problems that we routinely run to validate our NONMEM installations.
Switches between NONMEM versions, compilers and operating systems will
almost always result in numerical differences; most will of course not
impact your conclusions but convergence vs non-convergence can be a pain.
There is light though. We have found that you can get a truly consistent
setup if you stick to exactly the same version Intel Visual Fortran compiler
and use 64 bit operating systems on machines with Intel processors: Windows
7 or Vista 64 bit, Mac OSX and Linux. As far as I know we do not have
machines with AMD processors so I won't vouch for that (and differences
between Intel and AMD processors with Intel Visual Fortran have been
reported). To illustrate the need for consistent compiler versions: a switch
from 11.0 to 11.1 produced inconsistent results.
Cheers,
Rik Schoemaker, PhD
Exprimo NV
Tel:+31 (0)20 4416410
E-mail: [email protected]
Web: www.exprimo.com
Quoted reply history
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Luann Phillips
Sent: 17 February 2011 9:23 PM
To: Bob Leary
Cc: Kevin Dykstra; [email protected]
Subject: Re: [NMusers] Does inter-CPU variability exist in NONMEM??
Dear Chungam,
I have recently been running test models using NONMEM Version 7 Level
1.2 on an opensuse system with the gfortran compiler. I discovered in this
process that the -ffast-math compiler option can prevent some models from
minimizing (the first one I encountered used ADVAN5).
The -fast-math option changes how some arithmetic computations are
performed. One of them allows division to be performed using multiplication
of the reciprocal. This can result in a loss of precision. The intel fortran
compiler options specified in the SETUP file specifically indicate
-qprec-div which prevents changing division to multiplication.
I contacted ICON about the ADVAN5 model that failed to minimize with
-fast-math and ran fine without -fast-math. Bob Bauer indicated that the
optimizations for the gfortran compiler will be changed with NM 7.2.0.
If you don't mind sharing, which ADVAN and $EST were you using when you
encountered this problem?
Luann Phillips
Director, PK/PD
Cognigen Corporation
Bob Leary wrote:
> It is fairly common to use the compiler optimization level '-O3
> -ffast-math' with gfortran . The 'fast-math' option turns off
> compliance with the IEEE floating point arithmetic standard in order
> to get faster floating point computation. While computational speed is
> increased, it comes at a price - different processors can get different
> results with fast-math turned on depending on the specifics of the
> floating point hardware.
>
>
>
> *From:* [email protected]
> [mailto:[email protected]] *On Behalf Of *Kevin Dykstra
> *Sent:* Thursday, February 17, 2011 11:52 AM
> *To:* [email protected]
> *Subject:* RE: [NMusers] Does inter-CPU variability exist in NONMEM??
>
>
>
> Dear Chungam -
>
> You are not alone. A few years ago, I ran into a similar problem in
> comparing results (probably with NONMEM V at that time) from different
> computers. I was using an identical compiler on each, as well as
> identical compile settings (this is worth checking in your situation).
> Even the operating system was the same (Windows XP Professional), as I
> recall. Still I was getting subtle and not so subtle differences,
> including convergence vs. non-convergence. The only difference I could
> identify was, in fact, the machine on which the problem was run. I
> assumed at the time that the differences were down to small differences
> in the way each CPU handled floating point calculations (both were
> Intel, however; one was a laptop, the other a desktop). I also suspect
> that the model I was working on was not super robust, so that small
> differences translated into successful or non-successful convergence.
> Anyway, what you are seeing is not unheard of.
>
> Good luck!
>
>
>
> *__________________________________________ *
>
> *Kevin Dykstra, PhD, FCP*
>
> President/CEO
>
> Description: QPharmetra_noTag_FA little.png
>
> +1 978.655.1943 (O)
>
> +1 978.289.2987 (M)
>
> [email protected] <mailto:[email protected]> |
> http://qPharmetra.com
>
>
>
>
____________________________________________________________________________
______________________________
>
> This e-mail communication is confidential and is intended only for the
> individual(s) or entity named above and others who have been
> specifically authorized to receive it. If you are not the intended
> recipient, please do not read, copy, use or disclose the contents of
> this communication to others. Please notify the sender that you have
> received this e-mail in error by replying to the e-mail or by
> telephoning 978-655-1943. Please then delete the e-mail and any copies
> of it. Thank you.
>
>
>
> *From:* [email protected]
> [mailto:[email protected]] *On Behalf Of *???, Chungam Choi
> *Sent:* Thursday, February 17, 2011 10:55 AM
> *To:* [email protected]
> *Subject:* [NMusers] Does inter-CPU variability exist in NONMEM??
>
>
>
> Dear all
>
>
>
> I'm a newbie in this field practicing NONMEM using a few sets of
> bioavailabilty data.
>
> 2days before, I managed to make a model and got to get some parameters.
> Though I couldn't
>
> sure about it due to my poor background, they(parameters) were quite
> similar to those in a paper.
>
> Anyway, the thing was, the results were not constant in a single NMTRAN
> file. I've struggled for
>
> a few days figuring out what the problem was, but I couldn't get the
> first result. After I had run the same
>
> control file with the same data in another PC, surprisingly, I could
> find that the parameters were not the same
>
> as those from the prior PC. This had AMD X2 250/2G DDR2
> DRAM(Samsung)/windows 7 32bit and
>
> that had Intel i870/8G DDR3 DRAM(Samsung)/windows vista 32bit. Both had
> NONMEM 7/gfortran(in NONMEM7 CD).
>
> My friend, a developer, said that It didn't look like the problem of the
> processors but of the compiler.
>
> Because I've had fairly good relationship with AMD for long, I want to
> believe he's right.
>
> Is anyone here who 've met a similar problem?
>
> _________________________________________________________________
>