NEP-PACK 1.0: A julia package for nonlinear eigenvalue problems

Package Announcements
1

We are proud to announce version 1.0 of NEP-PACK - a Julia package for nonlinear eigenvalue problems with eigenvalue nonlinearities. The package is released with an open-source license. The package makes full use of the efficiency of Julia, yet maintains usability, and integrates well with other software packages and other programming languages (including matlab and python) as illustrated in tutorials. The package is designed to be easy to use for NEP-application researchers and engineers as well as algorithm developers.

Currently, the package contains implementations of many state-of-the-art algorithms including projection methods (nonlinear Arnoldi, two variants of Jacobi-Davidson methods), contour integral methods (Beynā€™s method and block SS), Krylov methods (nleigs, infinite Arnoldi variants, CORK-pencil data tyoe, infinite Lanczos), Rayleigh functional methods (residual inverse iteration, Rayleigh functional iteration), Newton-type methods (augmented Newton, implicit determinant, Newton-QR, quasi-Newton, Broydens method).

Common features and subtasks of different algorithms are implemented by code sharing, e.g., the contour integral methods have a common way to compute the integrals, such that if a new quadrature method is implemented, it can easily be used for both contour integral methods. The separation of subtask, allows for user and application specific improvements and sometimes even parallelization, e.g., the contour integral method can parallelized without modifying the internals of the package, as illustrated in the tutorials.

The NEP-PACK data types are constructed such that NEP-problems can be defined for general problems, e.g., as a sum of products of matrices and functions, or using many common classes are supported natively by the package such as time-delay systems and polynomial eigenvalue problems (monomial and Chebyshev). An additional feature of our software design allows for transparent implementations of transformations and manipulations of NEP-objects. Nonlinear Rayleigh-Ritz projection is implemented as a transformation that results in a new NEP-object (of much smaller dimension) and essentially any of the NEP-algorithms of the package can be used to solve the projected problem. Certain types of deflation have been implemented in an algorithm independent way. One particular type of deflation, deflates eigenvalues by constructing a larger NEP, with a smaller eigenvalue set, which we implement as a procedure resulting in an instantiation of a new NEP-object, such that we can combine deflation for essentially any algorithm in the package. Chebyshev interpolation is provided in a way that it transforms a general NEP, to a NEP represented in a (scaled and shifted) Chebyshev basis, such that (again) most solvers of the package can be used and additionally Chebyshev companion linearizations.

Documentation & tutorials: Introduction Ā· NEP-PACK

Core developers: Elias Jarlebring (@jarl), Max Bennedich (@bennedich), Giampaolo Mele (@meleg) Emil Ringh, Parikshit Upadhyaya

32 Likes
2

Neat! Two questions:

  1. have you considered the MIT license instead of GPL (I will not rehash discussions about these, eg this topic),

  2. the codebase implements a lot of nonlinear solution methods that are generic and could be useful outside this package, have you considered factoring these out to their own package, or contributing to existing ones?

1 Like
3

Thanks!

  1. We wanted MIT-license. But we also wanted to include the solver nleigs. We implemented this by a line-by-line conversion of an online MATLAB code, which is licensed under GPL. I contacted the authors (Roel Vanbeeumen and Stefan GĆ¼ttel) and requested that they changed to MIT and they in principle agreed but it has not happened yet. If we switch to MIT we would also need to remove some gallery problems (since the data comes from the Berlin-Manchester benchmark collection).
  2. Can you be more precise? All the NEP-algorithms depend on the NEP structs and other data types, so a package with a specific solver would depend on this package. Separating into several packages has a maintanance disadvantage since they can get out of sync and it is more difficult to set up unit testing.
1 Like
4

Thanks for the quick response.

Now that I take a closer look at the code, I suspect that most methods that are otherwise generic (eg quasi-Newton) exploit specific properties of your problem in the hardcoded parts, so indeed it may not make sense to factor them out.

2 Likes
5

