2D line and 3D scatter plots support in info bar

[cbenmahm]

Fix #78

For now, it is possible to visualize 1D properties as line plots (e.g. DOS plots or SOAP vectors) and 3D scatter plots in the table cells in the info bar for structures and environments. The data should be provided as [[x], [y], [z]] for every environment/structure. The z-axis is optional.

The current visualization setup is not optimal because the info bar covers entirely the structure viewer for smaller screens. I am hesitant to use bootstrap modals and have a floating window or create an extra column in the chemiscope viewer between the map and the structure viewer.

Checks for input data are not implemented (yet).

[Luthaf]

Thanks a lot for creating the PR! I think the first thing we should discuss is how we want to store multi-dimensional properties in the datasets.

The current approach (using a separate PropertiesND field) works fine for DOS, and more generally whenever one wants properties where multiple values are associated with a single structure/atom.

However there is another use case that could use the same code foundation: properties where each structure/atom is associated with a single scalar value; but parametrized by some parameter: for example a KPCovR map would be parametrized by the alpha parameter, or a PCA with values parametrized by max_radial. While we don't have to implement this "parametrized properties" use case right away, we will want to make sure the dataset interface remains stable when we want (so that JSON files created with an older version of chemiscope can still be loaded).

There was a proposed Dataset interface in the initial message of #78 that could support both DOS style multi-dimensional properties and parametrized properties, did you consider using it?

---

Using the "parametrized" interface, a dataset containing both multi-dimensional properties and parametrized properties would look like this:

dataset = {
    properties: {
        // already implemented
        "energy": {
            target: 'structure',
            values: [1.0, 2.0, 3.0],
            unit: "",
            description: "",
        },
        "KPCovR[1]": {
            // n_structures arrays each containing len(parameters["kpcovr-alpha"])
            // values
            values: [
                [0.3, 0.4, 0.5, 0.6],
                [0.2, 0.1, 0.2, 0.1],
                [0.7, 0.8, 0.9, 1.2],
            ],
            parameter: ["kpcovr-alpha"],
            /* unit & description */
        },
        "DOS": {
            // n_structures arrays each containing len(parameters["dos-energy"])
            // values
            values: [
                [0.3, 0.4, 0.5, 0.6],
                [0.2, 0.1, 0.2, 0.1],
                [0.7, 0.8, 0.9, 1.2],
            ],
            parameter: ["dos-energy"],
            /* unit & description */
        }
    },
    parameters: {
        "kpcovr-alpha": {
            values: [0.0, 0.5, 0.8],
            /* unit & description */
        },
        "dos-energy": {
            values: [-12, -11, -10, -9],
            /* unit & description */
        },
    }
}

---

Maybe the use cases for multi-dimensional and parametrized properties are different enough that we would want to use different code path & data storage for them; but I think it is worth to try to unify both features if possible.

[ceriottm]

If we start fiddling with the format, it might be good to standardize a bit, and to have a "version" field to make sure that the viewer is aware of, and compatible with, the standard.

On Wed, 16 Jun 2021 at 15:05, Guillaume Fraux @.***> wrote:

Thanks a lot for creating the PR! I think the first thing we should discuss is how we want to store multi-dimensional properties in the datasets.

The current approach (using a separate PropertiesND field) works fine for DOS, and more generally whenever one wants properties where multiple values are associated with a single structure/atom.

However there is another use case that could use the same code foundation: properties where each structure/atom is associated with a single scalar value; but parametrized by some parameter: for example a KPCovR map would be parametrized by the alpha parameter, or a PCA with values parametrized by max_radial. While we don't have to implement this "parametrized properties" use case right away, we will want to make sure the dataset interface remains stable when we want (so that JSON files created with an older version of chemiscope can still be loaded).

There was a proposed Dataset interface in the initial message of #78 https://github.com/cosmo-epfl/chemiscope/issues/78 that could support both DOS style multi-dimensional properties and parametrized properties, did you consider using it?

Using the "parametrized" interface, a dataset containing both multi-dimensional properties and parametrized properties would look like this:

dataset = { properties: { // already implemented "energy": { target: 'structure', values: [1.0, 2.0, 3.0], unit: "", description: "", }, "KPCovR[1]": { // n_structures arrays each containing len(parameters["kpcovr-alpha"]) // values values: [ [0.3, 0.4, 0.5, 0.6], [0.2, 0.1, 0.2, 0.1], [0.7, 0.8, 0.9, 1.2], ], parameter: ["kpcovr-alpha"], /* unit & description / }, "DOS": { // n_structures arrays each containing len(parameters["dos-energy"]) // values values: [ [0.3, 0.4, 0.5, 0.6], [0.2, 0.1, 0.2, 0.1], [0.7, 0.8, 0.9, 1.2], ], parameter: ["dos-energy"], / unit & description / } }, parameters: { "kpcovr-alpha": { values: [0.0, 0.5, 0.8], / unit & description / }, "dos-energy": { values: [-12, -11, -10, -9], / unit & description */ }, }}

---

Maybe the use cases for multi-dimensional and parametrized properties are different enough that we would want to use different code path & data storage for them; but I think it is worth to try to unify both features if possible.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cosmo-epfl/chemiscope/pull/150#issuecomment-862362770, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIREZ3VNSL56QSGMADB5LLTTCORFANCNFSM46Y3G65Q .

[Luthaf]

Could you rebase this branch on top of master, now that most of the sweeping changes are done?

[cbenmahm]

I didn't know that force-pushing a branch would result in closing this issue

[cbenmahm]

thanks @Luthaf. I implemented you suggestions, now it is time to break it :)

[cbenmahm]

it's no longer a draft!