Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Lepton vs Matheval #244

Closed
GiovanniBussi opened this issue Jun 8, 2017 · 20 comments
Closed

Lepton vs Matheval #244

GiovanniBussi opened this issue Jun 8, 2017 · 20 comments
Assignees
@GiovanniBussi

Comments

@GiovanniBussi
Copy link
Member

Hi @plumed/all

I was thinking whether we could replace matheval (or use it side by side) with lepton.

I cc also @peastman, who is the author of lepton and might have some comment (hi Peter!)

Here a few differences:

Matheval Lepton
License GPL BSD-like
Language C C++
Maintained No Looks so (it is part of other projects, see below)
Installable Yes (autoconf) No
Dependencies yes (guile + flex) Apparently none
Could be embedded in plumed Looks difficult Looks easy (see below)
Easy to customize No Looks easy (adding new functions is documented)

The most important difference is that whereas libmatheval is installable as a library (e.g. with apt-get install libmatheval or port install libmatheval) there is no apparent way to install lepton. In addition we should consider that there appear not to be an official lepton repository. The one here looks a bit outdated, and lepton is included directly at least in a couple of other repositories (openmm and opensim-core) with slight local modifications.

However, since it looks like lepton has no dependencies, we could think about including it in plumed directly (as done in the two examples mentioned above) provided that: (a) license allows it (I think so) and (b) @peastman agrees and thinks it is a good idea. If this is possible, the good thing is that users will have matheval-like features in plumed without the need of installing an extra library. In addition, lepton seems way easier than matheval to customize.

In particular, lepton could be included in a src/lepton module similarly to molfile module that we included from VMD. In this manner it would have a dedicated licence file. It could be imported with a script that applies some of the formatting required to be included in PLUMED, e.g.:

  • plumed-compatible guards in header files
  • headers should go in a single directory src/lepton together with source, and include commands should be changed accordingly
  • namespace will be nested inside namespace PLMD. This would avoid clashes if we link plumed against other software also including a possibly incompatible version of lepton (e.g. openmm).
  • source code will be astyled as the rest of the code.

Using a script to import the library would allow to keep it easily in sync with upstream changes. Since the three versions above are slightly different, we should choose which is the best one to start from.

If this procedure is acceptable, and if performances are similar to matheval (to be checked) we might even drop out matheval completely. Otherwise, we can keep them side by side, perhaps choosing which library to use from some env var or in the input file (something like FUNC=@lepton{sin(x)}).

Feedbacks are welcome!

Giovanni
@peastman
Copy link

peastman commented Jun 8, 2017

The actively developed version of Lepton is the one in the OpenMM repository. Every now and then I package up the latest code and post it as a new release, but the OpenMM repository is where all development happens, so that's where you'll always find the latest code.

It would be easy enough to build a library for it that could be installed separately. I've just never done that, because I've never had a need to. For my purposes, compiling it directly into another program was more convenient.

Lepton doesn't have any required dependencies, but it can optionally use asmjit (also included in the libraries folder of the OpenMM repository) to do JIT compilation of CompiledExpressions. That helps performance a lot. It also uses a BSD style license, so redistribution isn't a problem.

@GiovanniBussi GiovanniBussi self-assigned this Jun 19, 2017
GiovanniBussi added a commit that referenced this issue Jun 19, 2017
@GiovanniBussi
changelog
b6f1de4 
[makedoc]

Closes #244
@GiovanniBussi
Copy link
Member Author

@plumed/all I have a draft implementation for this in branch v2.4-lepton.
The way it works is the following:

  • At runtime, if env var PLUMED_USE_LEPTON is undefined, same as before.
  • At runtime, if env var PLUMED_USE_LEPTON is defined (e.g. by export PLUMED_USE_LEPTON=yes), lepton is used as a replacement for matheval

In the second case one can use MATHEVAL (function and switching function) also when libmatheval was not linked.

Input syntax is unchanged. I made a quick check with switching function MATHEVAL and it looks like lepton is even faster than matheval. However, I would prefer to add more tests before making it the default. In addition, it might be useful to add the missing functions and constants to make them totally compatible. For instance, I had to add explicitly pi=3.14159265358979 to allow lepton to reproduce a matheval regtest where pi was used. We could go through matheval documentation to be sure we include all of them.

@maxbonomi
Copy link
Member

maxbonomi commented Jun 19, 2017 via email

@GiovanniBussi
Copy link
Member Author

@gtribello was suggesting to keep the name MATHEVAL to allow people not changing their input files.

@maxbonomi
Copy link
Member

maxbonomi commented Jun 19, 2017 via email

@carlocamilloni
Copy link
Member

carlocamilloni commented Jun 19, 2017 via email

@GiovanniBussi
Copy link
Member Author

That's true. I can do

PLUMED_REGISTER_ACTION(Matheval,"MATHEVAL")
PLUMED_REGISTER_ACTION(Matheval,"ANYFUNC")

Then replace MATHEVAL with ANYFUNC anywhere in the code and just leave a short MATHEVAL manual that points to ANYFUNC manual.

For the switching function is even easier, it is just matter of changing an if statement.

Obviously ANYFUNC is not the correct name... which name should we use?

@maxbonomi
Copy link
Member

maxbonomi commented Jun 19, 2017 via email

@carlocamilloni
Copy link
Member

carlocamilloni commented Jun 19, 2017 via email

@maxbonomi
Copy link
Member

maxbonomi commented Jun 19, 2017 via email

@carlocamilloni
Copy link
Member

carlocamilloni commented Jun 19, 2017 via email

@carlocamilloni
Copy link
Member

carlocamilloni commented Jun 19, 2017 via email

@maxbonomi
Copy link
Member

maxbonomi commented Jun 19, 2017 via email

@carlocamilloni
Copy link
Member

carlocamilloni commented Jun 19, 2017 via email

@maxbonomi
Copy link
Member

maxbonomi commented Jun 19, 2017 via email

@carlocamilloni
Copy link
Member

carlocamilloni commented Jun 19, 2017 via email

@GiovanniBussi
Copy link
Member Author

I think COMBINE is mostly useful because it has sensible defaults. I often do

COMBINE ARG=*.bias PERIODIC=NO

@maxbonomi
Copy link
Member

maxbonomi commented Jun 19, 2017 via email

This was referenced Jun 20, 2017
Closed
Open
@GiovanniBussi
Copy link
Member Author

The implementation using env var was merged in v2.4 branch as of 7c5b104.

Instructions:

  • lepton is always compiled
  • lepton is enabled as a replacement of libmatheval only if PLUMED_USE_LEPTON env var is defined. In perspective (v2.5) we could eliminate libmatheval.
  • lepton is also used to interpret constant inputs (see Simple algebra in input values #250)

I let this issue open since the renaming/aliasing is still to be done (we were thinking about using CUSTOM as an alias to MATHEVAL). In addition, the possibility of using formulas in input constants should be documented.

@GiovanniBussi
Copy link
Member Author

Still to do: add CUSTOM as an alternative name for MATHEVAL

@GiovanniBussi GiovanniBussi reopened this Aug 26, 2017
GiovanniBussi added a commit that referenced this issue Sep 6, 2017
@GiovanniBussi
Removed libmatheval
3c6645d 
I removed matheval everywhere in the code. Now, MATHEVAL
(and CUSTOM) keywords are automatically using lepton (see #244).

Notice that env var PLUMED_USE_LEPTON is now ignored.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@GiovanniBussi GiovanniBussi

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@maxbonomi @GiovanniBussi @peastman @carlocamilloni