Invalid implementation - truncatew - fehler on processor 0

[Eduardo Solis]

Hello, I tried to execute the following (attached) input, but it always fails in the same place with the following output:

 PROGRAM * HESSIAN
 *** Long output written to logfile /home/esolis/molpro_run/nataliai/synhcnoh_freq.log ***
 Computing numerical hessian using default procedure for command CCSD(T)-F12
 Using no symmetry in wavefunction calculations
 Running default procedure: UHF-SCF000  CCSD(T)-F12
 Numerically approximating hessian using central energy differences
 Task list generated. Total number of displacements:    240
 Switching to mppx mode, nproc=  7
 ifil= 1  impl= 2
 ? Error
 ? Invalid implementation
 ? The problem occurs in truncatew
 GLOBAL ERROR fehler on processor   0  

Could someone guide me on how to move forward?

Best regards,

Eduardo

[peterso...@gmail.com]

it could be because UHF-CCSD(T)-F12 is not supported (although conventional UHF-CCSD(T) is). Try switching to rohf orbitals.

regards,  -Kirk

--
You received this message because you are subscribed to the Google Groups "molpro-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to molpro-user...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/molpro-user/6c8ea466-5de8-4a1e-9f7f-91966ba34828n%40googlegroups.com.

[Eduardo Solis]

Hello,

Thanks for your response.

I test with the sugeston, but the erro are similar.

In the .out the last message are:

PROGRAM * HESSIAN
 *** Long output written to logfile /home/esolis/molpro_run/nataliai/syn/synhcnoh_freq.log ***

 Computing numerical hessian using default procedure for command CCSD(T)-F12
 Using no symmetry in wavefunction calculations

 Running default procedure: RHF-SCF000  CCSD(T)-F12

 Numerically approximating hessian using central energy differences
 Task list generated. Total number of displacements:    240

 ? Error
 ? Time limit exceeded!
 ? The problem occurs in check_timelimit
 ? Error
 ? Time limit exceeded!
 ? The problem occurs in check_timelimit

 GLOBAL ERROR fehler on processor   0                                        

 ? Error
 ? Time limit exceeded!
 ? The problem occurs in check_timelimit


In the molpro calling line:
/opt/molpro/molpro_2025.3/bin/molpro   synhcnoh_freq.inp

I obtain this message when crash:
    0: fehler on processor   0                                          1 (0x1).
    0: In mpi_utils.cpp [MPIGA_Error]: now exiting...
    0: fehler on processor   0                                          1 (0x1).

Attached are the complete output, log, and input, if needed.
Regards,

Eduardo

[peterso...@gmail.com]

Looks like a completely different error to me.  Are you sure you haven’t restricted how much cpu or wall time this job can take?

To view this discussion, visit https://groups.google.com/d/msgid/molpro-user/f97c9abf-1cfd-402c-a641-16323d885d11n%40googlegroups.com.

[Eduardo Solis Céspedes]

No, I only run it directly on my computer.
13th Gen Intel(R) Core(TM) i9-13900
62GB of RAM

This error may be related to the fact that I am testing a trial version.

regards,

Eduardo

--

-----------------------------------------------------------------
Eduardo Solis-Céspedes
https://scholar.google.com/citations?user=LQKsLegAAAAJ&hl=es&oi=sra
orcid.org/0000-0002-7834-524X
https://www.researchgate.net/profile/Eduardo_Solis3

[peterso...@gmail.com]

oh yes, the trial version has a maximum CPU time limit.

-Kirk

[Matthew Graneri]

Hi there,

I've also got the same problem, except I have the full version of Molpro (2026.1). I'm running a CCSD(T)-F12 calculation and after the initial SCF, I get the following error:

 PROGRAM * OPT (Geometry optimization)     Authors: F. Eckert and H.-J. Werner


 BFGS update of hessian

 *** Long output written to logfile /home/granem94/calculations/polyhalides/fclfclf-/prohm-geom/f12/f12-TZ-cCR/opt/opt.log ***


 Geometry optimization using default procedure for command CCSD(T)-F12

 Geometry written to block  1 of record 700

 ifil= 1  impl= 2


 ? Error
 ? Invalid implementation
 ? The problem occurs in truncatew

 GLOBAL ERROR fehler on processor   0

I'm not quite sure what the problem might be... Does anyone have any ideas?

Thanks!

Matthew

[peterso...@gmail.com]

Hi Matthew,

could you at least post the input file (to the group)?

regards,  -Kirk

To view this discussion, visit https://groups.google.com/d/msgid/molpro-user/e360e806-b840-4898-8cb1-6ca648fd28b4n%40googlegroups.com.

[Matthew Graneri]

Sure! The input file in question should be attached below

Thanks for looking into this!

Regards,

Matthew

[peterso...@gmail.com]

Hi Matthew,

I don’t know why, but including the “nocompress” option is the culprit.  Without this the job runs without problem.

To view this discussion, visit https://groups.google.com/d/msgid/molpro-user/b55b4f42-c801-4548-b1db-8651729022bcn%40googlegroups.com.

[Matthew Graneri]

I'm not sure why, but getting rid of the nocompress actually stops the calculation from even getting to the optimisation part to begin with. It seems to finish the single point energy and then just stop. No error message in the output, no slurm oom error, nothing.

I just checked, also, and re-adding the 'nocompress' keyword gets it past the single point energy, but ends with the error again. Could this just be a bug?

[peterso...@gmail.com]

umm, mine worked just fine and was progressing nicely into the various tasks for the numerical gradient.  Could you  make sure you have all patches applied?

To view this discussion, visit https://groups.google.com/d/msgid/molpro-user/fc6435ae-6da8-4502-b50d-07df93443dacn%40googlegroups.com.

[Matthew Graneri]

That's strange... I would imagine all the patches have been applied, because they only installed the latest molpro version on Thursday, so it couldn't be any more recent.

I double checked with a second version of Molpro (2024.2.0) and the same thing happens. The weird thing is that the log file appears after the initial SPE and a second SPE starts calculating, but they never lead to a gradient before everything stops.

Would you be able to double check that it actually calculates the first gradient step before it stops? It's definitely not going that far for me. Or is there anything else I can send you which might help to diagnose the issue?