Re: relation of numerical error to gfortran?

On Tue, Apr 5, 2022 at 12:19 AM Rikard Nordgren < [email protected]> wrote: > Hi Tong, > > I agree with Bill Denney. I just want to add one more thing to the list. > > Around five years ago I tried to compare ifort with gfortran. This turned > out to be difficult since NONMEM gives different options to the two > compilers making the comparison unfair. At that time, and this is also > taken from my memory, ifort wasn't given its highest optimization setting > (O3) and gfortran was given the -ffast-math option. A comparison could > still be made, but it is non-trivial, so I don't think there are any strong > signs pointing to either compiler. At the time our group selected to only > continue using gfortran because it is cost-free and open source. > > As a side note there are now two new interesting open source fortran > compilers in the works: flang and lfortran. I don't think either of them is > production ready yet, but they are worth keeping an eye on. > > Best regards, > Rikard Nordgren > > > On 2022-04-04 23:13, Tong Lu wrote: > > Thanks Bill for your thoughtful reply! I am starting with adding "$ABBR > PROTECT" to see if it would help. Meanwhile, we will try to re-install > NONMEM 7.5.1 in the HPC with Intel Fortran. We had some issues with using > Intel Fortran and PsN 5.2.6 before, and we will see if we can get around > this time. > > In this particular case, it works in NM7.4.3 with Intel Fortran but not > 7.5.1 with gfortran. Since both NM versions are in the same HPC, there are > only two moving parts: one is the NONMEM version (7.4.3 v.s. 7.5.1), the > other is the Fortran compiler (Intel vs gfortran). All the rest are the > same. > > Is it a general understanding that Intel Fortran is more stable than > gfortran in the HPC (linux cluster) for NONMEM purpose? or it is an > incorrect impression. > > Thanks again! > Tong > > > > On Thu, Mar 31, 2022 at 5:21 PM Bill Denney <[email protected]> > wrote: > >> Hi Tong, >> >> >> >> The general issue of floating point instability is generally a problem >> for models that are hard to fit (3 days with full parallelization sounds >> hard to fit). It’s discussed in the intro7.pdf document in section I.70, >> “Stable Model Development for Monte Carlo Methods”. >> >> >> >> Given that you’re using SAEM, it seems like there could be a division by >> zero or near zero when trying to choose the next point to estimate and the >> values are going toward infinity or negative infinity. I’ve experienced >> this in the past with problems that are not well-defined around the OFV >> minimum. For instance, if a parameter has a near-flat derivative in the >> likelihood surface, it can cause these issues. >> >> >> >> It's not a specific problem to changing from Intel Fortran to gfortran; >> it could have happened with almost any platform change (changing operating >> system, changing compiler, changing operating system or compiler version, >> changing architecture [AMD vs Intel], and even changing architectures >> within a brand [Intel i9 vs Xeon, for instance]). >> >> >> >> In my experience, usually this points to a model that’s not >> well-defined. I would try to slowly build up the model—either in fixing >> parameters, fitting the model, and add the parameters back one-by-one to >> see which parameter estimation causes the estimation to slow down >> dramatically or to cause the problem. Or, subset your data: start with one >> study and build up from there; occasionally, trying to identify a problem >> individual or problem study and see if a different parameterization could >> help with that data (e.g. do you need a different residual error for Phase >> 1 vs Phase 2 studies?). >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> *From:* [email protected] <[email protected]> *On >> Behalf Of *Tong Lu >> *Sent:* Thursday, March 31, 2022 5:43 PM >> *To:* [email protected] >> *Subject:* [NMusers] relation of numerical error to gfortran? >> >> >> >> Hello All, >> >> >> >> Has anyone experienced numerical errors when using NONMEM with gfortran >> but not intel fortran? >> >> >> >> We have a complex PKPD model which gave us strage individual fitting with >> NM7.5.1 (compiled by gfortran) but not NM7.4.3 (compiled with intel >> fortran). When using NM7.5.1, there is an unexpected & abrupt change of the >> time profile in some individuals, which is likely caused by the issue of >> numerical integration. This is a model with a large percent of BLQ, and has >> an extremely long run time (3 day with full parallelization). We used >> NOHABORT in SAEM estimation. >> >> >> >> Somehow we failed to install NM7.5.1 and PsN 5.2.6 properly on our linux >> cluster (CentOS) when using intel fortran. Thus no >> apple-to-apple comparison can be made (NM 7.5.1 by gfortran v.s. NM 7.5.1 >> by intel fortran). I am wondering if you have experienced cases >> where gfortran gave an issue but intel fortran is ok, for the same NONMEM >> version. >> >> >> >> The changes made in NM7.5.1 could also be related to this issue. Any >> thoughts or experience around this could also be very helpful. >> >> >> >> Thanks a lot for your insights >> >> Best, >> >> Tong >> > > -- > Rikard Nordgren > Systems developer > > Department of Pharmacy > Faculty of Pharmacy > Uppsala University > Box 591 > 75124 Uppsala > > Phone: +46 18 > 4714308www.farmbio.uu.se/research/researchgroups/pharmacometrics/ > > > > > > > > > > När du har kontakt med oss på Uppsala universitet med e-post så innebär > det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör > det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ > > E-mailing Uppsala University means that we will process your personal > data. For more information on how this is performed, please read here: > http://www.uu.se/en/about-uu/data-protection-policy >