Issue on SCF convergence in CENSO

[jungsdao]

Hello, First of all, thank you for developing efficient and useful methods for the community. I was trying several runs with CENSO with some geometry contains transition metal. After generating conformer ensemble with CREST in GFNFF level, I ran CENSO subsequently. However, presumably due to the existence of transition metal ( in this case Ni2+ with triplet spin state), part0 single point run encountered SCF convergence issue. I'm using orca in conjunction with CENSO and b97-3c (with automatic basis set) is used for part0. My question is, how can I manually adjust SCF convergence tags for ORCA? Please find attached my input (censo.inp, crest_conformers.xyz ) and output file (stdout.log). Any general comments and advices are welcomed! Many thanks in advance :)

CENSO_question.zip

[fabothch]

Hi,

part0 or the "cheap prescreening" part is useful for structure ensembles with a large number of conformers. E.g. several hundred. In this case a very fast single-point calculation (with a small basis set) can aid in removing definitely high lying conformers. In your case there are only very few conformers and I would simply turn part0 off and just start from part1.

To clarify: CENSO uses a multi-level sorting scheme. And moving up each part, tighter convergence settings are applied.

The idea of CENSO is to have an easy to use program which automates many details and interfaces to other QM codes. Therefore there is currently no user accessible way of changing the SCF convergence settings (other than adjusting the python code). I will have a look whether I can implement it and if it does not introduce to much confusion I will give it a try.

Best, Fabian

[jungsdao]

Dear Fabian,

thank you for your reply! I turned off part0 and started from part1, it seems to work way better. However, for some systems still SCF convergence matters substantially leaving whole CONFs with error message. I tried to slightly modify censo_qm/orca_job.py as following, but the modification doesn't take effect immediately. Should I install again with modified python file and generate binary censo file again for this?

Best regards, Hyunwook

("default", [ "! smallprint printgap noloewdin", "! NOSOSCF", "%scf" , " maxiter 500", "end", "%MaxCore 8000", "%output", " print[P_BondOrder_M] 1", " print[P_Mayer] 1", " print[P_basis] 2", "end", ]

[fabothch]

Dear Hyunwook,

creating a binary censo file is just a workaround for easy distribution and not caring about existing and or required python installations. You can change the file censo_qm/orca_job.py and then install censo using pip:

$ pip install --upgrade pip
$ pip install --editable .

This should make censo with your changes available. But are you sure that only increasing the number of iterations within the SCF is aiding in SCF convergence ?

Best,

Fabian

[jungsdao]

Dear Fabian,

Thank you for your comments. For several cases I have, increasing SCF step definitely seems to help convergence but that might not be ultimate solution.

I have frequently encountered a kind of error as follows I'm not sure what causes these kinds of error.. I would very appreciated if you could give me hint on this issue.

Best, Hyunwook

========================================================= Traceback (most recent call last): File "censo_qm/parallel.py", line 49, in execute_data File "censo_qm/orca_job.py", line 861, in execute File "censo_qm/orca_job.py", line 627, in _xtbopt ValueError: could not convert string to float: ' **\n'

ERROR in part2!

The error-message is could not convert string to float: ' **\n'

**Traceback for debugging:**

---

Going to exit!

stdout.log.zip

[fabothch]

Hi,

which xtb version are you using? And it seems that a calculation might have terminated wrongly and therefore a false value is converted. Can you find out if in your optimizations a calculation crashed and send it to me? I have not encountered this error before.

Best,

Fabian

[fabothch]

I just added a try and except statement which is hopefully filtering the false value conversions (though I do not know why they appear). Will be available in 1.0.9 later today.

[jungsdao]

Dear Fabian,

I'm currently using xib version 6.4.0 which is the latest one. I've examined CONF*** folders and discovered abnormal termination in CONF307. The error seems to related with the parallelization with following messages within output. I have no idea why this happens but if this can be bypassed, that would be nice! This could be also problem with the cluster I'm using.

Best regards Hyunwook

[n103.hpc:200446] 15 more processes have sent help message help-mpi-btl-openib.txt / no device params found' '[n103.hpc:200446] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages' '[n103.hpc:200446] 7 more processes have sent help message help-mpi-btl-openib-cpc-base.txt / no cpcs for port

opt-part2.out.zip

[fabothch]

Ok,

older xtb versions are not compatible so that is good! I will update the CENSO version soon and you can test if I fixed it.

Best,

Fabian

[jungsdao]

Thank you for your update!

I have one more question, I've read your paper https://pubs.acs.org/doi/10.1021/acs.jpca.1c00971 on CENSO. You have used r2SCAN-3c in part2 for geometry optimization and performed single point energy evaluation with another functional in part3. In practice, in the case of interfacing with ORCA, this is not available for now since ORCA currently does not support r2SCAN-3c. It seems geometry optimization with r2SCAN-3c generally gives pretty reasonable geometry for subsequent single point energy calculation. However, I'm using PBEh-3c for geometry optimization in part2 and wb97x-d3 for single point energy calculation in part3. This might need some assessment on the parallelism in PES, but I just want to know how do you think of this workflow. Do you think accepting the the averaged Gibbs energy value (without additional geom opt with wb97x-d3 ) can be acceptable within this setting? Thank you for your help

Best, Hyunwook

[fabothch]

Dear Hyunwook,

you are right, r2scan-3c is not available in the current ORCA version. Depending on the investigated systems (organic or containing transition metal compounds) I would choose pbeh-3c or b97-3c as the functional for geometry optimization. Using a higher level method for single-point evaluation on the geometry of a lower level method is common practice in many multi-level approaches. It is of course a good strategy to investigate the parallelism of the different methods employed. wb97x-d3 is a good hybrid functional which is also recommended by the GMTKN55 evaluation. I personally would prefer the combination of b97-3c and wb97x-d3/basis-set.

Best,

Fabian