Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crest 3 QCG, final xTB optimisations not using the available cores #297

Closed
andrewtarzia opened this issue May 1, 2024 · 6 comments
Closed

Comments

@andrewtarzia
Copy link

As in title, a QCG run seems to be hanging after adding the requested number of solvents, but looking at htop I see the following command is running:

xtb cluster.xyz --gfn2 --opt best.xyz best_after_gen.xyz cluster.coord cluster.xyz cluster_cavity.coord final_structures.xyz optimized_structures.xyz solute solute_cavity.cood solute_cut.cood .........

As I understand, this is the final xtb optimisation of cluster.xyz, right? However, it seems to only be using 1 thread. Is there a way to change this?

My crest version: Version 3.0, Sat Apr 6 18:06:37 UTC 2024 commit (d321183) compiled by 'runner@fv-az778-216'

Crest command: crest input_solute.xyz --qcg input_solvent.xyz --nsolv 10 -xnam xtb --alpb water -chrg 0 -uhf 0 --gfn2 -T 6 --optlev crude --nopreopt --fixsolute -I det_control.in

@andrewtarzia
Copy link
Author

An alternative option is to turn off this final optimisation, which I would actually prefer. Is that possible?

pprcht added a commit to pprcht/crest that referenced this issue May 3, 2024
@pprcht
Copy link
Contributor

pprcht commented May 3, 2024

I've tried to fix some things with regards to this issue in #300 and the continuous release.
The final optimization can be turned off now with -no_final_opt_gfn2

@andrewtarzia
Copy link
Author

Hey @pprcht , thank you for this! --no_final_opt_gfn2 seems to avoid this issue. However, cluster_optimized.xyz is still written to file and seems to be very slightly different to cluster.xyz. Is that expected?

@pprcht
Copy link
Contributor

pprcht commented May 4, 2024

From my understanding of the code, yes, that seems to be normal. @cplett is the author and maintainer of QCG.
What I read from the routine is that cluster.xyz is put forth for one final optimization to produce cluster_optimized.xyz. Even when cluster.xyz is a minimum already, the optimization will take one or two tiny steps. My guess is that's what you're seeing.

Have you by any chance checked if #300 also resolves your issue #294?

@andrewtarzia
Copy link
Author

Ok, thank you again! I will update on #294 in that conversation.

Andrew

@pprcht
Copy link
Contributor

pprcht commented May 6, 2024

I'm closing the issue for now, if something else related to this comes up feel free to comment here again.

@pprcht pprcht closed this as completed May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants