Geometry Optimization within QC Codes about qcengine HOT 7 CLOSED

Great, this is not exactly an uncommon request :). I think a ProcedureHarness is the way forward here where this harness would inherit from the NWChemHarness. The main caveat here is that the program in the ProcedureHarness could only be NWChem. So you have this inner/outer program specification which must be the same.

You should be able to share a great deal of infrastructure, but the output parsing will be a bit different.

I think we would want to refactor the Harness a bit to be a general construct rather than a program/procedure specific one as well. So some thought would need to go into here.

As a note this should be thought about in a general manner of "my foundational program can do many things, how do I box its capabilities where the QCArchive architecture views it as separate pieces".

@Lnaden @sjayellis @mattwelborn @loriab might want to comment here as well.

from qcengine.

Is this a problem that MDI could solve? (Since the concern is about communication performance between geometric and nwchem, rather than needing to use nwchem's geometry optimizer specifically)

from qcengine.

A few thoughts:

• Last time I broached using NWChem optimizer in a standalone (aka restart) mode with TLW, she wasn't optimistic.
• I definitely support ProcedureHarness for this. Even if can't inherit from the NWChemHarness, should be able to expand the parsing infrastructure to support handling optimizations. So, parse_output can call functions from the programharness.
• As half a model, the Cfour harness breaks up instantiation outputs into optimization passes, then applies a normal AtomicResult parsing to each. Cfour internal optimizer not fit for Procedure treatment, though, because it needs internal coordinates as input, and that's not in models.Molecule.
• The "my foundational program can do many things, how do I box its capabilities where the QCArchive architecture views it as separate pieces" extensions where programs can be tricked (i.e., native files imitated) into broader input sources is smaller than you might expect since QC codes are so tightly coupled. But the simpler nwchem@nwchem setup proposed here is more feasible and will likely be informative. Personally, I like the nwchem optimizer!
• These must be mighty short gradient calcs to be worried they'll be dwarfed by startup costs?
• I hope nwc has an opt history file that can be dragged along.

from qcengine.

@mattwelborn @taylor-a-barnes I think that this is problem that MDI will solve in the future (performance). But we also need to consider specific algorithms in NWChem (STEPPER) and Gaussian that do not have OSS driver counterparts. As noted QC programs are often very tightly coupled and difficult to pry apart in the manner that we wish, so this is more of a question of what do we need in the next month?

from qcengine.

I'll try to make a ProcedureHarness for the NWChem optimizer, since that seems to be a simpler route forward and let you know if I see much of an improvement over geoMETRIC+QCEngine

from qcengine.

Great! Ping us if you have any issues. I think one item to note is that we may not be able to parse all intermediate gradients easily.

from qcengine.

I made a procedure harness for NWChem's relaxation awhile back: #281

from qcengine.