add REMP methods (take 2)

[loriab]

Description

Not for review. This in contents is much a duplicate of #2354, except that was (18 months ago master + SB commits + UB commits + SB commits, all with some master commits sprinkled in) and this is (current master + UB commits + 1 LAB commit with occ/dfocc testing + SB commits). This will have more testing added and be broken up into further PRs. Just notification of progress, @behnle. Thanks for the very nice contribution.

Status

• [ ] Ready for review
• [ ] Ready for merge

[behnle]

Thank you very much, @loriab. Is there a rough schedule whether and if yes, when this will make it into the master? We are currently preparing a paper which makes use of this code and it would be nice if it was available publicly in the not-too-far future :innocent:. Is there anything i can do for speeding up this progress?

[JonathonMisiewicz]

We definitely plan to get this into master, but Lori would be the one with reliable time estimates.

[loriab]

I've got all the parts that affect REMP ready. Final stage is to persuade dfocc to converge simple molecules to default tolerance under default conditions :-)

I'll update this PR as the amalgamation, then break off just occ changes for you and other to look over, @behnle. A couple easy questions:

• Do you want REMP controlled by mp_type (covers all MPn > 2 and ZAPT) or cc_type (covers CEPA and CC)? Either is sensible, so your call.
• Any need to future-proof QCVariables with REMP2 (or REMP2,3!)?

[behnle]

Thanks for your work.

• Do you want REMP controlled by mp_type (covers all MPn > 2 and ZAPT) or cc_type (covers CEPA and CC)? Either is sensible, so your call.

Actually not so easy :smile:, as it is a blend of MP and CEPA. But as it is in the occ/dfocc module, i'll vote for cc_type for the moment.

• Any need to future-proof QCVariables with REMP2 (or REMP2,3!)?

Currently not, it is not entirely clear whether and how this project is continued. 3rd order might come, but there are no concrete plans.

[loriab]

Hooray, we finally have clean CI and tests on this combo dfocc+remp PR!

Now, I'll break off occ as the first piece for review.

I think I favor REMP to REMP2 in QCVariables, just to be specific.

[loriab]

I think I favor REMP to REMP2 in QCVariables, just to be specific.

Hmm, that means the the calls change also to e.g., energy("oremp2"). That's consistent with energy("mp2"), so fine by me. But others can weigh in before I start a grand search-and-replace.

[behnle]

Wow, thanks for your work. I'm completely fine with changing REMP/OREMP to REMP2/OREMP2. (with the limitation that it's the 2nd order energy/1st order wavefunction, but this is equivalent in the case of MP2)

[JonathonMisiewicz]

@loriab Can we close this? I think this is wrapped up by now.

[loriab]

@loriab Can we close this? I think this is wrapped up by now.

Sure, go ahead. I think I was using it to track a snapshot of file, but it's outlived its usefulness. And certainly REMP is wrapped up.