Command Line tool for the smirky sampler

[bannanc]

I suggested to @cbayly13 today that it would be useful to be able to run the smirky sampler from the command line with files as input the same way we have been using smarty. He agrees it would make testing the probabilities of moves easier and would get us a more polished intermediate tool for sampling chemical environments.

@davidlmobley and @jchodera What is the best/preferred way to set this up? It's input is similar, but not identical to smarty. Should it be a completely separate tool or a new option when running smarty `smarty --sampler smirky? With the latter I'm concerned about how complicated the command line options are going to become with all the different input options.

[jchodera]

Can you point to where the sampler code is and where the driver code for it is right now?

[jchodera]

Also, what input options do you want to expose, and how would you like to specify them?

If there are a lot of options, we could use YAML files which are human readable and trivially importable as a Python dict of ducts.

[jchodera]

Dict of dicts/lists, that is.

[bannanc]

The sampler code is here: https://github.com/open-forcefield-group/smarty/blob/master/smarty/sampler.py
but is still being updated from move proposal @cbayly13 wrote separately.

I don't have the driver code yet, I thought I would bring up the issue first. Generally, I was imagining input files could be in a similar form to the smarty atomtype files (such as this), but with SMARTS and probabilities instead of type names.
So a decorator file would have a form such as:

X1    0.25
X2    0.25
X3    0.25
X4    0.25

I was aiming for consistency with the smarty tool, but trying to determine if it should be an option when calling smarty or a separate tool completely.

[bannanc]

The sampler code is here: https://github.com/open-forcefield-group/smarty/blob/master/smarty/sampler.py
but is still being updated.

I should say that the input is changing to incorporate odds/probabilities so nothing currently online is really up to date quite yet

[davidlmobley]

@bannanc - I think it ought to be a separate tool, as I agree with you that otherwise it will make SMARTY's command-line interface too complicated (as well as the fact that the input files will have totally different formats depending on whether we're dealing with smarty or smirky). Plus, @camizanette is also working on additional changes to smarty's interface anyway (to allow for it to focus on a particular element) so trying to bolt optional support for that, together with optional support for smirky, sounds like a recipe for something way too complex.

I'd make it a separate tool called smirky, honestly. :)

Also, regarding decorator files -- I have a bit of a preference, honestly, for how Chris framed things in terms of odds. Particularly, your format:

X1    0.25
X2    0.25
X3    0.25
X4    0.25

could be written as

X1    1
X2    1
X3    1
X4    1

These would then get converted to probabilities internally, of course. The advantages of odds, as I see it, are:

1. It allows extending the files to cover new possibilities or remove possibilities without re-calculating the probabilities
2. It's somewhat easier to see what ratios of two probabilities are if the denominator is, say, 1. :)

Not major issues, but possibly worth going that direction... Your call though.

[jchodera]

I'd take @davidlmobley's suggestion and write a new command-line interface driver for smirky, just to make it quicker to make progress for now.

If I were to do this, I'd

• Create a smarty/cli/smirky.py Python file for the command-line driver, following smarty/cli.py---which would eventually be migrated to smarty/cli/smarty.py.
• Add a new "entry point" to this line of setup.py to call your driver from a command-line script wrapper called smarty
• In your driver, you would call your sampler code to do what you want

I like the idea of having user-specified decorator weights that are used in sampling.

I think the most important thing is to aggressively refactor the sampler code into independent and simple modules with well-defined APIs so we can try various different simple implementations of them to see which strategies are most efficient. We discussed this a bit in issues like #110

[bannanc]

@davidlmobley it looks like we all agree so I will keep it as a separate tool

commenting on this:

Also, regarding decorator files -- I have a bit of a preference, honestly, for how Chris framed things in terms of odds.

yes, I was just commenting on the file format so I may have said probabilities when I meant odds or probabilities. I treat all the input into the smirky sampler assuming odds are given and they are immediately converted to weights/probabilities when the Sampler is initialized. I will make sure the documentation is clear.

@jchodera
I have a much more modular version of the sampler that I'm currently debugging. I'll commit it on to the environment branch as soon as it's working and passing tests.

I am aiming to have a pull request with the command line tool and examples up tonight or early tomorrow.

[bannanc]

Added in pull request #130

Create a smarty/cli/smirky.py Python file for the command-line driver, following smarty/cli.py---which would eventually be migrated to smarty/cli/smarty.py.

I had some issues with the entry_points working when the command-line drivers were in a buried directory for some reason. It ended up being easier to just make two files in smarty/ smarty/cli_smarty.py and smarty/cli.smirky.py. I will reorganize as needed, but may need some help identifying the problem with the subdirectory.

[bannanc]

Closed with pull request #130