Question 1)
If I create a fix that includes code from Eigen, will it be considered for inclusion with LAMMPS? Eigen is a popular linear algebra library which uses the MPL2 license, and it is a big library (I think it’s over 100000 lines of code). To be clear, I am not proposing to include the entire Eigen library with LAMMPS. I only need about 200 lines of code from one of their files.
the USER-SMD package already uses code from Eigen (Eigen3, to be exact), however we do not bundle the corresponding code, but you have to install Eigen. When using CMake to configure/build LAMMPS, the presence of Eigen is detected and if not, it will try to download a copy and use that. Since Eigen is a template library, this is portable and simple.
Hi Axel.
Thank you for your thoughtful, thorough, and sweeping answer to my question.
Incidentally, the fix in question is “fix bond/react” which is currently in USER-MISC. (I am adding new functionality to this fix.) I will say that I prefer your approach, and I think it’s cool you figured out a way to automate installing Eigen using CMAKE.
My concern is that following your advice would prevent end-users from being able to use fix bond/react (or any of the other fixes in USER-MISC), unless they figure out how to use CMAKE. In an ideal world, they would take the time to learn this useful skill. In the real world, they might not. I am reluctant to introduce new code which adds the first external dependency to USER-MISC (or fix bond/react). It would be different if other fixes in USER-MISC also require Eigen.
For now, I will try to adapt the code in “KSPACE/pppm_disp.cpp” (specifically the “qr_alg()” function) to suit my needs. (After some half-assed googling, I convinced myself that this code does not appear to be an exact copy of anybody else’s work.)
i would strongly recommend against copying code from Eigen, as that would “decouple” the code from the Eigen distribution and - for example - no bugfixes or other improvements would be applied.
The biggest problem we had in figuring out in making (most of) LAMMPS compatible with LGPL was to identify pieces of code that people had liberally (and sometimes in violation of the license) copied into LAMMPS without giving attribution or any other way of identifying it easily.
I can only imagine…
— details —
The MPL2 license (that Eigen uses) is less restrictive than the LGPL. Even so, I am guessing that if I use any Eigen code in my LAMMPS fix, I would be forced to include the MPL2 license somewhere in my source files which contains their code. So I would put the contents of their MPL2 license in one big comment at the end of one of my source files. (Would that be okay?)
see above. we would want to avoid that.
Agreed. Don’t worry. I won’t do this.
Andrew
P.S.
— alternative —
I am aware that one of the existing LAMMPS files (“pppm_disp.cpp”) includes some code for calculating eigenvalues. I would need to modify that code heavily, so I prefer to use the Eigen code instead. I can do that if I have to. On that note, it occurs to me that many different fixes might eventually need to calculate eigenvalues and eigenvectors. So perhaps it makes sense to have a file in the “src/” directory that calculates eigenvectors and eigenvalues that different fixes can refer to (“pppm_disp.cpp” is in the KSPACE directory).
The alternative to using Eigen would be to use BLAS/LAPACK, which is the traditional library for linear algebra operations (e.g. USER-ATC, USER-AWPMD). in that case you can link to either an installed (and vendor optimized) BLAS/LAPACK library (like MKL, OpenBLAS) or compile and link to the subset in the lib/linalg/ folder, which contains the subset required for compiling and linking with just the BLAS/LAPACK functions used by different packages in LAMMPS.
having custom code or copies (e.g. from numerical recipes, which is problematic if copied literally from the numerical recipes provide files) for preforming such tasks is not such a good idea for maintenance reasons. there are a few files with library functions in LAMMPS for simple matrix/vector/math operations already available. the problem with these is usually that they require a specific layout of the data (same for BLAS/LAPACK), which is often considered too much of an inconvenience.
there is not a clean and consistent situation in LAMMPS for historical reasons. the code has grown over many, many years and in parts people didn’t pay too much attention to all those details affecting licensing and maintainability. now that we have changed things in that respect and do automatic integration and regression testing, the requirements for overall code quality and consistency are higher. so we are somewhat stuck between having bad examples already in the distributions, but at the same time are applying higher standards to new contributions (at least most of the time and to the best of our abilities).
HTH,
Axel.
Thank you very much.
I’m glad I asked before proceeding.
Andrew