One of my test jobs is consistently failing with a fatal error with a newly installed version 5.4.2. It’s a geometry optimisation of benzene at 3-21G*. The job works fine with 5.4.1 and previous versions, and if I change basis set to 3-21G or 6-31G* it also runs fine in 5.4.2. The error message I get is:
Atom C is not defined in /software/qchem_v5.4.2/qcaux/basis/3-21G.pol.
Please use different basis set or customized basis (basis = gen).
Q-Chem fatal error occurred in module forms1/AtomicBasis.C, line 394:
One of the atom can be found in the polarization funciton file
The file referred to (3-21G.pol) is present, readable and identical to the one in our previous version.
Input file is below:
We added a crash for undefined basis to avoid misinterpretation in 5.4.2. Note that the polarization function of C/H not defined in standard basis set. In the previous versions, 3-21G* will produce the same result as 3-21G but this behavior will make users think polarization function is added to C/H but it is not in reality. The polarization function of 3-21G* is only available for Na, Mg, Al, Si, P, S , and Cl. You may add your own polarization function through basis = gen. Otherwise, you can safely use basis = 3-21G to get the same result with any crash for the presented system.
Thanks for your response. Can I ask if this was a requested change? If I understand correctly, the previous results would not have been incorrect - if the molecule contains no elements for which polarization functions are defined then 3-21G* should give the same result as 3-21G? A warning message sounds like more appropriate behaviour than a fatal error in this case?
My issue is that we have an internal interface that enables some non-expert users to run simple calculations, and it sounds like I will now need to check every time whether this situation will arise - not just with 3-21G*, which is obviously a fairly trivial case, but potentially for other basis sets too? Given that the results would not be “wrong”, it seems like overkill to me?
The new behavior for polarization/diffuse functions is on par with the behavior for basis set. Say, if you request 6-31G for system containing iodine, Q-Chem will crash with similar error message. As you mentioned, it can be handled as warning. However, the warning message can be ignored quite easily so a user’s judgement will be misled as well by thinking they actually put polarization/diffuse function on all atoms. Once they found the problem, they may have to rerun the “normally-terminated” calculations. What’s worse, those calculations may be non-trivial and take months to finish.
I can understand your concern for simple calculations as the error could serve as bad impression for non-expert/new users. Nonetheless, the more inconsistency a program can catch at the beginning the more users can benefit from saving time for calculations in long run. Yet, different opinions are welcome.
Thanks for your reply. I appreciate that you have a diverse user base, and finding solutions that work for everyone must be challenging! I’m in the pharma industry, so we are working with “small” (up to maybe 60 or 70 atoms) organic molecules.
I’ve run a few more test cases, and I note that dichlorobenzene also fails at 3-21G*. I assume from this that the new rules require all atoms to have polarization (or diffuse) functions defined? Is that the desired behaviour? Wouldn’t dichlorobenzene genuinely give different results at 3-21G* compared to 3-21G?
I appreciate your argument about basis functions, and for your iodine example I have no issue with the program failing as it’s not clear how to proceed. I’m not sure polarization functions are quite the same - if 3-21G* only specifies polarization functions on second row elements then I would argue it is perfectly fine for benzene to behave identically at 3-21G and 3-21G*. That is the correct behaviour from the definition of the basis set.
Anyway, just offering a different opinion. For this specific case I can work around the problem by removing 3-21G* as an option for our users and replacing it with 3-21G. All of our molecules will contain carbon and hydrogen so 3-21G* will never work for us. I’d rather not have to do that as we do have molecules containing S or Cl. I am also a little concerned that I will run into the same problem with different basis sets, but I guess I can come back to you if that happens.
One final thought - would it be possible to add a keyword that turned this into a warning rather than an error? That way you could leave the default behaviour as it is in 5.4.2, but give users the option of returning to the old way.
@kyliu I think this idea deserves careful consideration. By way of analogy, 6-31G* has no effect on hydrogen atoms (6-31G is applied instead) and does not cause a crash, even a warning.
For what it’s worth, I think I agree that it would be better to have 3-21G* essentially aliased to 3-21G for elements where polarization functions are not defined, as we do with hydrogen for 6-31G*, although possibly with a warning to the user. We used 3-21G* for QM/MM a couple of years ago and got pretty far into before realizing there were no polarization functions on 2nd-row atoms, which by analogy to 6-31G* I thought there would be.
Thank you for the feedback. Yes, calculations of 5.4.2 require all atoms to have defined polarization/diffuse functions. For dichlorobenzene, you have to use the following setup.
If you can let us know more about how you generate the input files (through support@q-chem.com), we may be able to help you to make the corresponding changes. For now, I would imagine you can change basis to gen and have all the the definitions, say Si, P, S, or Cl, in $basis for 3-21G*. I’ll see if I can find more alternatives.
I have submitted a feature request for either making undefined pol/dif as warning or implementing a rem variable for backward compatibility. Thanks again for sharing your opinions. I do appreciate them.
1/11/2022 1:38 PM PT Edit: Please email support@q-chem.com. We prepared files in qcaux folder so you can use 3-21G* as before without changing your own workflow/scripts. The hack is to add dummy atoms in .pol files so Q-Chem won’t crash. Just in case you would like to change the file yourself. You just append dummy atoms after AR as follows in 3-21G.pol (qcaux/basis).
BASIS="3-21G* Polarization"
NA 0
D 1 1.00
0.17500000 1.00000000
****
MG 0
D 1 1.00
0.17500000 1.00000000
****
AL 0
D 1 1.00
0.32500000 1.00000000
****
SI 0
D 1 1.00
0.45000000 1.00000000
****
P 0
D 1 1.00
0.55000000 1.00000000
****
S 0
D 1 1.00
0.65000000 1.00000000
****
CL 0
D 1 1.00
0.75000000 1.00000000
****
AR 0
D 1 1.00
0.85000000 1.00000000
****
H 0
****
HE 0
****
LI 0
****
BE 0
****
B 0
****
C 0
****
N 0
****
O 0
****
F 0
****
NE 0
****
K 0
****
CA 0
****
...etc
****
For this specific case I can work around the problem by removing 3-21G* as an option for our users and replacing it with 3-21G. All of our molecules will contain carbon and hydrogen so 3-21G* will never work for us. I’d rather not have to do that as we do have molecules containing S or Cl. I am also a little concerned that I will run into the same problem with different basis sets, but I guess I can come back to you if that happens.