initial property parse

[amandadumi]

Starting to add other property parsers. These aren't thoroughly tested so will mark this WIP for a bit.

[amandadumi]

okay cleaned this up a bit. I am currently just spot checking this with the following script:

from cclib import ccDriver
a=ccDriver('dvb_sp.out')
a.process_combinator()
print(a.__dict__)
print(a.cccollection._parsed_data[0].scfenergies)
assert(a.cccollection._parsed_data[0].scfenergies==-382.308266602)
assert(a.cccollection._parsed_data[0].nmo==60)
assert(a.cccollection._parsed_data[0].charge==0)
assert(a.cccollection._parsed_data[0].nbasis==60)
assert(len(a.cccollection._parsed_data[0].atommasses)==20)
assert(a.cccollection._parsed_data[0].atommasses[0]==12.0)
assert(a.cccollection._parsed_data[0].atommasses[5]==1.007825)
assert(a.cccollection._parsed_data[0].atommasses[18]==12.0)
assert(a.cccollection._parsed_data[0].atommasses[19]==1.007825)
assert(a.cccollection._parsed_data[0].atomcoords[0][0] == [0.269445, 1.410118,0.000000])```

[shivupa]

OK this is awesome. I will review and merge today probably then rebase the tree stuff

[amandadumi]

sounds good. i am working on a few more but thought those could be in a separate PR.

Also i just full copied the utils files from parser directory, we may be able to prune it.

[shivupa]

Dependency resolution is a WIP but looks fine right now.

For us to remember in the future, offline discussions led to us basically having parsers with dependencies where the order that the subparsers are called is resolved by making some sort of dependency tree and making sure things are called in the right order. It's not clear to me how to handle if only some programs have dependencies (e.g. property A in gaussian requires B and C but property A in Orca requires B and D)?

[berquist]

This is too much to go over in a code review but this reminds me of https://craftinginterpreters.com/representing-code.html#the-expression-problem: is it better for us to have properties as classes/programs as methods, or programs as classes/properties as methods? This implements the former, since the latter has been a mess, and I think doing anything fancier (visitor) is not user-facing.

My one concern here is that this method is public. Will it be able to be made private so a user never has to specialize their code for their specific program? (Visibility is a breaking API change.)

[berquist]

This is the "same" in every parser. The atombasis.known_codes can be abstracted if it's made a classmethod, then it becomes cls.known_codes, getattr(cls, program), etc., which just leaves the return type. Shouldn't the return type eventually be https://docs.python.org/3/library/typing.html#typing.Self?

[amandadumi]

i do agree in abstracting this would be good. I am a bit unclear on the last sentence on how to use getattr with it and what the return type is?

I have to read a bit more about the use of typing.Self, but you're probably right. I can open an issue about it if its an eventual change if you are okay letting it through without this at the moment.

[shivupa]

Since this is approved I am going to merge. I opened a meta issue and linked the conversation there to decide exactly how to proceed with some of the minor changes