Woohoo... Created an engine today. Seems that it is not so difficult to use our framework at all...

I ran a 1000 steps trajectory of a simple LJ Fluid for testing. Still some subtleties to figure out, but we might interest a lot of people once lammps is supported. Not sure how to really test this since I have so clue on how to properly use lammps... Means we might need someone that has used lammps before.

Alright, this failed because we need to install lammps, which I think need some time to figure out how to install in travis. On my machine it passes though...

Alright, this failed because we need to install lammps, which I think need some time to figure out how to install in travis.

Is there a reason not to use the pre-built Ubuntu package? I mean, it would be nice to get away from using sudo and onto Travis's newer architectures, but we're already using sudo to get conda, right?

I don't think so. I did not look for this. installation on OS X was a little tricky due to me updating to El Capitain and my mix of homebrew and macports installations.

does not seem to work. The installable binary does not include python wrappers...

:-( Oh well, it was an idea worth trying. There may be a way to get the python wrappers separately?

This is milestoned for "future" anyway, but I would have been happier to see fewer red Xs in the list of PRs. That was my main reason for hoping this would be a quick and easy fix!

The idea was great and installing was extremely easy. Three lines in install.sh and it installed pretty fast.
There is just no python package available. It could be that you can do this separately, but I do not know how to do that.

This is ready to be reviewed although it can take a while. All it does is create an engine that takes a Lammps script and extracts Snapshot objects. It contains a simple test notebook. Note that so far we cannot have automatic traivs testing since the binary of lammps does not contain Python support!

The code looks fine, but it is currently kind of ghost code: it isn't actually imported in the __init__.

I don't want to merge this until we have working tests for it. With working tests, we can count on Travis to warn us of any problems due to changes in LAMMPS before they start causing problems for our users.

Also, I think this is a good place to figure out how to deal with "optional" external packages. My suggestion: In __init__.py

try:
    import lammps
except ImportError:
    pass # maybe raise a quiet warning about LAMMPS not available?
else:
    from lammps_engine import LammpsEngine

Yes, it is not meant to be merged. I just wanted you to have a look. We definitely need to make this work with travis, but potetially not in the main branch since building lamps could take a while.

Okay -- I'll remove my assignment for now. My comment above says what I had to say, and there's nothing more for me to do right now.

It looks like the Ubuntu package might not even have the shared lib included. We may have to roll our own library-based installer -- at that point, it would probably be worth looking to making it conda installable. But that also makes it a much lower priority.

There were some issues on merge. Apparently it took parts of the old openmm engine. I probably need to fix this some other way... But not now...