-
Notifications
You must be signed in to change notification settings - Fork 208
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
Instance property should be class property #519
Comments
mrossinek
added a commit
to mrossinek/qiskit-nature
that referenced
this issue
Jan 27, 2022
This is actually required for the matrices loaded during ElectronicIntegrals.from_hdf5 to be in the correct order!
Anthony-Gandon
pushed a commit
to Anthony-Gandon/qiskit-nature
that referenced
this issue
May 25, 2023
* WIP: HDF5-integration for property framework This is an initial proof-of-concept implementation. This needs to be reviewed extensively. * Clean up interface * refactor: let ElectronicIntegrals derive from PseudoProperty * refactor: let Molecule derive from PseudoProperty * feat: implement DriverMetadata HDF5 methods * feat: add toggle to include PseudoProperty objects in GroupedProperty iteration * feat: implement ParticleNumber HDF5 methods * feat: implement AngularMomentum and Magnetization HDF5 methods * feat: implement ElectronicBasisTransform HDF5 methods * fix: lint * fix: fix unittests * remove comment * fix: spell * feat: also store Qiskit Nature version * handle potential error cases in Property.import_and_build_from_hdf5 * Fix copyright * feat: introduce individual version numbers per Property class * WIP: HDF5 integration into vibrational properties * Fix copyright * fix: property tutorial * Update typehints * Run black * Remove @AbstractMethod from Property.from_hdf5 This needs to be removed in order to ensure that the stable tutorials remain working. * Add more missing typehints * refactor: introduce HDF5Storable Protocol * refactor: remove PseudoProperty in favor of Interpretable Protocol The PseudoProperty class effectively removes everything which defines the Property class (the interpret method). So instead of having such a pseudo-class, all previous PseudoProperty subclass are now directly Property subclasses and the `interpret()` method existence is handled via the `Interpretable` Protocol. * Fix linters * Fix ASTransformer caught error type * Fix copyright * Fix imports * More guards against Property type * More import fixes * fix: property tutorial * fix: ElectronicStructureDriverResult.__str__ * refactor: remove Property base class where not needed * test: basic hdf5 method unittests * test: *StructureDriverResult from_hdf5 methods * docs: HDF5 documentation * refactor: formally deprecate PseudoProperty class * docs: actual HDF5 save and load examples * Fix spell * fix: avoid name clash with multiple atoms of same kind * fix: ElectronicEnergy.from_hdf5 group access * Update unittest HDF5 resource * fix: ParticleNumber.from_hdf5 occupation dataset access * Fix qiskit-community#519 This is actually required for the matrices loaded during ElectronicIntegrals.from_hdf5 to be in the correct order! * Update qiskit_nature/properties/property.py Co-authored-by: Steve Wood <[email protected]> * Update docs * Rename save_to_hdf5(..., force -> replace) * refactor: fix DriverMetadata HDF5 attribute names * refactor: make from_hdf5 a staticmethod * feat: store Molecule.units in HDF5 * fix: update expected HDF5 result * docs: include backwards compatibility expectations * feat: add skip_unreadable_data toggle to HDF5 loading methods * Fix spell Apparently Sphinx can now use `kwds` instead of `kwargs` * docs: explicitly request error raising * docs: use `:func:` instead of `:class:` * docs: ensure *StructureDriverResults are documented * refactor: enforce keyword arguments in hdf5 module * Update driver return types While the previous return types were not wrong, for documentation purposes using these concrete implementations is a bit nicer. * Run black * Add reno * feat: use Molecule.units during from_hdf5 * test: refactor _hdf5 method tests Instead of hard-coding the expected HDF5 file structure, we test that `to_hdf5` and `from_hdf5` work consistently with each other. The `test_to_hdf5` tests ensure that this method executes correctly (i.e. without errors). The `from_hdf5` tests ensure that first writing and subsequently reading a property from a file produces an identical instance. In the future, once version numbers of certain properties may increase, we should store HDF5 files and compare those against expected instances. * fix: README test The README test previously failed because the iteration over the auxiliary operator observables in the ElectronicStructureResult is currently unable to handle the lack of certain properties which have always been evaluated for legacy reasons (AngularMomentum, Magnetization). Even if we were to default them to an empty list instead of None, while the zip command would execute normally, no results would be printed since zip stops after the shortest length. That being said, fixing ElectronicStructureResult is not the solution right now in any case, since a user would be unable to manually request the computation of AngularMomentum and Magnetization before we resolve the issue ý¿¿¼£�qiskit-community#312 Thus, this commit reverts the exclusion of these auxiliary operators in the case of `settings.dict_aux_operators`. * refactor: use only public API in PropertyTest * refactor: update type hints * fix: update TestVibrationalStructureDriverResult to G16 Rev.C01 Co-authored-by: Steve Wood <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
What is happening?
please
How can we reproduce the issue?
see
What should happen?
below
Any suggestions?
This property is never mutated as far as I can tell.
https://github.com/Qiskit/qiskit-nature/blob/a8a5d9b6bd6f02078ff6bdd56f1c98eb3102be45/qiskit_nature/properties/second_quantization/electronic/integrals/two_body_electronic_integrals.py#L61
(The same goes for the same property in the base type and sibling type)
Should this not be a class property? Or maybe a future development will allow mutation ?
The text was updated successfully, but these errors were encountered: