GSOC 2014: LTI systems & control / ODE integration
Hello all, This is not my first message to this mailing list but let me introduce myself anyway - I'm Juan Luis Cano, a 5th year student of Aeronautical Engineering at TU Madrid. I am a self-taught Python programmer, editor of the blog Pybonacci about scientific Python in Spanish language and I have contributed to SciPy in the past (see https://github.com/scipy/scipy/commits/master?author=juanlu001). I showed interest last year about the ODE integration methods in SciPy, and in fact I rewrote the odeint function in modern Fortran 90 using f2py (see #2818) but the PR is on hold due to build problems on Windows and backwards compatibility issues. There was some discussion on the mailing list about totally revamping the integrators interface but it halted. Besides, I polished some functions in the signal.lti package but I noticed some limitations while writing an article on PID control with SciPy (original in Spanish in http://pybonacci.wordpress.com/2013/11/06/teoria-de-control-en-python-con-sc...) and wanted to help building a solid framework for control theory within SciPy, polishing the LTI class, adding methods to connect several blocks and doing time response calculations and perhaps creating a graphical user interface. I would like to work on one (or both) of these topics as part of the GSOC program in case they are seen as potentially useful. Any advice on narrowing the subject and/or writing a proposal would be greatly appreciated. Regards, Juan Luis Cano Aeronautical Engineering TU Madrid, Spain
Juan Luis Cano <juanlu001@gmail.com> wrote:
I showed interest last year about the ODE integration methods in SciPy, and in fact I rewrote the odeint function in modern Fortran 90 using f2py (see #2818) but the PR is on hold due to build problems on Windows and backwards compatibility issues. There was some discussion on the mailing list about totally revamping the integrators interface but it halted.
Yes, we should replace f2c with a Fortran to C translator that understands Fortran 90 as well :) The only obstacle is we have to make it first ;-) Sturla
On 03/02/2014 03:40 PM, Sturla Molden wrote:
Juan Luis Cano <juanlu001@gmail.com> wrote:
I showed interest last year about the ODE integration methods in SciPy, and in fact I rewrote the odeint function in modern Fortran 90 using f2py (see #2818) but the PR is on hold due to build problems on Windows and backwards compatibility issues. There was some discussion on the mailing list about totally revamping the integrators interface but it halted. Yes, we should replace f2c with a Fortran to C translator that understands Fortran 90 as well :)
The only obstacle is we have to make it first ;-)
Sturla
Perhaps I didn't understand something but notice I didn't use f2c, but f2py. Which, btw, has its own sort of (big) problems and probably would need some attention too :) Juan Luis
Juan Luis Cano <juanlu001@gmail.com> wrote:
Perhaps I didn't understand something but notice I didn't use f2c, but f2py. Which, btw, has its own sort of (big) problems and probably would need some attention too :)
Right now it is possible to build SciPy without a Fortran compiler. In that case, f2c is used to translate the Fortran sources to C. If we introduce Fortran 90, we get two problems: 1. A Fortran compiler will be required to build SciPy (particularly a problem on Mac OS X). We cannot f2c Fortran 90 code. 2. Using gfortran with MSVC has stability problems on Windows (due to the crt and mingw runtime) The comments on the PR only focused on the latter. But if we solve the former problem the latter becomes invalid. Sturla
Pauli Virtanen <pav@iki.fi> wrote:
02.03.2014 18:31, Sturla Molden kirjoitti: [clip]
Right now it is possible to build SciPy without a Fortran compiler. In that case, f2c is used to translate the Fortran sources to C.
I don't think this statement is correct.
Ok. Maybe I misunderstood. (But I were under impression that this is possible.)
02.03.2014 18:43, Sturla Molden kirjoitti:
Pauli Virtanen <pav@iki.fi> wrote:
02.03.2014 18:31, Sturla Molden kirjoitti: [clip]
Right now it is possible to build SciPy without a Fortran compiler. In that case, f2c is used to translate the Fortran sources to C.
I don't think this statement is correct.
Ok. Maybe I misunderstood. (But I were under impression that this is possible.)
I think the build will just fail if no Fortran compiler is present. Currently, our binaries are built using gfortran on Linux/OSX and mingw-g77 on Windows. The problems with Fortran 90 come mainly on Windows. It's AFAIK possible to set up a toolchain today based on mingw-64 that can produce OK results with Gfortran without CRT issues, but this does seem to require some nontrivial fiddling. So at the moment, lack of out-of-the-box free toolchain for Fortran 90 on Windows is blocking inclusion of F90 code in Scipy. -- Pauli Virtanen
On Sun, Mar 2, 2014 at 4:43 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
Pauli Virtanen <pav@iki.fi> wrote:
02.03.2014 18:31, Sturla Molden kirjoitti: [clip]
Right now it is possible to build SciPy without a Fortran compiler. In that case, f2c is used to translate the Fortran sources to C.
I don't think this statement is correct.
Ok. Maybe I misunderstood. (But I were under impression that this is possible.)
You were probably thinking of numpy's use of an included f2c'ed subset of LAPACK when an external version is not present. scipy does not do this, and neither package will consciously run f2c automatically. You may happen to have something that fakes a FORTRAN compiler by using f2c internally, but scipy's build system knows nothing about it. -- Robert Kern
On Sun, Mar 2, 2014 at 2:24 PM, Juan Luis Cano <juanlu001@gmail.com> wrote:
Hello all,
This is not my first message to this mailing list but let me introduce myself anyway - I'm Juan Luis Cano, a 5th year student of Aeronautical Engineering at TU Madrid. I am a self-taught Python programmer, editor of the blog Pybonacci about scientific Python in Spanish language and I have contributed to SciPy in the past (see https://github.com/scipy/scipy/commits/master?author=juanlu001).
I showed interest last year about the ODE integration methods in SciPy, and in fact I rewrote the odeint function in modern Fortran 90 using f2py (see #2818) but the PR is on hold due to build problems on Windows and backwards compatibility issues. There was some discussion on the mailing list about totally revamping the integrators interface but it halted.
Besides, I polished some functions in the signal.lti package but I noticed some limitations while writing an article on PID control with SciPy (original in Spanish in
http://pybonacci.wordpress.com/2013/11/06/teoria-de-control-en-python-con-sc... ) and wanted to help building a solid framework for control theory within SciPy, polishing the LTI class, adding methods to connect several blocks and doing time response calculations and perhaps creating a graphical user interface.
There's enough to do here to be able to write an interesting GSoC application. An unordered list of thoughts: - Filter design has seen a significant for 0.14.0 with @endolith's work on using zpk internally, but that's mostly still hidden from the user. An API allowing ss and zpk usage instead of tf still needs to be worked out (see discussion on https://github.com/scipy/scipy/issues/2443). - MIMO systems also need work still: https://github.com/scipy/scipy/pull/2862. - There's the duplicate lsim/step/impulse functions that need fixing. - Adding more functionality for LTI systems sounds good. - Chuck has mentioned having an improved Remez algorithm lying around before, that still needs integrating. - There are lots of Kalman filters in Python floating around, including in the Cookbook, in statsmodels and in pyKalman. You'd expect to find one in scipy.signal though. - PID tuning is kind of a large topic, but if you have a clear proposal I could see it fitting in. - A GUI is definitely out of scope for Scipy. Maybe some basic plotting tools like for Bode plots using MPL could be in scope though.
I would like to work on one (or both) of these topics as part of the GSOC program in case they are seen as potentially useful.
Both are useful imho. I'd definitely focus on one topic though, two separate ones probably won't work too well in practice and your GSoC proposal will not look very coherent. Cheers, Ralf Any advice on narrowing the subject and/or writing a proposal would be
greatly appreciated.
Regards,
Juan Luis Cano Aeronautical Engineering TU Madrid, Spain _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (5)
-
Juan Luis Cano -
Pauli Virtanen -
Ralf Gommers -
Robert Kern -
Sturla Molden