Really cool! Congratulations, this seems like a really nice and powerful package. I myself would have applications for it, but indeed, until it changes to an MIT license I cannot add a dependency to it in my (MIT-licensed) code. Please keep us updated on this!

2 Likes
6

Iā€™m not certain about the context, but facts are generally not copyrightable so itā€™s possible that these are not restricted by copyright.

7

I second that. The license one chooses is about all source files that are included when using the project. One may even license the benchmarks or tests in a different license. What matters for the dependent packages is how one licenses the code in src/

1 Like
8

The data files are matrices generated by a specific discretization of a specific PDE. The code to generate them are not a part of that GPL-package, and someone spent substantial work to generate them. Comparable situation: A GPL-package contains data files with temperature measurements. Is it okay to take them and change license?

I would at least not feel comfortable doing so.

9

Iā€™m not suggesting that you use them without attribution, but this sounds like a situation where it would be fine to include them with attribution and you can even include their original license file. However that doesnā€™t force the package to be GPL. Bundling a file that is GPL does not automatically ā€œinfectā€ an entire repositoryā€”it depends on how the GPL code is used. The technical criterion is whether it contributes to a ā€œderived workā€. From the sound of it, these data are not necessary for the package to function, which means that the package is definitely not a derived work of these data files, even if they are used during testing or for demo purposes. The fact that they are generated data files and not code also means that itā€™s questionable whether copyright even applies in the first place.

1 Like
10

Okay. Thanks. Iā€™ll look into it. At the moment, I couldnā€™t change anyway because of the nleigs solver license.

11

Factoring out the GPL-dependent data files into another package could be a solution to this.

An incidental benefit is that since data files are not expected to be updated frequently, this would require little maintenance.

12

Possibly relevant: Brendan Gavin put some non-linear eignvalue code in Julia on Github.

2 Likes
13

With no license unfortunately.

1 Like
14

Thanks for releasing the package now. Iā€™m working on a rotating Gross-Pitaevskii problem L[Ļˆ] = Ī¼Ļˆ, which has states Ļˆā‚€ with residual āˆ„L[Ļˆā‚€]-Ī¼Ļˆā‚€āˆ„Ā²/āˆ„Ī¼Ļˆā‚€āˆ„Ā² ā‰¤ 10ā»āµ. Itā€™s tempting to guess that one of them is an eigenstate, but no one has been able to get a solver to converge to it. Iā€™m keen to try out your solvers and see if they can.

1 Like
15

Note that this is a nonlinear eigenvector problem, not eigenvalue. For Gross-Pitaevskii, you can use the solvers in Optim.jl, specifying the Sphere manifold. I work on these things, so let me know how that goes!

edit: also you might be interested in https://github.com/JuliaMolSim/DFTK.jl/blob/master/examples/gross_pitaevskii.jl

4 Likes
16

Thanks Antoine. I missed that distinction.

17

Thanks for reminding of Gavinā€™s code. We have not implemented FEAST in the package, mainly because we already have two contour integral solvers in the package with similar algorithm properties. After all we already have in total approx 15 different NEP-solvers. We did spend quite some time on the FEAST fortran code (http://www.ecs.umass.edu/~polizzi/feast/download.htm) which already has quite a bit of software engineering invested. It would be cool to be able to use it as an external solver for NEPs defined in NEP-PACK. It is certainly possible to use external solvers in general. If we manage eventually, it would probably end up as a tutorial.

2 Likes
18

I am currently working on Julia bindings to the FEAST fortran code, which in particular should make calling it from NEP-PACK much easier. The latest version uses a reverse communication interface (RCI) pretty heavily, which might complicate the Julia bindings, but ARPACK.jl seems to have figured this out, so it should be possible.

Also, Brendan has now added an MIT license to the Julia FEAST code on github.

1 Like
19

The license of NEP-PACK is now changed to MIT, after the matlab implementation of the nleigs solver was also changed to MIT last week. Ping @pablosanjose.

7 Likes
20

Fantastic! Thanks @jarl

1 Like