Failure at computing inla.group.cv() in HTC

[Leonardo Cefalo]

Dear INLA experts,

I am unable to run `inla.group.cv()` on models fitted with INLA 25.10.19 on an HTCondor HTC cluster. I must use INLA 25.10.19 because as far ask I know it is the most recent stable build compatible with GLIBC 2.34 on our cluster nodes.  

• HTC: INLA 25.10.19 (CentOS7-compatible binary, installed via `inla.binary.install()`), inlabru 2.14.1, R 4.5.3
• Local PC: INLA 25.06.22, inlabru 2.12.0, R 4.5.x (Windows)

On my local PC, `inla.group.cv()` works fine on locally-fitted models. 

However, after a model fitted on HPC completes successfully, calling `inla.group.cv()` on its output eventually fails. As far as I understand, errors should not occur during computation, but only when R attempts to read the results back from the temporary directory. The error message is only:

The inla result collection failed.

And it also occurs if I import HTC-run INLA outputs to my local PC and try running `inla.group.cv()` from there.

May I please ask if there is anything I can do in the script to make `inla.group.cv()` work in my environment?

I attach the reproducible R script, the .err and the .out files, but I can provide more objects if needed (e.g. the INLA output). 

Thank you in advance,
Best
LC

[Helpdesk (Haavard Rue)]

can you retry with the testing version?

inla.upgrade(testing=TRUE)

On Tue, 2026-07-21 at 03:22 -0700, Leonardo Cefalo wrote:
> Dear INLA experts,
> I am unable to run `inla.group.cv()` on models fitted with INLA 25.10.19 on an
> HTCondor HTC cluster. I must use INLA 25.10.19 because as far ask I know it is
> the most recent stable build compatible with GLIBC 2.34 on our cluster
> nodes.  

>  * HTC: INLA 25.10.19 (CentOS7-compatible binary, installed via

> `inla.binary.install()`), inlabru 2.14.1, R 4.5.3

>  * Local PC: INLA 25.06.22, inlabru 2.12.0, R 4.5.x (Windows)

> On my local PC, `inla.group.cv()` works fine on locally-fitted models. 
>
> However, after a model fitted on HPC completes successfully, calling
> `inla.group.cv()` on its output eventually fails. As far as I understand,
> errors should not occur during computation, but only when R attempts to read
> the results back from the temporary directory. The error message is only:
>
>     The inla result collection failed.
>
> And it also occurs if I import HTC-run INLA outputs to my local PC and try
> running `inla.group.cv()` from there.
> May I please ask if there is anything I can do in the script to make
> `inla.group.cv()` work in my environment?
>
> I attach the reproducible R script, the .err and the .out files, but I can
> provide more objects if needed (e.g. the INLA output). 
>
> Thank you in advance,
> Best
> LC
>
>
>  

> --
> You received this message because you are subscribed to the Google Groups "R-
> inla discussion group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to r-inla-discussion...@googlegroups.com.
> To view this discussion, visit
> https://groups.google.com/d/msgid/r-inla-discussion-group/0e5ba9e9-56c3-47b3-8025-3b485cde0cbcn%40googlegroups.com
> .

--
Håvard Rue
he...@r-inla.org

[Leonardo Cefalo]

Dear Professor, thank you for your suggestion

I tried to rebuild the environment, upgrade INLA and install binaries. I was not able to test with R 4.6, since as far as I understand conda-forge does not currently have a resolvable r-sf/libgdal build for R 4.6 on our channels.  

Both on the compute node (interactive job) and on the user node (remote job), INLA fails before starting the optimization. I am not sure if this is the actual failure cause, but this output looks suspicious.

inla_build: check for unused entries in[/tmp/Rtmpa0jXep/file347d9b2b52e980/Model.ini]

        Unused entry [INLA.Expert!opt.storage]=[0]

        Unused entry [INLA.Expert!memory.alignment]=[0]

        Unused entry [INLA.Expert!blas.num.threads]=[0]

        Unused entry [INLA.stiles!block.size]=[-1]

        Unused entry [INLA.stiles!param]=[$inladatadir/file347d9b658bd13]

        Unused entry [INLA.taucs!min.block.size]=[4]

inla_build: [/tmp/Rtmpa0jXep/file347d9b2b52e980/Model.ini] contain[6] unused entries. PLEASE CHECK

