This question is regarding a potential parser for LOBSTER: http://schmeling.ac.rwth-aachen.de/cohp

LOBSTER is a package that calculates crystal orbital hamilton populations. So it is not a DFT package, but rather a program which calculates some extra property on top of other DFT calculations: VASP, abinit, and qespresso.

We would like to have it for our oasis (as we have a lot of such calculations around), but preferably would like to get it upstream later so I want to check early if this would be an option and what would be needed.

The question is how to actually structure the parser. So as far as I can see there are already some other parsers (like phonopy and elastic) which work on top of other DFT calculations so it might be acceptable for upstream? But they might be slightly different in the sense that they generate the input (displacements, etc.) for DFT calculations and than parse it later, LOBSTER more or less just reads the wave function, structure and calculates some properties.

I wanted to check if I have thought about this correctly how to populate all the metadata sections:

- system: Lobster itself doesnâ€™t have this info (in its specific output and input files), but it technically need the structure from the underlying DFT calculation as an input so it should be in the same directory for it to work. The question is if we implement the reading on our own (it should not be that hard as all the DFT packages supported by lobster are supported by ase as well) or if we somehow call the corresponding DFT parser and get it from there?
- single_configuration_calculation: here would reside all the outputs under x_lobster_* program specific keys/sections, and also section_calculation_to_calculation_refs should link to the underlying DFT calculation, right?
- method: also lobster specific stuff
- workflow: here I have no idea? probably no workflow at all?

So in general we donâ€™t touch the general metadata scheme at all, just populate what we can (the system section) and all the rest will go into the x_lobster_* code specific

If this is acceptable for upstream, the question is how we should proceed? Should we just make it work a bit, lets say when it can parse the system, some method details and few properties, than upstream as soon as possible and work on it there, or would it be preferable to develop separately and only upstream when the parser is more complete?