-
Notifications
You must be signed in to change notification settings - Fork 475
Add creation of Eigen::Map representations of Psi4 matrices #3143
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
Conversation
c606254 to
d240948
Compare
The entire |
The reason I didn't mark anything here as an API change is because neither of the new The |
6c9eec2 to
430ecc4
Compare
psi4/src/psi4/libmints/matrix.cc
Outdated
| eigen_maps.emplace_back(get_pointer(h), rowdim(h), coldim(h)); | ||
| } | ||
|
|
||
| return std::move(eigen_maps); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably not "necessary", strictly speaking, but I did this on the understanding that doing a std::move on the output vector would be more efficient due to avoiding unnecessary object copying/duplication. Happy to change if this is deemed unnecessary, however.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't return value optimization cover this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, when I double-checked my assumption online based on your inquiry, it does seem that std::move can hinder RVO. So with that in mind, I'll get rid of the move.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done and done!
loriab
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks!
I agree that this is an API change on the plugin side, and thanks for pointing that out @TiborGY . It's less disruptive than some b/c it's an addition. And we've never achieved API stability on the c++ side; plugins builds just have to pin to a particular psi4 bld.
|
All right, added a note about the relevant API change as introduced by this PR! |
| #include <eigen3/Eigen/Core> | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this a new requirement? I don't think Eigen3 has been used in Psi4 previously...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I did mean to mention this. Correct that Psi4 doesn't use Eigen3 itself. But Eigen3 and boost header-only libs are needed to compile against L2 header-only, so it isn't a net new requirement.
Description
This is something I have been working on as part of the upcoming Psi4-GauXC interface; but it seems to be of interest for other use cases, so I will be adding it here as a separate PR.
What this change does, is it adds two new member functions to the
Psi4::Matrixclass,eigen_map()andeigen_maps(). Both of these functions serve the same purpose - take the Psi4 matrix in question and return a representation of said matrix through Eigen'sMapobjects. TheEigen::Mapclass acts the same way as a normalEigen::Matrixobject, but uses an external array as its data buffer rather than an internal data buffer. Theeigen_map()andeigen_maps()functions, then, return Eigen matrix-like objects that directly link with the Psi4 matrix data buffer of the Psi4 matrix for which the function was called. This provides an efficient fashion by which to utilize Psi4 matrices in contexts which require Eigen constructs, with no data deepcopying or Eigen-to-Psi4 back-conversions required.There is a key difference between the two functions.
eigen_map()assumes that the matrix has a single irrep, and returns a singleEigen::Mapobject.eigen_maps(), on the other hand, is used for matrices with multiple irreps, and returns astd::vectorofEigen::Mapobjects, eachMapin thevectorcorresponding to one irrep of the Psi4 matrix.User API & Changelog headlines
eigen_map()andeigen_maps(), usable in Psi4 plugins and downstream programs, that return a formulation of the callingPsi::Matrixobject, that is usable in contexts whereEigen::Matrixobjects are required/desired.Dev notes & details
Psi4::Matrix,eigen_map()andeigen_maps(), that returnEigen::Maprepresentations of the Psi4 matrix object.Questions
Notes
Eigen::Mapturns out to be a bit ugly, as it is a class template that, to forward declare, ends up requiring forward declarations for other Eigen classes and enums (such asStrideandAlignmentType) that aren't specifically necessary for the Psi4 use case. Therefore, I have skipped forward declarations here.eigen_map()function, as I have implemented these PR changes into my Psi-GauXC interface, whereineigen_map()replaces the original formulation I used for the equivalent result.eigen_maps(), however, is currently untested as there is no current use case for it yet, and should thus be considered experimental.Checklist
Status