Is your feature request related to a problem? Please describe.

Lots of functions are passed around in this package, some of which capture variables in a way advised against by the Julia performance tips. Those advise use of let blocks for better performance and type stability. That's probably among the many things that could be done to speed up performance of this library.

Describe the solution you’d like

Check wherever closures are made in this library, such as the NumericalNeuralLyapunovFunctions function, and bring them up to best practices, likely with let blocks.

Is your feature request related to a problem? Please describe.

Currently, NeuralLyapunov outputs a PDESystem for use in NeuralPDE. As described in SciML/NeuralPDE.jl#703, NeuralPDE generates its loss function in two steps: first parsing the PDE into a data-free loss function, then merging that with a training strategy for how data points are selected within the training domain (e.g., GridTraining or QuadratureTraining). Since NeuralLyapunov has a very constrained set of potential data-free loss functions, the parser isn't very helpful, and (as in the issue already referenced) is often inconvenient. We're mostly using NeuralPDE for the training strategies.

If NeuralPDE isn't going to add functionality for merging a training strategy with a user-defined data-free loss function, should NeuralLyapunov handle the training strategies as well?

Describe the solution you’d like

Potentially, NeuralLyapunov could take in training strategy as those in NeuralPDE, and output an OptimizationProblem, skipping over NeuralPDE entirely. This would allow more flexibility and optimization in creating the data-free loss function, but would also involve writing code similar to NeuralPDE for merging the strategy and data-free loss function into a full loss function.

Describe alternatives you’ve considered

The ideal would be if SciML/NeuralPDE.jl#703 is completed, in which case NeuralLyapunov could generate an OptimizationProblem using that part of NeuralPDE, skipping over the parser, and still benefit from any advancements in training strategies implemented by the NeuralPDE library.
Failing that, the current state of NeuralLyapunov, which uses NeuralPDE in its current state, parser and all, does work.

Additional context

Specific issues/difficulties that have come up with parser include directional derivatives being calculated inefficiently (SciML/NeuralPDE.jl#702), if ... else ... blocks not parsing well, and the dynamics needing to be traceable. (I'm not actually sure how limiting the last one is, but it doesn't seem ideal in general. It may be possible to deal with the traceability of dynamics with some fancy Symbolics work instead.)

Describe the bug 🐞

Codecov isn't generating new reports, for some reason. It hasn't for a month.