Re: relation of numerical error to gfortran?
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
Quoted reply history
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
>