technologicat / pydgq Goto Github PK

Python 2.7 will be out of support January 1, 2020.

Dropping support for it allows a simple solution for #1.

A possibly incomplete list of things to remember:

• Update metadata in setup.py.
• Update GitHub tags.
• Update hashbangs.
• Drop runtests2.sh.
• Consider migrating runtests3.sh into a runtests.py. Shell? Where we're going, we need no shell.
  • Unpythonic has a template for this.
  • Or could just use unittest from the stdlib.
  • pytest would be even nicer, but introduces a dependency.

When pydgq is installed under Python 3.6, both data files pydgq_data_27.bin (old, for Python 2.7) and pydgq_data_34.bin (compatible with 3.4 and later, tested also in 3.6) get installed under their own names, but the symlink (that should point to the correct version) fails to install.

Solution: drop Python 2.7 support in the next release, so we need only one universal data file for Python 3.x.

Workaround: meanwhile, go to your site-packages/pydgq in a terminal, and install the symlink manually. Assuming pydgq was installed with pip3 install pydgq --user under Python 3.6, the full path is ~/.local/lib/python3.6/site-packages/pydgq. Once there, ln -s pydgq_data_34.bin pydgq_data.bin. Or if using Windows, just copy the file.

Currently, pydgq only supports Picard (fixed-point) iteration in all implicit solvers (including the Galerkin solvers). This is the simplest thing that works, but the convergence rate is linear (constant number of added correct bits per iteration).

Newton-Raphson would be a useful option to have for improving performance, because it converges quadratically (number of correct bits doubled per iteration).

• To make it easy to use, approximate the Jacobian with finite differences, to avoid the need for the user to provide a function for the Jacobian to be able to use Newton iteration.
• Allow the user to optionally provide such a function, if they prefer.
• The Right Thing for producing a Jacobian automatically is (forward-mode) automatic differentiation, but in a low-level language such as Cython this is not easy (if at all possible) to make conform to the same interface as standard double-precision floats.
• Maybe optionally also allow a mixed scheme which starts by a user-configurable number of Picard iterations, then switches to Newton. This can sometimes help convergence (if the final value from the previous timestep is outside the basin of attraction of the Newton method; Picard is not that sensitive to the initial value).

The contact email in setup.py is outdated. PyPI uses it to provide the link to email the maintainer. Update it for the next release.

Currently, pydgq considers an iteration complete once all bits of the double-precision 64-bit float agree.

While this is useful for very sensitive equations (e.g. those in undamped vibration problems), for other real-world use a convergence tolerance setting would be useful.

• Maybe options for absolute and relative.
• Maybe default to 1e-6.
• Let the user specify 0 to use the old behavior.