I have the following fort.55 file:

                    1                2
  1.055712895050240    1    1    1    1
 -1.931748420029463    1    1    0    0
  0.000000000000000    0    0    0    0

I am trying to run MRCC using the above fort.55 with the following MINP input file:



#Li 1 R



However, I am getting an error indicating that MRCC is not able to read the integrals in the fort.55:

Reading integral list from unit 55...
 Sorting integrals...
 Sorting integrals... 

 Fatal error in mrcc.
 Program will stop.

I tried to run MRCC using the same MINP input but with another fort.55, the program ran properly without any reading errors:

                   1                     2
  0.00000000000000000000E+00   0   0   0   0
  0.00000000000000000000E+00   0   0   0   0
  0.10557128950502403519E+01   1   1   1   1
  0.00000000000000000000E+00   0   0   0   0
 -0.19317484200294638974E+01   1   1   0   0
  0.00000000000000000000E+00   0   0   0   0
 -0.19317484200294638974E+01   1   1   0   0
  0.00000000000000000000E+00   0   0   0   0
  0.00000000000000000000E+00   0   0   0   0

Why is this MINP file leading to a proper output when using the second fort.55, but gives an error when using the first fort.55.


1 Answer 1


The good news

I got MRCC working properly with your first fort.55 file, by a very small modification of your MINP file.

Reproducing what you obtained

First I reproduced your error with your first fort.55 file and reproduced your success using your second fort.55 file, both using your MINP file.


I then removed all lines in the MINP file that pertain to pre-fort.55 keywords, and the calculation ran successfully. This means that at least one of the keywords in the MINP file is interfering with the way that the fort.55 is being read. At first I thought it might be symm=off because your second fort.55 (which was working successfully from the beginning) had duplicate entries, perhaps to ensure that the fort.55 had a certain number of lines corresponding to what the fort.55 would resemble if no symmetry was used. However, removing symm=off lead to the same error that we had before. Next, I added back symm=off and commented scftype=ROHF (I chose to remove this keyword next, because a He atom is a closed shell system, and the O in ROHF stands for "open shell"), and again the calculation ran successfully!. The removal of the keyword scftype=rohf therefore constitutes a "minimal" modification to your MINP needed to get the calcultion running successfully.

All of the above calculations were done using the "April 12, 2017" release of MRCC because that is what I had available on the cluster that I was using, and because I know that Xiao Wang had said in an email to me that he found that his reading of fort.55 generated from were failing in newer versions of MRCC. Therefore, I tried using my most recently mentioned MINP file, with the originally failing fort.55 file, with the most recent version of MRCC: August 28, 2023. This was also a success!.


These are the CCSD energies obtained in the various scenarios described above (the letters at the beginning of each line, will be described in the table below, along with for a 5th scenario which did not yield any energy):

A: Total CCSD energy [au]: -2.807783945009 
B: Total CCSD energy [au]: -2.807783945009
C: Total CCSD energy [au]: -2.807783945009
D: Total CCSD energy [au]: -2.807783945009
Case MRCC version ROHF keyword kept or not? Which fort.55? Result
A 2017 ROHF Long -2.807783945009
B 2017 no ROHF Short -2.807783945009
C 2017 no ROHF Short -2.807783945009
D 2023 no ROHF Short -2.807783945009
E 2017 ROHF Short Error

Conclusion based on the above results

If you have the scftype=rohf keyword, you need the longer fort.55 file, but the short fort.55 file is fine otherwise.

I feel like I have noticed this before (in 2019 or earlier), and may have complained about it on the MRCC forum or in an email to Mihaly Kallay: reading a fort.55 file can lead to errors or successes depending on the scftype used.

  • 3
    $\begingroup$ Great to see the "debugging" steps in your answer, thanks for including those $\endgroup$ Commented May 21 at 11:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .