adapt for QCSchema v2 and Python v3.14#110
Conversation
…ma v2-adapted psi4
…sed QCEngine and new v0.5x QCSchema v2-based QCEngine
…t_through_json excluded)
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #110 +/- ##
==========================================
- Coverage 82.74% 82.12% -0.62%
==========================================
Files 36 36
Lines 7950 8068 +118
==========================================
+ Hits 6578 6626 +48
- Misses 1372 1442 +70 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
psi-rking
left a comment
There was a problem hiding this comment.
Assuming you can get this to run with v1 and v2 QCSchema, looks good to me!
On the output, it would be good to double-check that this is the best source of output data, but I don't think this need hold up your pull request here. Any tweaks there should not involve changes to format, right?
| from qcelemental.models.v2 import Molecule, OptimizationInput, Model, AtomicSpecification | ||
|
|
||
| # WARNING. The user MUST set fix_com and fix_orientation to True. | ||
| # optimization will almost certainly fail otherwise |
There was a problem hiding this comment.
Why must orientation be fixed? Because qcengine doesn't guarantee gradients come back with the same COM/orientation? Or because qcengine has its own orientation? Just wondering.
There was a problem hiding this comment.
I was just copying the warning from the v1 snippet. But yes, it's b/c input Cart w/o fix_* (or w/False) will return gradient in whatever the QC program's natural orientation is. fix_*=True demands results in input Cart orientation. At least one of your routes imposes the fix_*=True, but I didn't change or enforce that more or universally.
|
|
||
| result = optking.optimize_psi4("ccsd") | ||
| print(result["trajectory"][-1].keys()) | ||
| trajkey = "trajectory" if _schver == 1 else "trajectory_results" |
There was a problem hiding this comment.
That change was getting a little annoying, I bet?
| if spec_schema_name == "qcschema_many_body_specification": | ||
| model = "(proc_spec_in_options)" | ||
| options = opt_input["specification"]["specification"] | ||
| if "model" in (qc := options["specification"]): # single spec |
There was a problem hiding this comment.
I think that I understand what this is doing; pretty cool!
|
When I was last doing docs updates, the docstrings in |
|
I'm going to approve and will come back later to check SF4 quasilinear. That test breaking is not surprising - just a reminder to get molsym integrated. |
AlexHeide
left a comment
There was a problem hiding this comment.
Thank you for all the code updates and keeping optking up to date with QC*
|
LGTM. Now that I've added some things I can't review though 😄 |
|
LGTM. Are we ready to merge?
On the SF4 quasilinear case, optking has been unreliable in the past. I
presume the problem is with linear bends, but I haven't looked at it in
awhile. I'm interested in a keyword that would turn all derivative B
matrices over to numerical determination. Then we only need handle
discontinuities in the internal coordinate itself. For the purposes of
optimization only, there never was a good reason to use analytic derivative
expressions that introduce additional singularities.
…On Fri, Apr 17, 2026 at 9:45 AM AlexHeide ***@***.***> wrote:
*AlexHeide* left a comment (psi-rking/optking#110)
<#110?email_source=notifications&email_token=AA4C4TFCZ6H3ZLY3H23HNJ34WI7RFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRWHEYDEMBRGQ3KM4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4269020146>
LGTM. Now that I've added some things I can't review though 😄
—
Reply to this email directly, view it on GitHub
<#110?email_source=notifications&email_token=AA4C4TFCZ6H3ZLY3H23HNJ34WI7RFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRWHEYDEMBRGQ3KM4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4269020146>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4C4TBTQHIYEX7FIKWIVCD4WI7RFAVCNFSM6AAAAACWCPXEWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENRZGAZDAMJUGY>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
The only thing I've though of that I haven't tested lately is new optking with old/current psi4. Though probably your CI covers that ... I have so many versions running around that I've lost reasoning capacity. I've just done a quick test locally, and it looks good. I think it's ready for merge and tag. And if we're lucky it'll need zero-to-minimal tuneups for the next Psi4 release. Thanks! |
Goals
Sorry for the monster PR. Basic goals are as it says on the tin:
Notes
Molsys.from_psi4,Molsys.to_schema,CustomHelper.__init__(default to 1),CustomHelper.from_dict(default to 1),from_dict(default to 1),from_psi4(default to 1),ComputeWrapper/Psi4/QCEngine/UserComputer.__init__/init_fullnow take schema version and protocols since OptimizationProtocols are a new class,make_computer_from_dictlikewise take version and protocolswrite_opt_xyz_trajectory,Helper.to_dict,from_schema,prepare_opt_output,initialize_from_psi4(acts on whether psi4 is pre- or post- my Py314 and QCSchema v2 psi4/psi4#3341 PR),optimize_qcengine(detects by schema structure),make_computer(detects MBE vs plain opt and 1 vs 2),ComputeWrapper/Psi4/QCEngine/UserComputer.generate_schema_input/generate_schema_input_for_procedureprepare_opt_output. Is there a better way to collect properties? In particular, it'd be nice to get return_gradient from optking innards, not from trajectory, in case of an energy driver or a single atom or absent trajectory. Also, it'd be nice to get rmsd, max forces etc. against which convergence is judged. properties needs to be very reliably populated.OptimizationInput/Resultrather than the non-unified and experimentalGeneralizedOptimizationInput/Resultfor v1 that you merged before. I'm plain killing off the GenOpt for v1, so those tests are no more.utils.psi4_runs_v2_qcschemato a lot of your tests. note that unlike QCEngine, v1 and v2 aren't being tested simultaneously through parameterization. Rather, if it detects a psi4 that can run v2, it runs it, and otherwise it runs v1. A corollary is that v2 isn't much tested in CI b/c there is not conda psi4 with v2 released. But this is clean for a local psi4 with py314 and QCSchema v2 that I have. A few tests do parameterize v1 and v2 explicitly, but it isn't most.packagingadded to easily compare versionsbase-next, but it isn't testing a lot b/c no v2 psi4 availableKnown Problems
Next Steps
v0.5release of this in the next couple weeks. I can work on Psi4 with internal optking builds for a while. How does that timeframe sound?Added After Above