Integrate LOBSTER apps into crystal toolkit

[JaGeo]

This is the PR to integrate LOBSTER into the Crystal Toolkit.

See below for a detailed explanation of the PR by @naik-aakash !

[naik-aakash]

StructureMoleculeComponent update

• @JaGeo added option to use LobsterNeighbors in structure visualization

CohpAndDosComponent Features

• Get relevant bonds interactive cohp plots alongside dos from Lobstery by means of LobsterPy and existing dos plotter in crystaltoolkit
• Include Bonding analysis summary and calculation quality texts
• Include visualization of LobsterEnv identified environments
• Hovering over atoms shows Mulliken charges and edges show the ICOHP values in the visualizer

Example rendered app

Todos (Will be worked on once app layout is finalized))

• Exception handling needs to be implemented
• Add tests

Open questions and things to improve

• App loading is currently slow as we pass in completecohp objects (this is quite large) as due to inherent nature of how ploty/dash handles callbacks, lot of time is spent in serialization and deserialization of this object

• Vasprun.xml file seems to have issues with serialization via plotly so, I think, simple fix would be to just make a small change in pymatgen - Have included temporary workaround for it in the example script here.

• Icohpcollection object also has serialization issues and currently a fix is a WIP via this Add custom as_dict/from_dict method for proper initialization of attributes of IcohpCollection pymatgen#4391

• With the current changes LobsterNeighbors can also be used to visualize structure on the Main MP website. Is this desirable ? We think could be nice addition to already exisitng options.
  

• Need to agree on what would be best place to visualize LocalEnv identified from LobsterNeighbors, maybe in crystaltoolkit app ? (i.e move this part in localenv.py module ) or could be better to have all LOBSTER related information in one page as in current app layout?

• What one can query over from MP website using mpid ? If we intend to provide complete taskdoc then we can then add option as in the app.

[esoteric-ephemera]

@naik-aakash @JaGeo for this to be used on MP's site, we'll need any of the required outputs to be in the LobsterTaskDocument. The client will retrieve a LobsterTaskDocument and then use any fields, like CalcQualitySummary rather than rerunning Analysis.get_lobster_calc_quality_summary

(The client shouldn't depend on lobsterpy / need to call lobsterpy). Also to be clear, crystal toolkit shouldn't depend on emmet, but should use data that is available in the task document

The method you implemented is OK to keep as a from_files / from_directory method, but we'd also need something that operates on data after lobster is run

Can you double check that any data that is required for the app to work is included in the task document model? Any updates to the schema should be made against this branch in emmet (PR link)

[naik-aakash]

Hi @esoteric-ephemera, thanks for the suggestion. I will look at the pinned emmet PR and raise a PR if I find anything is missing.

I will also try to make the changes in the client in the PR soon.

[esoteric-ephemera]

For this class, I would recommend against copying all of Vasprun.final_energy:

class CustomVasprun(Vasprun):

    @property
    def final_energy(self):
        return float(super().final_energy)

[naik-aakash]

Hi @esoteric-ephemera , have one question. So, now the plan is that LobsterPy is already run as part of taskdoc generation, and we simply use the outputs from the taskdoc and render the app?

I did it this way because, in our initial discussions, it was emphasized that Postprocessing should not be part of Taskdoc, but rather that this app should handle it.

Curious about how the workflow pipeline would be now.

Once I start with this, I can better comment on the emmet PR.

[esoteric-ephemera]

Any "heavy" post-processing, or post-processing which requires raw output files like vasprun.xml, should happen in the build process for your data. In the current pipeline, the lobster build would be LobsterTaskDocument.from_directory

Ex: all derived MP data is built from TaskDoc objects, and not the raw VASP output - any necessary fields for apps/subsequent builds has to be in TaskDoc. The tasks collection is built from the TaskDoc.from_directory method currently

Light post-processing can occur in the app (e.g., the oxygen evolution graph drawing in the client) , but this should be

Let me know if that makes sense!