lammps.py for Windows?

I was looking at the LAMMPS python section (http://lammps.sandia.gov/doc/Section_python.html) as well as scanning the archives.

Is the shared object problem for Windows still unsolved?

It looks like if there was a dll you could use ctypes to do the same thing as the Linux shared object, cf., http://stackoverflow.com/questions/252417/how-can-i-use-a-dll-from-python

Where do the Windows executables available at the LAMMPS site originate, and has/or is generating a dll been contemplated?

Thanks,

Fred

I was looking at the LAMMPS python section
(http://lammps.sandia.gov/doc/Section_python.html) as well as scanning the
archives.

Is the shared object problem for Windows still unsolved?

you could as well ask whether there is somebody that wants to provide
"professional" support for running LAMMPS on windows.

It looks like if there was a dll you could use ctypes to do the same thing
as the Linux shared object, cf.,
http://stackoverflow.com/questions/252417/how-can-i-use-a-dll-from-python

sure.

Where do the Windows executables available at the LAMMPS site originate, and
has/or is generating a dll been contemplated?

the old (static) binaries (up to about 2013) came from paul croziers
windows box running the cygwin compiler tool chain, the newer ones
(installer packages) from a linux (virtual) machine using the mingw64
cross compiler tool chain on my desktop.

no, building a .dll has not been contemplated. i don't recall anybody
yet asking for it. since software development on and for windows is
in many ways so different from Linux/UNIX/MacOSX, support for LAMMPS
in general is on a take-it-or-leave it basis and dependent on suitably
motivated developers with sufficient experience in writing portable
code and a preference for doing development on windows.

my motivation to come up with a way to build those windows installers
was mostly motivated by wanting to have suitable binaries for
performance LAMMPS tutorials without having first to teach people how
to compile LAMMPS or and the fact that very few computer classrooms
offer a (usable) linux environment. the hack value of learning
something new was a bonus...

axel.

i should add that i think it should be quite possible to compile a
LAMMPS .dll file for windows with the cross compiler tool chain that i
use. i have done so several times in order to provide updated molfile
plugin binaries for users of VMD that use windows and have reported
problems with VMD plugins that i support. but on windows each function
that should be visible in a shared object has to be explicitly
exported. for VMD this has been done long ago and made portable using
some (rather ugly) preprocessor magic, but for LAMMPS this would still
need to be done and thus requires somebody that actually is capable to
do this and properly test and debug on windows. i keep building
windows packages, because it is a mostly automated process and as i
mentioned, it is an extremely convenient way to learn using LAMMPS.

axel.

Axel/Paul/Andrew:

Thank you all for your comments.

Just as a preface, I asked this question because we have a need for using lammps.py natively in the Windows environment for a project. Perhaps the new python extensions that run in the native LAMMPS scripts (once they are provided in the Windows binaries) can be used instead.

The one thing I now understand is that the LAMMPS windows binaries have been originating come from either Cygwin and Mingw-w64. I

I just took a quick scan of the file Makefile.mingw64-cross. The shlib option is there. So, my remaining questions are: 1) Does this option create an .so or a .dll in this environment? And can that object, whatever it is, be used with lammps.py outside the Mingw environment or only in the Mingw environment?

Thanks again for the input!

--Fred

Axel,

Is this a custom modification of the Makefile.mingw64-cross in order to build the dll? If so, could you possibly share those details?

--Fred

Axel/Paul/Andrew:

Thank you all for your comments.

Just as a preface, I asked this question because we have a need for using lammps.py natively in the Windows environment for a project. Perhaps the new python extensions that run in the native LAMMPS scripts (once they are provided in the Windows binaries) can be used instead.

no. if you want to use any advanced features of the python module, you
need the ctypes interface of the shared object, i.e. lammps.py to
work.
there is *very* little chances that the PYTHON package in LAMMPS will
be supported on windows, because windows doesn't ship with a "natively
bundled" python environment and bundling a python distribution within
the LAMMPS windows installer is out of the question as it compiling
them with and without support for a specific external python package
or forcing people to install it, even if they don't want to use it.
maintaining python in a not natively compiled application is a big
mess, even on linux.

The one thing I now understand is that the LAMMPS windows binaries have been originating come from either Cygwin and Mingw-w64. I

there was somebody that contributed changes to compile LAMMPS with
Visual C++ and provided project files. but those had been abandoned
long ago. i think LIGGGHTS does support building with VC++ (probably
via cmake).

I just took a quick scan of the file Makefile.mingw64-cross. The shlib option is there. So, my remaining questions are: 1) Does this option create an .so or a .dll in this environment?

it is there by way of copy-and-modify, not by design.

And can that object, whatever it is, be used with lammps.py outside the Mingw environment or only in the Mingw environment?

neither. like i already mentioned, all symbols in a .dll file on
windows have to be explicitly exported with __declspec(dllexport), so
you can build a .dll file, but you cannot use it. see, e.g.:
http://www.mingw.org/wiki/sampledll

for a dynamically loaded shared object, some additional work is
needed. like i said, i know in principle from working on plugins for
VMD how this can be done, but it is a bit of a laborious process, and
it needs to be done by a person that knows what he/she is doing *and*
knows LAMMPS and what kind of changes steve is comfortable with to
include and what not.

make a proposal that would make it attractive for me to collaborate,
but at the moment, this is not a very attractive prospect. developing
and particularly debugging on windows is quite a nuisance.

axel.

Axel,

Is this a custom modification of the Makefile.mingw64-cross in order to build the dll? If so, could you possibly share those details?

i already pointed you towards http://www.mingw.org/wiki/sampledll
also we have this little gem from VMD's vmdplugin.h

/** "WIN32" is defined on both WIN32 and WIN64 platforms... */
#if (defined(WIN32))
#define WIN32_LEAN_AND_MEAN
#include <windows.h>

#if !defined(STATIC_PLUGIN)
#if defined(VMDPLUGIN_EXPORTS)
/**
* Only define DllMain for plugins, not in VMD or in statically linked plugins
* VMDPLUGIN_EXPORTS is only defined when compiling dynamically loaded plugins
*/
BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
  return TRUE;
}

#define VMDPLUGIN_API __declspec(dllexport)
#else
#define VMDPLUGIN_API __declspec(dllimport)
#endif /* VMDPLUGIN_EXPORTS */
#else /* ! STATIC_PLUGIN */
#define VMDPLUGIN_API
#endif /* ! STATIC_PLUGIN */
#else
/** If we're not compiling on Windows, then this macro is defined empty */
#define VMDPLUGIN_API
#endif

/** define plugin linkage correctly for both C and C++ based plugins */
#ifdef __cplusplus
#define VMDPLUGIN_EXTERN extern "C" VMDPLUGIN_API
#else
#define VMDPLUGIN_EXTERN extern VMDPLUGIN_API
#endif /* __cplusplus */

oh, and on top of that, you will *have* to use my LAMMPS-ICMS branch.
there are several modifications that are either not "steve compatible"
or so specific for my way of building with the cross compiler. details
are here: http://git.lammps.org/git/?p=lammps-icms.git;a=tree;f=tools/mingw-cross;hb=HEAD

that being said, if you need to build for a specific controlled
environment, things get easier and it may be less of an effort to
build a specific version for that specific purpose. but as i already
mentioned, generic support for python on windows is not something that
i will even start to look into unless i have a very compelling reason.
having to develop and test on windows is a major PITA for me, since i
have extremely little practice (i more-or-less switched from windows
to linux (with a brief detour on OS/2) more than 15 years ago).

axel.