Hi all,
thanks for your input, I ended up contacting Andreas as Clorice
suggested. I am happy to say the issue has been resolved.
In order to hopefully help anyone else out there who may experience a
similar issue in the future:
The problem was regarding the available ORCA versions on the cluster I
was using. I do not have any documentation of what ORCA version was used
when amber was compiled but I have a suspicion that the version is very
important.
I found that when I loaded 6.1.X (6.1.0 and 6.1.1 are available) I would
experience the mpirun issue whereas if I loaded the 6.0.1 version, there
would not be any mpirun call by amber when it initiates the ORCA
calculation.
so in short, if anyone experiences a similar issue in the future, try
loading a different ORCA version with amber if available on the cluster
you are using.
Best,
Anders
On 26/05/2026 19.46, 喵Junmin via AMBER wrote:
> As I remembered in fixing the amber/orca problem, you can just alias orca
> into a full path command in the script or environment.
> The other problem is sander still using old Grid formats and that will not
> be accepted by current ORCA 6.1, I posted the fix here or you can just
> change the argument into defgrid2 or 3.
>
> http://archive.ambermd.org/202512/0028.html
>
>
> James Kress via AMBER <amber.ambermd.org> 於 2026年5月27日週三 上午1:39寫道：
>
>> You might want to try the ORCA forum since the problem seems to reside in
>> ORCA.
>>
>>
>> https://orcaforum.kofo.mpg.de/index.php?sid=89c1171e8020013cf5b3d7a1ea1a513a
>>
>>
>> On Tue, May 26, 2026 at 5:13 AM Anders Frederiksen via AMBER <
>> amber.ambermd.org> wrote:
>>
>>> Hi Clorice,
>>>
>>>
>>> thank you very much for this input. I have tried to implement your path
>>> definitions in my slurm script, however still to no avail. I have below
>>> pasted the relevant part of my slurm script to start the simulation
>>>
>>>
>>>
>>> ml PDC/24.11
>>> ml amber/24-cpeGNU-24.11-ambertools-24-amdgpu
>>> ml openmpi/5.0.8
>>> ml orca/6.1.1
>>>
>>> ORCA_PATH=/pdc/software/24.11/other/orca/6.1.1/
>>> ORCARUN=/pdc/software/24.11/other/orca/6.1.1/orca
>>> export PATH="/pdc/software/24.11/other/orca/6.1.1/orca:$PATH"
>>>
>>> srun $AMBERHOME/bin/sander.MPI -O -i colvar.mdin \
>>> -o orc_test.mdout \
>>> -p neutral.prmtop \
>>> -c rewrapped.rst7 \
>>> -r cont.rst7 \
>>> -x orc_test.nc \
>>>
>>>
>>> similarly, my orca template contains
>>> %pal nprocs 10 end
>>>
>>>
>>> which ORCA correctly catches
>>>
>>> ************************************************************
>>> * Program running with 10 parallel MPI-processes *
>>> * working on a common directory
>> *
>>> ************************************************************
>>> Unfortunately, the simulation still crashes
>>>
>>> Calling Command: mpirun -np 10
>>> /pdc/software/24.11/other/orca/6.1.0/orca_startup_mpi orc_job.int.tmp
>>> orc_job
>>> [file orca_tools/qcmsg.cpp, line 394]:
>>> .... aborting the run
>>>
>>> The mpirun call is not something I have inserted anywhere, it seems to me
>>> to happen on ambers part, though I am not sure if it is an issue that
>> stems
>>> from the way the program was compiled on the cluster or if there is
>> another
>>> underlying issue.
>>>
>>>
>>> I will try and mail this thread to Andreas in the hopes that he has a
>>> solution.
>>>
>>>
>>> Best,
>>>
>>> Anders
>>>
>>>
>>>
>>> ________________________________
>>> From: Clorice Reinhardt <Clorice.Reinhardt.uvm.edu>
>>> Sent: Monday, May 25, 2026 11:54:21 PM
>>> To: amber.ambermd.org; Anders Frederiksen
>>> Subject: Re: [AMBER] bug when running QM/MM with orca as external program
>>>
>>> Hi Anders,
>>>
>>> I have not any problems with Amber/ORCA interface. I'm not sure why you
>>> are calling ORCA in this way... Amber calls ORCA when it needs the forces
>>> on the atoms at each time step, or to perform the minimization.
>>>
>>> Therefore, you only write the command to call AMBER not ORCA in your job
>>> submission file. The original QM/MM interface paper has a nice flow chart
>>> if your confused on the flow of information. Amber writes the input files
>>> for orca at each minimization or time step, you do not need to do this
>> for
>>> it.
>>>
>>> For example, my slurm file looks like the following for QM/M I do (with
>>> some information redacted 🙂 )
>>>
>>>
>>> module load amber/24
>>> echo $AMBERHOME
>>>
>>> module load gcc/13.3.0
>>> module load openmpi/5.0.5
>>> module load orca/6.0.1
>>>
>>> ## amber can't find orca unless you explicitly tell it where the paths
>>> are. Probably could remedy this by passing the path while compiling, but
>> I
>>> didn't compile the version on the cluster and it works fine
>>>
>>> ORCA_PATH=YOURPATH
>>> ORCARUN=YOURPATHTOEXECUTEABLE
>>> export PATH="/gpfs1/sw/x86_64/rh7/pkgs/orca/6.0.0/orca:$PATH"
>>>
>>> top=my_parmtop
>>>
>>> $sander -O -i qmmm_md.in -o qmmm_md.out -p ${top}.prmtop -c
>>> YOUR_RESTART.rst -r qmmm_md.rst -x qmmm_md.netcdf
>>>
>>> I read in an orca template file with into amber (contain these among
>>> others):
>>> %pal nprocs 24 end
>>> %maxcore 3600
>>>
>>> Confirming it worked (looking at orc_job.dat which gets produced each
>> time
>>> orca is called and is the default name of the output file):
>>> " ************************************************************
>>> * Program running with 24 parallel MPI-processes *
>>> * working on a common directory *
>>> ************************************************************
>>>
>>>
>> ------------------------------------------------------------------------------
>>> ORCA STARTUP CALCULATIONS
>>> -- RI-GTO INTEGRALS CHOSEN --
>>>
>>>
>> ------------------------------------------------------------------------------
>>> "
>>>
>>> Your happy to reach out to me if you have questions. I run a ton of QM/MM
>>> and have dug into the source code and used the interface with Qchem,
>>> Gaussian and ORCA without a hitch, but Andreas Goetz is who'd I reach out
>>> if you have questions. He wrote the original paper on the interface, and
>>> he's super nice.
>>>
>>> https://scholar.google.com/citations?user=PJusscIAAAAJ&hl=en
>>>
>>> Clorice
>>> ________________________________
>>> From: Anders Frederiksen via AMBER <amber.ambermd.org>
>>> Sent: Monday, May 25, 2026 9:52 AM
>>> To: amber.ambermd.org <amber.ambermd.org>
>>> Subject: [AMBER] bug when running QM/MM with orca as external program
>>>
>>> Dear amber forum,
>>>
>>> I have in the last week been working with the QM/MM interface of the
>>> amber programme and especially focussing with performing a QM/MM
>>> simulation with orca as the external program.
>>>
>>> I have had great success running with orca as external program on small
>>> test systems for short simulations with sander running on multiple
>>> processors through MPI and orca running on single core through num
>>> threads = 1.
>>>
>>> However, if I want to run any kind of multi processing the QM part of
>>> the simulation crashes with the error
>>>
>>> ORCA finished by error termination in orca_util
>>> Calling Command: mpirun -np 2
>>> /pdc/software/24.11/other/orca/6.1.0/orca_util_mpi orc_job orca_hostfile
>>> orc_job
>>> [file orca_tools/qcmsg.cpp, line 394]:
>>> .... aborting the run
>>>
>>> This in principle is not surprising if we take a quick look at the orca
>>> documentation where it states:
>>>
>>> Do not start the ORCA driver with mpirun!
>>>
>>> I have tested and if I use ORCA the intended way, that is calling ORCA
>>> with its full path followed by the input file it runs just fine on
>>> multiple processors and therefore the fix for the amber call should be
>>> quite simple: Remove the "mpirun -np #MPIprocessors" call when orca is
>>> initiated.
>>>
>>> I should not that this should not be a version dependent thing for orca
>>> as I have found documentation all the way back in ORCA 3 (i.e.
>>> documentation from 2015), stating that starting ORCA with mpirun will
>>> make it crash.
>>>
>>> I have tried to work around the issue by using a template file
>>> (use_template =1) however sadly AMBER seems to read the nprocs flag and
>>> will make ORCA run through mpirun, leading to the same error as if
>>> initiated with AMBER input.
>>>
>>>
>>> If anyone have found another workaround I am all ears, though I hope
>>> this mail reaches a developer as the fix on paper should be rather
>>> simple, though given my inexperience in development it could not be as
>>> simple as I want it to be.
>>>
>>> Best,
>>>
>>> Anders Frederiksen
>>> Postdoctoral researcher
>>> KTH, department of Chemistry, Stockholm, Sweden.
>>>
>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>>
>> --
>>
>> James Kress Ph.D., President
>>
>> The KressWorks Foundation ©
>>
>> An IRS Approved 501 (c)(3) Charitable, Nonprofit Organization
>>
>> "Improving Lives One Atom At A Time" TM
>>
>> (248) 573-5499
>>
>>
>>
>> Learn More and Donate At:
>>
>> http://www.kressworks.org
>>
>>
>>
>> Confidentiality Notice | This e-mail message, including any attachments, is
>> for the sole use of the intended recipient(s) and may contain confidential
>> or proprietary information. Any unauthorized review, use, disclosure or
>> distribution is prohibited. If you are not the intended recipient,
>> immediately contact the sender by reply e-mail and destroy all copies of
>> the original message.
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri May 29 2026 - 00:30:02 PDT