..done

Warning in bru_log_warn(paste0("iinla: Problem in inla:\n", result)) :

  iinla: Problem in inla:

Error in inla.core.safe(formula = formula, family = family, contrasts = contrasts,  :

  The inla-program exited with an error. Unless you interupted it yourself, please rerun with verbose=TRUE and check the output carefully.

  If this does not help, please contact the developers at <he...@r-inla.org>.

The R script is the same as before. For more context I attach the new .out and .err files in case they may be useful.

Should I change something in my environment or in the R script?

Thank you again for your time,
Kind regards
LC

Il giorno mar 21 lug 2026 alle ore 18:04 Helpdesk (Haavard Rue) <he...@r-inla.org> ha scritto:

did you do

        inla.binary.install()

after upgrade?  try with 'Rocky8' as CentOS7 is past end-of-life.



On Tue, 2026-07-21 at 15:04 +0200, Leonardo Cefalo wrote:
> Thank you for your very quick reply!
>
> Initially I tried using the testing version, but it seems it cannot work with
> GLIBC2.34 - I immediately get errors of the form:
> /lustrehome/lcef97/miniconda3/envs/r_env/lib/R/library/INLA/bin/linux/64bit/in
> la.mkl: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by
> /lustrehome/lcef97/miniconda3/envs/r_env/lib/R/library/INLA/bin/linux/64bit/in
> la.mkl)
> /lustrehome/lcef97/miniconda3/envs/r_env/lib/R/library/INLA/bin/linux/64bit/in
> la.mkl: /lib64/libm.so.6: version `GLIBC_2.38' not found (required by
> /lustrehome/lcef97/miniconda3/envs/r_env/lib/R/library/INLA/bin/linux/64bit/li
> bRmath.so)
> and so on
>
> Is there a way to circumvent this issue using the testing version as well?
>
> Il giorno mar 21 lug 2026 alle ore 14:07 Helpdesk (Haavard Rue)
> <he...@r-inla.org> ha scritto:

[Helpdesk (Haavard Rue)]

On Wed, 2026-07-22 at 11:14 +0200, Leonardo Cefalo wrote:
> > inla_build: check for unused entries
> > in[/tmp/Rtmpa0jXep/file347d9b2b52e980/Model.ini]
>
>
> >         Unused entry [INLA.Expert!opt.storage]=[0]
> >         Unused entry [INLA.Expert!memory.alignment]=[0]
> >         Unused entry [INLA.Expert!blas.num.threads]=[0]
> >         Unused entry [INLA.stiles!block.size]=[-1]
> >         Unused entry [INLA.stiles!param]=[$inladatadir/file347d9b658bd13]
> >         Unused entry [INLA.taucs!min.block.size]=[4]
> >

This means there is inconsistency between the INLA R-code and the inla-binary
that you run. it looks like the inla-binary is to old compared to the INLA R-
code

--
Håvard Rue
he...@r-inla.org

[Leonardo Cefalo]

Thank you, indeed by looking at the Rocky8 binary file timestamp it results modified 2025-10-31.

For comparison, my working CentOS7 binary (paired with the older stable R package, 25.10.19) results modified on 2025-10-31 as well.

Is there a more recent binary that matches 26.06.08, still being compatible with  GLIBC ≤2.34? If one isn't available yet, would you recommend I pin the R package back to the 2025.10.19 version?

Kindest regards,
LC

[Helpdesk (Haavard Rue)]

On Wed, 2026-07-22 at 17:22 +0200, Leonardo Cefalo wrote:
> Is there a more recent binary that matches 26.06.08, still being compatible
> with GLIBC ≤2.34? If one isn't available yet, would you recommend I pin the R
> package back to the 2025.10.19 version?

sure, for every R-INLA version, there should be corresponding builds for various
systems, you can check here

https://inla.r-inla-download.org/Linux-builds/


for the Rocky8, its here

https://inla.r-inla-download.org/Linux-builds/Rocky%20Linux-8.10%20%28Green%20Obsidian%29%20x86_64/Version_26.06.08/64bit.tgz

let me know...

--
Håvard Rue
he...@r-inla.org

[Leonardo Cefalo]

Now it seems to work fine

Thank you so much!

Kindest regards,
LC