JuDFTteam / aiida-fleur

AiiDA plugin of the high-performance density functional theory code FLEUR (www.judft.de) for high-throughput electronic structure calculations.
https://aiida-fleur.readthedocs.io
Other
14 stars 7 forks source link

fleur output node in case of relaxation #101

Open broeder-j opened 3 years ago

broeder-j commented 3 years ago

Currently we parse the relaxation results like this: relax_brav_vectors relax_atom_positions force_x_type1 abspos_x_type1

example:

{
    "abspos_x_type1": 0.0,
    "abspos_x_type2": 2.677278,
    "abspos_y_type1": 0.0,
    "abspos_y_type2": 2.677278,
    "abspos_z_type1": 0.0,
    "abspos_z_type2": 2.677278,
    "bandgap": 0.0006269675,
    "bandgap_units": "eV",
    "charge_den_xc_den_integral": -112.2549410828,
    "creator_name": "fleur 31",
    "creator_target_architecture": "GEN",
    "creator_target_structure": " ",
    "density_convergence_units": null,
    "end_date": {
        "date": "2020/12/04",
        "time": "13:30:06"
    },
    "energy": -69267.226594049,
    "energy_core_electrons": -1442.4767961443,
    "energy_hartree": -2545.5236263188,
    "energy_hartree_units": "Htr",
    "energy_units": "eV",
    "energy_valence_electrons": -24.2135380091,
    "fermi_energy": 0.4398852929,
    "fermi_energy_units": "Htr",
    "film": "False",
    "force_largest": 0.0,
    "force_units": "Htr/bohr",
    "force_x_type1": 0.0,
    "force_x_type2": 0.0,
    "force_y_type1": 0.0,
    "force_y_type2": 0.0,
    "force_z_type1": 0.0,
    "force_z_type2": 0.0,
    "kmax": 3.2,
    "magnetic_moment_units": "muBohr",
    "magnetic_moments": [
        -2.9565296423,
        2.5912813299
    ],
    "magnetic_spin_down_charges": [
        8.7349634355,
        6.1354957246
    ],
    "magnetic_spin_up_charges": [
        5.7784337932,
        8.7267770545
    ],
    "number_of_atom_types": 2,
    "number_of_atoms": 2,
    "number_of_iterations": 1,
    "number_of_iterations_total": 1,
    "number_of_kpoints": 10,
    "number_of_species": 1,
    "number_of_spin_components": 2,
    "number_of_symmetries": 48,
    "orbital_magnetic_moment_units": "muBohr",
    "orbital_magnetic_moments": [],
    "orbital_magnetic_spin_down_charges": [],
    "orbital_magnetic_spin_up_charges": [],
    "output_file_version": "0.27",
    "parser_info": "AiiDA Fleur Parser v0.3.1",
    "parser_warnings": [
        "Can not get attributename: \"units\" from node \"[]\", because node is not an element of etree."
    ],
    "relax_atom_positions": [
        [
            "Fe",
            0.0,
            0.0,
            0.0
        ],
        [
            "Fe",
            0.5,
            0.5,
            0.5
        ]
    ],
    "relax_brav_vectors": [
        [
            5.354555983,
            0.0,
            0.0
        ],
        [
            0.0,
            5.354555983,
            0.0
        ],
        [
            0.0,
            0.0,
            5.354555983
        ]
    ],
    "spin_dependent_charge_intersitial": [
        1.292882,
        1.331448
    ],
    "spin_dependent_charge_mt": [
        24.5052109,
        24.8704592
    ],
    "spin_dependent_charge_total": [
        25.7980928,
        26.2019072
    ],
    "start_date": {
        "date": "2020/12/04",
        "time": "13:30:04"
    },
    "sum_of_eigenvalues": -1466.6903341534,
    "title": "A Fleur input generator calculation with aiida",
    "total_charge": 52.0000000078,
    "total_magnetic_moment_cell": 0.4038144,
    "unparsed": [],
    "walltime": 2,
    "walltime_units": "seconds",
    "warnings": {
        "debug": {},
        "error": {},
        "info": {},
        "warning": {}
    }
}

Problems with this:

  1. The kind/species information is not preserved
  2. We have the whole structure information in the output, maybe the parser should output the forces in an array and output a StructureData node instead. (in the long run the relax workchain should output trajectory data, and for this it needs a force array and a structure at every point)
  3. this may grow very large with the cell size.
broeder-j commented 3 years ago

@Tseplyaev For know I will do a minor rewrite: I will delete the atom information from "relax_atom_positions" and will add an additional key with

"relax_atomtype_info": [[species_name1, element1], 
                                     [species_name2, element2]]

which will have length of natom type. Such a thing will be also usefull for the 'relax_parameters output' node Does this affect other workchains besides the relax workchain? Beyond this one could output abspos and force as lists with the same order as relax_atomtype_info.

The core-level workflows parse generate a whole bunch of info for the atom types but I think we want need this.

broeder-j commented 3 years ago

write routines for

extract_structure_inp_xml
extract_structure_out_xml
Tseplyaev commented 3 years ago

@broeder-j I think none of my workchains explicitly use the parsed relaxation parameters. They only use the StructureData output of the relaxation workchain.