-
Notifications
You must be signed in to change notification settings - Fork 7
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
Develop/properties #8
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ic package (this package) (2) incorporating the prototype in the new aiida StructureData type. - up to now, properties (Magnetization only, for now Pbc are not yet migrated) and new related classes (BaseProperty, PropertyInfo, PropertyMixinMetaclass, HasPropertyMixin) are included here. - I introduced the StructureMeta metaclass, to avoid metaclass conflicts in the StructureData class. Moreover, in the order of inheritance I put first the HasPropertyMixin class with respect to the Data class, otherwise the new node results already stored before instantiation. - Added new method to the StructureData, to manage properties (which are store in self.base.attributes.get("_property_attributes"): get_property_attribute and set_property. the last method should be used also by built-in methods of the single properties that initialize the given property. (3) added a "pseudo_test.py" script to test the new functionalities of the StructureData
(1) moving from structure.py to property.py all the classes used in the definition of a property in the StructureData node (2) creation of the magnetic and hubbard properties (in magnetic.py and hubbard.py). Magnetic is still under some development. (3) The hubbard.py is actually very similar to the aiida-core/src/aiida_quantumespresso/common/hubbard.py file: it is the same file but adjusted to have the Hubbard class as BaseProperty, plus some fixing to support the parent feature (see property.py) and a consistent way to generate the hubbard property from built-in-methods (like the from_list() one). - set default value for the input parameters of the Hubbard class (needed to initialize the class correctly as Hubbard and not Property) - set_property method added in the return of the from_list method of the Hubbard class - the from_list method is no more a static method of the class. - adding hubbard_test.py to test that the property can be set by using the from_list method. (4) For now, the hubbard property is stored in the DB, not in the repository as the old implementation; TO CHANGE (5) TO ADD the methods that are contained in the HubbardStructureData of the QE plugin; I think this can be done easily, I will do it in the next push
…ry-based approach and the sites re-definition. (1) moving methods from HubbardStructureData - qe plugin - to Hubbard (aiida-atomistic). - still sites are not included in this move; for now the related @Property methods (see HubbardStructureData) are not supported - updated the hubbard_test.py in order to try the built-in method 'append_hubbard_parameter'. (2) repository-based storage of Hubbard property: this includes changes in the fset and fget methods of the PropertyMixin class, name _set_property and _get_property. STATE-OF-THE-ART: only the setter method for db-based quantities is created explicitely, as _database_wise_setter of HasPropertyMixin (in property.py). but it can be readily incorporated again in the _set_property method of the HasPropertyMixin class.
For now we support only collinear case, kind-wise. This means that automatically kinds are update, if magnetization is set via the `set_from_components` method. Also, more on the Hubbard property. See below. (1) Input parameters accepted are: >moments: List[Tuple[float,float,float]] = Field(default=None) #should be validated against the number of sites. >collinear_kind_moments: Dict[str,float] = Field(default=None) >units: Literal["Bohr_magneton"] = "Bohr_magneton" (2) built-in method for setting the magnetization property: > set_from_components( self, magnetic_moment_per_site: List[float], coordinates: Literal["cartesian","spherical","collinear"] = "cartesian", use_kinds: bool = True, atol: float = 0.5, ztol: float = 0.49, ) (3) new Hubbard utils for QE is in the atomistic package - for now some changes wrt Lorenzo implementation: - hubbard.parameters => hubbard["parameters"] - hubbard.projectors => hubbard["projectors"] - hubbard.formulation => hubbard["formulation"] - (4) new Magnetic utils for QE is in the atomistic package - for now (5) folder aiida_atomistic/data/structure/tests with a collection of hand made tests. These are meant to be used to build the proper pytests.
…r multiple elements. The problem was a structure.clear_sites() done inside the loop.
…ch may cause problems -adding the possibility to provide a dictionary of magmoms per kinds to set magnetization (per site) -adding a line in the StructureData user stories
Missing: - developer guide for plugin usage of SData, - single property sections - query structuredata property-wise - custom properties section
…ructure/new_implementation.ipynb file. In the following we define the new StructureData class, here named `StructureData_prototype` for simplicity, as it should be implemented in the `aiida-atomistic` package. We then define the `PropertyCollector` class, which manages all the properties taking care of all data validation and storage instructions. Instance of this class will be created within the initialization of the StructureData instance and is stored under the `properties` attribute. In the final implementation, original StructureData will be named `LegacyStructureData` and StructureData_prototype `StructureData`. - properties are stored under the `properties` attribute of the `StructureData` instance. This attribute is immutable. `STATUS: done`; - the `properties` attribute is a dictionary, keys being the name of each property and values being a dictionary with the information about the property, which we will store when the StructureData node is stored in the AiiDA db. `STATUS: storage part to be done`; - information about a property can be provided in only one format (we may implement, in each property, some method to translate from common formats to the accepted one). `STATUS: todo the possiblity to have property class methods`; - no direct change of the properties is allowed. `STATUS: done`; - backward compatibility: structure.pbc and structure.kinds are still there. `STATUS: done`; - always possible to access the list of defined and of supported properties. `STATUS: done`; - support for custom properties. `STATUS: todo`; - constructors: adapt methods like `from_ase` to support also the interface with the properties stored in a given `Atoms` object. `STATUS: todo`. The new StructureData class will be a subclass of the old StructureData. This is the best way to ensure backward compatibility while avoiding code duplication. This enhance also how this new AiiDA data type is indeed and extension of the original StructureData. In the future, the entire orm.StructureData module will be moved into the `aiida-atomistic` package and the `pbc` and `kinds` attribute will be removed.
…of concepts. Also, the full orm.StructureData is copied and cleaned a bit.
next step is to define masses
*Missing: - Give custom threshold and use kind_tags as defined in structure.properties.positions.kind_tags. Questions: answered, but worth to leave it here for now: What is then the value of each property associated to each kind? an average? maybe yes. This can be then generated in another function which takes the averages. Maybe in the property specific to_kind methods. Maybe indeed the average point which is obtained during the space_grid generation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.