LAMMPS developer workshop discussion

LAMMPS LAMMPS Mailing List Mirror
1

OK, I’ll throw my idea (now that summer break is coming in the southern hemisphere I can put work on it) then: I think that LAMMPS needs to have a good libray interface. Personally, a rewrite of the python module would be helpful for me, and I think that maybe for a couple more people. But apart from python, I think that LAMMPS behaviour as a library is pretty limited and convoluted, and could be improved.

So that’s my proposal, improve LAMMPS library interface. I will work on it on january and any help would be appreciated, even working or development priorities.

pablo

2

Pablo,

It looks like you have to be familiar with lammps to work on library interface :slight_smile: But let’s see if things change and it can actually work. I believe you have several particular things you want to implement. If you start working on them in January, don’t keep it private. Github, e.g., has some issue tracking mechanism. Let’s see how it works. I suppose that if you open an issue in lammps/lammps repository, everyone who’s “watching” it should be notified. That’s a lot. Then people might contact you and discuss the workflow if they want to join (probably fork from your fork of lammps and from time to time push their additions to your repository, that eventually will be pushed to lammps-icms).

You can also notify this mailing list when you start your project.

Best,
Oleg

6:01, 5 декабря 2014 г., Pablo Alcain <pabloalcain@…24…>:

3

Personally, a rewrite of the python module would be helpful for me,

I’m not sure what you have in mind, but the python/lammps.py file

(Python wrapper) is meant to simply wrap the C interface to
LAMMPS, provided in src/library.cpp/h.

If you want to add more functions to library.cpp (and add
the wrap function to lammps.py), then great.
If you want to add more external Python-based tools
that use python/lammps.py to access LAMMPS, then great.

But if you want to change lammps.py, then I don’t see
why that would be necessary or useful. It’s functional and complete
for anything that LAMMPS exposes thru its lib interface.

And it uses ctypes which is included in Python and is much
simpler than SWIG which Andrew raised as an idea.

Steve

4

> Personally, a rewrite of the python module would be helpful for me,

I'm not sure what you have in mind, but the python/lammps.py file
(Python wrapper) is meant to simply wrap the C interface to
LAMMPS, provided in src/library.cpp/h.

I'm sorry, I do realize that. Actually that's what I wrote previously but
it got lost
in the hyperspace and it looks like I didn't cc lammps-users, sorry for
that.

If you want to add more functions to library.cpp (and add
the wrap function to lammps.py), then great.

That's exactly what I have in mind :slight_smile:

If you want to add more external Python-based tools
that use python/lammps.py to access LAMMPS, then great.

But if you want to change lammps.py, then I don't see
why that would be necessary or useful. It's functional and complete
for anything that LAMMPS exposes thru its lib interface.

I think that the problem is the lib interface. In case it got lost, I'll
quote what I
wrote previously as an example

"""
I will give an (extremely naïve) example: lammps has, as you know, a run
method, implemented in run.cpp
<https://github.com/lammps/lammps/blob/master/src/run.cpp>. It does a whole
bunch of syntax-checking stuff and then it goes to the run itself. Then it
does the run itself, a bit more checks ,an initialization, etc. But what if
I want to do a run from any other code (say python, for example). The
problem is that I don't have the run part isolated, so I have to either
call every method or use an interface to the "run". There is currently no
interface to the run method, the only way I can run is through the
"command" method, so I have to call this in my code:

lmp.command("run 1000")

which i don't like. I can define this method [which i have done]:

def run(self, Nsteps): """ Wrapper for the "run" command in
lammps """ self.lmp.command("run {ns}".format(ns=Nsteps))

but once again, using Python as a wrapper to a scripting language written
in c++ embedded in LAMMPS sourcecode. well, doesn't /feel/ right.

Just imagine how this works when you want to compute something and extract
its value for post-processing on the fly.

I insist, bottomline it's a matter of taste, I think it is an extremely
convoluted way, but I admit it does work.
"""

And it uses ctypes which is included in Python and is much

simpler than SWIG which Andrew raised as an idea.

I agree, ctypes > SWIG

5

Re: your example of a streamlined run() function.

It’s fine if you want to add that to src/library.cpp and
then wrap it in python/lammps.py

I’d suggest a syntax like
run(int nsteps, int preflag, int postflag)

so that you have the option to avoid pre and post setup/output,
like the run command allows. With those options invoked there
is almost no overhead invoking a run externally.

I think you will find however, that if you are running for more than
a step or 2, that the overhead of doing it thru the interface to the run
command versus a new function like this, is negligible.

Also note that new lib functions need to be C syntax, not C++. So that
any language can call them.

Any function added to the lib interface also needs to be documented
clearly. If you start avoiding checks that LAMMPS does on its
script commands, you will quickly find users calling the lib in ways that
don’t work.

But other than those suggestions, I don’t care if people add many new funcs
to the lib interface. That’s what it was designed to allow.

Steve