SOF-6892: include new hubbard parameters property

[pranabdas]

No description provided.

[timurbazhirov]

Can we return to reusable atomic_properties per orbital instead of adding "category"?

# Reusable: atomic_properties_per_orbital
{
    "name": "ANY",
    "values":
    [
        {
            "id": 1,
            "atomicOrbital": {
                // reusing the content of "atomicOrbital" here, maybe not all of it
                "orbitalName": "3S",
                "orbitalIndex": 1,
                "principalNumber": 3,
                "angularMomentum": 0,
                "occupation": 2
            },
            "value": 6.3
        },
        {
            "id": 1,
            "orbitalName": "3S",
            "value": 3.3
        },
        {
            "id": 2,
            "orbitalName": "3P",
            "value": 6.3
        }
    ]
}

Then hubbard_u is a specific implementation of an atomic_properties_per_orbital, so is hubbard_v and hubbard_j?

[pranabdas]

We need to decide. Few things to note:

1. We have only orbitalName in common. Not sure if it is worth reusing atomicOrbital
2. It is a per site property (same species on different sites can have different U values). In case of V, it is no longer per site rather inter-site property (V Co-3d O-2p 1 2 0.2), so we are going to have somewhat different schema.
3. Property names are used in application-flavors/executables/ to specify the results. We do not have different flavors for hp.x, so how do we specify when to use hubbard_u and when hubbard_v result? I created category for this (keeping the same name), which can be populated by the parser depending on the content of hp.x output.

[timurbazhirov]

Should we extract hubbard_u and hubbard_v separately as two different properties? Do we ever need to store both together?

And what about J?

[timurbazhirov]

hubbard_u, hubbard_v and hubbard_v_nn (add description full name - nearest neighbors)

[pranabdas]

For reference, currently hp.x does not support calculating Hubbard parameters based on DFT+U+J.

[timurbazhirov]

We need to indicate the required and optional parameters - all but distance should be required

[pranabdas]

Leaving orbitalName(s) as non-required as hp.x supports only main orbitals in DFT+U+V calculations, so orbital names can be omitted.

[timurbazhirov]

We should probably create atomic_data_per_orbital_number and atomic_data_per_orbital_string if needed, and then use them here - otherwise, it looks weird to be adding value of type number here directly

[timurbazhirov]

Same as above