When we are doing a energy minimization in Gaussian 09, one of the issues that rise are that the energy of minimization steps will start to oscillate and never converge until one kills the calculation job or it passes a huge number of steps, wasting a computational time. So, our question is: can this kind of behavior happen in the GRRM during the minimization performed during a AFIR calculation (or other GRRM calculation that requires the minimization algorithm) that we have to keep an eye on it to avoid wasting computer time in a calculation that gets "derailed " from its original purpose?, in other words, what are those things that we should watch out during the calculation to know that something is wrong and we have to reset or change something because the calculation won't stop but it is going wrong? 

Thank you very much.

We are using MC-AFIR to look at some reactions on metal clusters, similar to the gold cluster work here: J. Phys. Chem. C, 2015, 119 , pp 11120–11130.

We're having many equivalent structures show up as new, and while we've tried various settings of MatchDecScale and MatchDecTarget, we've not had much success in cutting down the number of incorrectly identified new structures.

Are there any other recommended options to more closely identify structures as equivalent? What options were used for the MC-AFIR of Au_n + H2? 

Many thanks,
Matt

Yesterday, I attended GRRM18 tutorial and have a question.

When SC-AFIR2 is performed (input name: butadiene.com ) to consider dummy EQs, how to understand the Energy in a parenthesis.

For example, EQ2 is dummy EQ with "Energy    = -154.769690740354 (-154.850619271653 :    0.000000000000)", please let us know the meanings of -154.769690740354 and -154.850619271653, respectively. 

%grep Ene butadiene_EQ_list.log

Energy    = -154.864576395665 (-154.864576395665 :    0.000000000000) #EQ0

Energy    = -154.859935087313 (-154.859935087313 :    0.000000000000) #EQ1

Energy    = -154.769690740354 (-154.850619271653 :    0.000000000000) #EQ2...dummy EQ

Energy    = -154.742435832251 (-154.850514028576 :    0.000000000000) #EQ3...dummy EQ

Energy    = -154.703735106368 (-154.841020263992 :    0.000000000000) #EQ4...dummy EQ

Thank you in advance.

We understand that two files are required for the submission, for example, a shell script file (ABC.sh) which is giving the orders to the queuing system and an GRRM input file (ABC.com)  in the same folder.

After we failed one GRRM calculation with an error, and modify/overwrite the input file as the name followed by resubmission, this calculation did not work. We think that the error was caused by the presence of the residual files from the previous failed calculations. Once we deleted all the extra files and left only the ABC.sh and ABC.com,  the calculation runs successfully. Why did this error happen and it is not mentioned in the manual? Is there any possibility that the presence of other files in the same folder can interfere with the GRRM calculation?

Thank you very much for  taking time on so many questions!!

- In the MESX or MECI calculations, (https://afir.sci.hokudai.ac.jp/documents/manual/37) we need to define a Second Input, where we explicitly specify the level of theory and the charge and spin of the other PES that is going to cross the first one. But what we don't see in the manual is how to specify the extra Gaussian input in our second Input, i.e., if we need also to repeat the specification of the extra keywords and lines, like when you define your own basis sets or add ECPs by using a GenECP keyword to the Second Input? or we do not need to repeat that and rather specify in the first input file (the ones defines in the previous GauInpB) ?

https://afir.sci.hokudai.ac.jp/documents/manual/20

Thank you very much again.

-If we want to calculate the IRC trajectory of a structure, it is possible to do it with GRRM with the keyword  IRC, and it will give you the IRC path in both directions, the forward and the backwards direction to the Gradient Vector. Now, if you want only one of the directions of the IRC path, you could use the keyword Meta-IRC to compute ONLY the forward path. is there a way to compute ONLY the backward path?  I am assuming the forward and backward concept from Gaussian, in which they refer to the direction of the gradient Vector, which means that sometimes the Product path can be in the Reverse direction and not the Forward direction. 

https://afir.sci.hokudai.ac.jp/documents/manual/14

- Regarding the use or embedding of the Gaussian program into the GRRM, it is supposed that  through aliases and environment variables we define which version of Gaussian program is connected to the GRRM (how it is explained in the manual in the section "how to run GRRM17 (with Gaussian 09)"( https://afir.sci.hokudai.ac.jp/documents/manual/9). Now, I was checking some of the files generated during a MIN  calculation and a SC-AFIR calculation , specifically the file xxx_PARAM.rrm that is generated during the calculation says explicitly 

"INPUT DATA SET OF THE GRRM VER. 13.X 

 Energy Calculation=GAUSSIAN03"  ( It must be "GRRM VER 17. and ....=GAUSSIAN09" because I am connecting to Gaussian 09.)

- It is supposed that the GRRM programs can be connected to Gaussian programs when you have installed both programs in one computer. What are the commands from the Gaussian program that the GRRM is able to understand in the command line (the line that starts with the # symbol. For example, can I write in this line IOp commands, can I specify implicit solvent such as scrf=PCM, change from Cartesian functions or pure functions (for example, 5d or 6d), What about the command that have and impact (or are needed) for the extra input (which you call GauInpB)  to work? 
In the AFIR manual (“Options for Gaussian 03/09/16”)( https://afir.sci.hokudai.ac.jp/documents/manual/43), there's only the example of the basis set with GenECP but that's it, there's no information regarding the other options such as SCRF or IOP keywords. Thank you.