Glue code

[matt-chan]

A preliminary implementation of the glue code for HORTON 3.

You can ignore the test_snippet.py for the review.

Just want to get some feedback before going too much further when filling in details. The skeleton is mostly there though. There's some examples at the bottom to show what the user would write.

A few design decisions which I'd like comments on in particular:

• I'm using decorators to help with caching and also to protect against accidentally using the object before final instantiation.
• Almost all the details about "smart defaults" are yet to be written, but the idea is to have the local defaults (ones which don't require information from outside the class) implemented within the class and the global defaults (ones which require information from outside the class) are implemented in the SmartCompute class. This keeps the options classes fairly decoupled.
• I'm using a ton of multiple inheritance. I hope this is okay.

[tovrstra]

I'll take a look soon.

[tovrstra]

getattr will raise an exception if the attribute is not present and when no default argument is provided. Would be better to have one getattr call also. E.g. like

val = getattr(self, varname, None)
if val is None:
    val = func(self, *args, **kwargs)
    setattr(self, varname, val)
return val

[tovrstra]

@matt-chan Could you add docstrings to the decorator functions and the classes Options and DelayedInit? (The rest would need docstrings too at some point but that is for later.) I'm asking for just these docstrings because they would facilitate the reviewing.

[tovrstra]

Unit tests with example usage and expecte behavior would also facilitate the review. It does not have to be complete coverage etc. Just some examples that show the aim of the decorators would make it easier to understand and comment.

[matt-chan]

@tovrstra good ideas! How does it look now?

[tovrstra]

@matt-chan Sorry for the slow reaction from my side. I looked at it once again and I start to get the idea now. I'll have to let this percolate once more. I would like to figure out if the same result (as shown in the example) can be obtained with a simpler code structure.

Would the following description be right? The idea is to define a program as a dependency graph: if a result is requested, it's inputs must be looked up (either mandatory inputs or optional ones with sensible defaults) and then the results can be computed. This may go a few layers deep where inputs of inputs are needed to compute intermediate results.

[matt-chan]

@tovrstra it's okay!

Yes, that's essentially the gist of it. The additional criteria I'd say is that the nodes in the dependency graph should be distinct (nodes aren't composed of other nodes). It seems to keep things simpler I think. It forces us to write a class to pass parameters (or select default ones for passing) between the nodes though.

The newest push contains most of the code necessary for a HF/DFT program I think. We're missing the meanfield and grid modules though.

[tovrstra]

Thanks! Looks good already, so fine by me to merge. I just need some unperturbed thinking time to come up with useful suggestions. At the moment, that is really hard, so it may take a little while. Sorry...

[matt-chan]

@FarnazH @tczorro @PaulWAyers

Can you guys take a look at this PR and also the code in the repo and let me know what you think? Is it a reasonable API for HORTON 3's porcelain?

I think this might be a better way of doing settling on API instead of meeting and talking. At least we can play with code this way and let things mull.

[PaulWAyers]

I'll let others actually look at the code for cleanness and structure. The porcelain should meet a very high standard of code as it is the thing that is most likely to be
(a) used by others.
(b) modified by non-experts
(c) used by intermediate-skilled users as templates for their own work.

We should also include David and Kumru probably in this.

Matt, I think all of my thoughts are in the specification we worked out ~9 months ago (in terms of input requirements, optional arguments, procedures for determining charge/multiplicity/geometry/etc. from "easy" input, etc.. As long as you hit those requirements and the code is pristine, I think things will be OK.