I promised to keep my mouth shot after my last email but couldn’t resist using this example. Stephan below quotes his for $ lib to be an improvement over ReaxFF because of his enhanced charge equilibration scheme.
I'll just make one post. I have been following this discussion,
and finally succumbed to elaborate my personal experience. Short
version: Ideology, aside, professors and students are often unlikely
to want to pay for software licenses or other large service fees
up-front.
(Although it really depends on the field. Strangely, EM labs seem
happy to fork out $5k or $10k for a software license.)
Here's the long version:
I was a physics graduate student, and theory students in a typicaly
physics department can take 3 or more years in limbo to find an
adviser that will even take them in, let alone pay them. Furthermore,
sometimes a project starts up as a collaboration, the outcome of which
determines whether the professor agrees to take on the student.
(During this time I ran my simulations on some office computers
between midnight and 6AM.) Once you get professor to take you on, in
can be hard go ask for resources. I have met several graduate
students doing computational physics/chemistry work who's professors
refused to buy them, or provide access to a computer. (Any computer.
Even a basic single-core linux PC desktop.) Either way, when making a
$11000-$15000 annual stipend as a graduate student, you don't want to
buy your own hardware, and a MedeA license would be regarded as
extravagant. I wish that were not the case.
I think it supports Axel's assertion that graduate student labor is
incredibly cheap and expendable. The process creates an army of
resource-deprived, attention-deprived, poorly-paid (and sometimes
poorly-trained) student labor where paying a reasonable fee for advice
or software is prohibitive.
I should also add that another source of reluctance to purchase a
software license is that they are encouraged to get some fundamental
unix computer clue, and programming skills under their belt (in the
likely event they don't end up as professors). You don't want to
produce a PhD that is incredibly specialized in using one particular
kind of software (with a fancy GUI, ...even if it's really nice
software).
Does the endless supply of fresh new student faces generate a
stream of new ideas? I really think so, yes. Is it inexpensive
source of labor? Yes. Is the quality of grad-student code appalling?
Truly, yes. Is it optimal: No. Is this sustainable?
Unfortunately, it will probably continue as long as grad school still
sounds alluring.
I enjoy writing little programs. And science problems can be
incredibly interesting and fun to work on. I have some rather modest
contributions ("moltemplate", "minrms", etc...), and I can think of
many cool features that people have asked for which I don't have time
to implement. It does not advance my career at all, and (if I'm not
careful) will reduce my chances of being able to feed myself later.
(That said, I will keep moltemplate updated and add new features when
I can.)
Last I checked, there are almost no public government science
grants in the USA (from NSF, NIH) which directly support any kind
software development. (Which is very odd, since there are numerous
grants for hardware/protocol development.) It does not have to be
(directly) government-funded. So perhaps a LAMMPS foundation, or some
other kind of more general (private) crowd-sourced effort might fill
this big hole.
Axel wrote:
oh, and i forgot one issue with "closed source add-ons": bugfixes.
for example, several of the add-ons that paul's company contributed to
LAMMPS had problems and inconsistencies that were primarily found and
resolved by the LAMMPS community developers and that was only possible
because the source was available. nothing serious, but rather subtle
and thus most regular users would not have noticed.
Of course, I have no idea about this incident. I initially thought
this was a criticism, but after reading it again, it sounds like a
compliment. If Paul opened up the source code to MedeA-LAMMPS enough
that a 3rd party was able to spot a bug (I assume that's what
happened), then great.
I am strongly biased towards open-source software. But if you run
all-atom simulations, and if you use a popular force-field, (such as
OPLSAA for example), I suspect that you are less likely to encounter a
bug with in your force-field parameters if you use MedeA than if you
use moltemplate. (For what that's worth...) I haven't used MedeA,
but I'm admit that programs like the MedeA molecule-builder are a
better fit for most users, compared to programs like "moltemplate",
which I originally only wrote to fill a specific niche (coarse-grained
simulations).
This mailing list a wonderful forum, by the way. I've really
enjoyed being on the periphery.
Andrew
Stephan - a follow-up Q. We have talked about keeping LAMMPS GPL
but also licensing it selectively to interested folks as LGPL.
Would LGPL make a difference for how/if your company distributes your
LAMMPS-compatible library?
Steve
On a first look i’d say that LGPL would solve the problems for us. But i have to check that with my boss on monday. Than i can give you a definitive answer.
Stephan
First impression I’d say it would solve our problems. I’ll have to talk to my boss on monday and can give you definitive answer then.
Stephan
First impression I’d say it would solve our problems. I’ll have to talk to
my boss on monday and can give you definitive answer then.
please note that there also is the option to have a "loader" or "wrapper"
included in LAMMPS that then at a later point will load the actual compiled
code.
this is, for example, what is done with the OpenKIM project that uses a GPL
incompatible (open source) license. also the interface to the Molfile
plugin library for reading and writing trajectory files with VMD plugins
falls into a very similar category.
i've been lobbying in the past that LAMMPS makes this easier and offers a
plugin system for extensions. that was initially considered to complex and
too much changed to the core code, but since then factories for creating
instances of optional classes had to be introduced to work around compiler
limitations and from there it is not that large of a step to a functional
plugin system. at least for simple cases.
axel.
Hi Axel,
While you can certainly do that, it is not clear that it avoids the restrictions in the GPL. For example, there are those who claim that using GPL Python libraries applies the GPL to the entire project. The only way to absolutely know is via a court case setting a precedent. You suggestion might be a reasonable approach, but if your livelihood depends on being correct, even a small chance that you are wrong — or even the thought of a lawsuit — makes it difficult if not impossible to use that route. Uncertainty is a major problem.
Hello,
over the weekend i spend a little time to research GPL vs LGPL. For a company, like Paul Saxe wrote poses various risks. Personally i like using GPL software, but as a company various risks have to be taken into account. What we would need is a „legally save“ way of linking our ReaxFF lib against lammps. LGPL seems to be one way to solve the legal worries/concerns. A sort of plugin system for lamps like Axel mentioned would also certainly be very interesting.
If somebody is attending the GdCH Wissenschaftsforum in Dresden or the EURO-CC in Fulda it would be interesting to meet up and exchange ideas. I am also interested in suggestion how ReaxFF could be improved or what features would be interesting.
Stephan