Skip to content
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 30 commits into from
Feb 8, 2024
Merged

Develop/properties #8

merged 30 commits into from
Feb 8, 2024

Conversation

mikibonacci
Copy link
Collaborator

No description provided.

Miki Bonacci and others added 30 commits September 20, 2023 11:37
…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.
@mikibonacci mikibonacci merged commit 19bf071 into main Feb 8, 2024
0 of 6 checks passed
@mikibonacci mikibonacci deleted the develop/properties branch February 8, 2024 12:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant