MRChemSoft / mrchem

MultiResolution Chemistry
GNU Lesser General Public License v3.0
27 stars 21 forks source link

Response initial guess by random dipole perturbation #443

Closed robertodr closed 7 months ago

robertodr commented 1 year ago

The response orbitals are guessed applying a linear combination, with random coefficients, of monomials in x, y, z. Essentially, we're trying to introduce some dipole components into the ground state. Seems to perform marginally better than the zero guess for static/dynamic polarizabilities. It should be more useful for excitation energies, where the zero guess would not work.

stigrj commented 1 year ago

Seems to be missing a CMakeLists in the new test folder

robertodr commented 1 year ago

Ooops! Now the test is actually in there. I'm not quite sure why for non-zero frequency it's giving me a full polarizability tensor though. That's why the test fails...

stigrj commented 1 year ago

Hmm, I see the problem. The property is computed for a particular component only if the computation of the corresponding perturbed orbitals was reported as success. This can happen in one of two ways: either the guess was set up "successfully", or the orbitals were "successfully" converged. The guess criterion accommodates the situation where you want to compute the property directly on a set of pre-computed initial orbitals, without changing/optimizing them.

Possible solutions:

  1. Always report success = false for random initial guesses. I don't see when it would be relevant to compute properties directly from these orbitals. This is a trivial fix, but it means that we are unnecessarily setting up random guess orbitals that are never used (but then again, how often do we run these "incomplete" response calculations?).
  2. Pre-process the guess input in the same way we did for the cube guess, where we changed the guess type in the json input file to none for the components we are not optimizing. The none guess already reports success = false and thus no property is computed.
  3. I guess the full flex solution would be to allow separate guess types for the components from the user input. Something like this:
    Response {
    run = [false, false, true]
    guess_type = [none, none, random]
    }
stigrj commented 1 year ago
  1. Leave the behavior as is, and only test against the last row of the computed tensor.
stigrj commented 1 year ago

There's anyway a logic bug that makes the static case behave as "expected": success_y defaults to false which, means that a static response guess always returns success = false.

ilfreddy commented 7 months ago

We close this for now, to remove some clutter...

ilfreddy commented 7 months ago

DITTO