So, I have made a rough layout of the main function that will be used to
solve ODEs with the methods like
neq_nth_order_linear_constant_coeff_homogeneous/nonhomogeneous,
neq_nth_linear_symmetric_coeff_homogeneous/nonhomogeneous, special case
non-linear solvers, etc.
Some notations used:
eqs: Equations, funcs: dependent variables, t: independent variable,
wcc: weakly connected component, scc: strongly connected component
Introduction to helper functions that will be used(these are temporary
names, parameters and return elements and may be changed if required):
1. match_ode:-
Parameters: eqs, funcs, t
Returns: dictionary which has important keys like: order(a dict
that has func as a key and maximum order found as value), is_linear,
is_constant, is_homogeneous, eqs, funcs.
2. component_division:-
Paramters: eqs, funcs
Returns: A 3D list where the eqs are first divided into its wccs
and then into its sccs.
This function is suggested to be implemented later. So, until all
the other solvers are not ready(tested and working), this function will
just take eqs and return [[eqs]].
3. get_coeff_matrix:-
Parameters: eqs, funcs
Returns: coefficient matrix A(t) and f(t)
This function takes in a first order linear ODE and returns matrix
A(t) and f(t) from X' = A(t) * X + f(t).
4. nth_order_to_first_order:-
Parameters: eqs, order
Returns: first order ODE with new introduced dependent variables.
And all the first order linear solvers mentioned above.
Now, besides the main function, there are two separate functions depending
on whether the system of ODEs is linear or not, namely _linear_ode_sol and
_non_linear_ode_sol.
1. _first_order_linear_ode_sol:-
Parameters: match dict(obtained earlier and maybe modified in
ode_sol)
Returns: Dict with keys as func and value as its solution that
solves the ODE.
Working: First, extracts A(t) and f(t) using get_coeff_matrix, then
using match dict, identify which solver is required and solve the ODE if it
is possible to do so. For example: Case where A(t) is not symmetric isn't
solved.
2. _non_linear_ode_sol has similar Parameters and Returns but the function
operates differently that's why it is essential to use a different
function. But I don't have a clear understanding
of how to design _non_linear_ode_sol yet but here is what I have came up
with: First match the condition where it is possible seperate out the
independent variable to get a relationship
between the dependent variables and then finally, just use the special
solver to solve the ODE.
Now, coming to the main function ode_sol(for now, I haven't considered
initial values):-
Parameters: eqs, funcs, t
Returns: Solution in a dict form where func is the key and value is the
solution for that corresponding func.
Working:
The steps of its working-
1. Preprocess the equations.
2. Get the match dict using match_ode function.
3. Convert nth order equations to first order equations using
nth_order_to_first_order while storing the funcs seperately so that we can
later filter out the dependent variables that were introduced in this step.
4. Get the 3D list of equations using component_division function.
5. Iterate through the wccs and solve and store solutions seperately
but for sccs, first solve the first set of equations in a scc, then
substitute the solutions found in the first set of the current scc to the
second
set of current scc. Keep doing this until the all the sets for a
particular scc is solved.
6. For solving a component, choose either _linear_ode_sol or
_non_linear_ode_sol depending upon the set of equations to be solved.
7. Return a dict by taking out values from the solution obtained
using all the dependent variables in funcs as there may be more variables
introduced when we made the system into first order.
For now, this is what I have came up with. Obviously the order in which we
will proceed is, build the basic layout of the main function and
component_division will just increase the number of dimensions to 3
rudimentarily as we
will have to first ensure that the general solvers work well since working
on both of them simultaneously will make it tough to pinpoint the errors.
Along with that, non-linear solvers can be implemented later, we can just
raise a
NotImplementedError for now till we have completed both the general linear
solvers and the component_division and then add the special case solvers.
On Tuesday, March 17, 2020 at 3:02:29 AM UTC+5:30, Oscar wrote:
>
> There are possibilities to go from nonlinear to linear e.g.:
>
> In [6]: x, y = symbols('x, y', cls=Function)
>
> In [7]: eqs = [x(t).diff(t)**2 - y(t)**2, y(t).diff(t)**2 - x(t)**2]
>
> In [8]: eqs
> Out[8]:
> ⎡ 2 2⎤
> ⎢ 2 ⎛d ⎞ 2 ⎛d ⎞ ⎥
> ⎢- y (t) + ⎜──(x(t))⎟ , - x (t) + ⎜──(y(t))⎟ ⎥
> ⎣ ⎝dt ⎠ ⎝dt ⎠ ⎦
>
> In [9]: solve(eqs, [x(t).diff(t), y(t).diff(t)], dict=True)
> Out[9]:
> ⎡⎧d d ⎫ ⎧d d ⎫
> ⎧d d ⎫ ⎧d d ⎫⎤
> ⎢⎨──(x(t)): -y(t), ──(y(t)): -x(t)⎬, ⎨──(x(t)): -y(t), ──(y(t)):
> x(t)⎬, ⎨──(x(t)): y(t), ──(y(t)): -x(t)⎬, ⎨──(x(t)): y(t), ──(y(t)):
> x(t)⎬⎥
> ⎣⎩dt dt ⎭ ⎩dt dt ⎭
> ⎩dt dt ⎭ ⎩dt dt ⎭⎦
>
> On Mon, 16 Mar 2020 at 15:48, Milan Jolly <milan....@gmail.com
> <javascript:>> wrote:
> >
> > Thanks for the suggestion, I have started with the design for these
> solvers. But I have one doubt, namely since now we are using
> linear_eq_to_matrix function to check if the system of ODEs is linear or
> not, would we require the canonical rearrangements part? Or rather are
> there other cases when we can reduce non-linear ODEs into linear ODEs.
> >
> > On Monday, March 16, 2020 at 2:53:57 AM UTC+5:30, Oscar wrote:
> >>
> >> That seems reasonable to me. Since the plan is a total rewrite I think
> >> that it would be good to put some time in at the beginning for
> >> designing how all of these pieces would fit together. For example even
> >> if the connected components part comes at the end it would be good to
> >> think about how that code would fit in from the beginning and to
> >> clearly document it both in issues and in the code.
> >>
> >> Getting a good design is actually more important than implementing all
> >> of the pieces. If the groundwork is done then other contributors in
> >> future can easily implement the remaining features one by one. Right
> >> now it is not easy to improve the code for systems because of the way
> >> that it is structured.
> >>
> >> On Sun, 15 Mar 2020 at 19:27, Milan Jolly <milan....@gmail.com> wrote:
> >> >
> >> > Thanks for your reply. I have planned a rough layout for the phases.
> I took a lot of time this past month to understand all the mathematics that
> will be involved and have grasped some part of it.
> >> >
> >> > If I am lucky and get selected for GSOC'20 for this organisation,
> then the below is the rough plan. Please comment on suggestions if
> necessary.
> >> >
> >> > Community Bonding phase:
> >> > 1. Using matrix exponential to solve first order linear constant
> coefficient homogeneous systems(n equations).
> >> > 2. Adding new test cases and/or updating old ones.
> >> > 3. Removing and closing related issues if they are solved by the
> addition of this general solver. Identifying and removing the special cases
> solvers which are covered by this general solver.
> >> >
> >> > Phase I:
> >> > 1. Adding technique to solve first order constant coefficient
> non-homogeneous systems(n equations).
> >> > 2. Adding the functionality that reduces higher order linear ODEs to
> first order linear ODEs(if not done already, and if done, then
> incorporating it to solve higher order ODEs).
> >> > 3. Adding a special case solver when non-constant linear first order
> ODE has symmetric coefficient matrix.
> >> >
> >> > Phase II:
> >> > 1. Adding technique to solve non-constant non-homogeneous linear ODE
> based off the solver added by the end of Phase I.
> >> > 2. Evaluating and eliminating unnecessary solvers.
> >> > 3. Closing related issues solved by the general solvers and
> identifying and removing unwanted solvers.
> >> > 4. Adding basic rearrangements to simplify the system of ODEs.
> >> >
> >> > Phase III:
> >> > 1. Dividing the ODEs by evaluating which sub-systems are weakly and
> strongly connected and handling both of these cases accordingly.
> >> > 2. Adding a special case solver where the independent variable can be
> eliminated and thus solving the system becomes easier.
> >> > 3. Wrapping things up: adding test cases, eliminating unwanted
> solvers and updating documentation.
> >> >
> >> > This is the rough layout and my plan for summer if I get selected. If
> this plan seems ok then I would include this plan in my proposal.
> >> >
> >> > On Saturday, March 14, 2020 at 9:37:31 PM UTC+5:30, Oscar wrote:
> >> >>
> >> >> It's hard to say how much time each of these would take. The roadmap
> >> >> aims to completely replace all of the existing code for systems of
> >> >> ODEs. How much of that you think you would be able to do is up to
> you
> >> >> if making a proposal.
> >> >>
> >> >> None of the other things described in the roadmap is implemented
> >> >> anywhere as far as I know. Following the roadmap it should be
> possible
> >> >> to close all of these issues I think:
> >> >>
> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3Asolvers.dsolve.system
>
> >> >>
> >> >> On Fri, 13 Mar 2020 at 22:30, Milan Jolly <milan....@gmail.com>
> wrote:
> >> >> >
> >> >> > I have mostly read and understood matrix exponentials and Jordan
> forms along with the ODE systems roadmap. But I am unclear as to what has
> already been done when it comes to implementing the general solvers. For
> example: The matrix exponentials part has already been implemented and now
> I have a PR that has revived the matrix exponential code.
> >> >> >
> >> >> > I want to make a proposal and contribute to make these general
> solvers during this summer if my proposal gets accepted. But I am unclear
> what should be the parts I need to work during community bonding period,
> phase 1, phase 2 and phase 3 as I am unaware how much time each part of the
> general solvers would take.
> >> >> >
> >> >> > If someone can help me in this regard(helping me with these 2
> questions) then it would be great.
> >> >> >
> >> >> >
> >> >> > On Tue, Feb 25, 2020, 5:09 AM Milan Jolly <milan....@gmail.com>
> wrote:
> >> >> >>
> >> >> >> I will go through the roadmap. Also, I will work on reviving and
> finishing the stalled PRs namely the matrix exponential one for now as I am
> interested in working towards this. Thanks.
> >> >> >>
> >> >> >> On Mon, Feb 24, 2020, 9:56 PM Oscar Benjamin <
> oscar.j...@gmail.com> wrote:
> >> >> >>>
> >> >> >>> This section in the roadmap refers to existing stalled PRs
> trying to
> >> >> >>> fix the n-equations solver for constant coefficient homogeneous
> ODEs
> >> >> >>> which is the first step:
> >> >> >>>
> https://github.com/sympy/sympy/wiki/ODE-Systems-roadmap#constant-coefficients---current-status
>
> >> >> >>>
> >> >> >>> A first step would be to attempt to revive one or both of those
> PRs
> >> >> >>> and finish them off.
> >> >> >>>
> >> >> >>> On Mon, 24 Feb 2020 at 05:59, Milan Jolly <milan....@gmail.com>
> wrote:
> >> >> >>> >
> >> >> >>> > So, I am interested in rewriting parts of the current ODE as
> discussed in the roadmap. Is there any work started in that direction and
> if not then can I create a PR for the same?
> >> >> >>> >
> >> >> >>> > On Mon, Feb 24, 2020, 2:52 AM Oscar Benjamin <
> oscar.j...@gmail.com> wrote:
> >> >> >>> >>
> >> >> >>> >> The current refactoring effort applies only to the case of
> solving
> >> >> >>> >> *single* ODEs. The ODE systems code also needs to be
> refactored but
> >> >> >>> >> (in my opinion) needs a complete rewrite. That is what the
> roadmap is
> >> >> >>> >> about (it describes how to rewrite everything). The code for
> systems
> >> >> >>> >> of ODEs should also get refactored in the process but there
> is no need
> >> >> >>> >> to "refactor" it in its current form if it is in fact being
> >> >> >>> >> *completely* rewritten: we can just make sure that the new
> code is
> >> >> >>> >> written the way we want it to be.
> >> >> >>> >>
> >> >> >>> >> On Sun, 23 Feb 2020 at 19:52, Milan Jolly <
> milan....@gmail.com> wrote:
> >> >> >>> >> >
> >> >> >>> >> > Ok so I have gone through the links suggested and I have
> realised that as far as ODE module is concerned, refactoring is the most
> important task. But, as far as that is concerned, I think Mohit Balwani is
> working on this for a while and I want to limit any collisions with my
> co-contributors. So, I have couple of ideas to work on:
> >> >> >>> >> > 1. Helping to extend the solvers, i.e.implementing a fully
> working n-equations solver for constant coefficient homogeneous systems.
> This is from the ODE systems map. I am interested in working on this but I
> understand that it might be hard to work upon it while refactoring takes
> place. Still, if its possible to work on this and if no one else has
> started to work in this direction yet then I am willing to work for this.
> >> >> >>> >> > 2. Using connected components function implemented by Oscar
> Benjamin in https://github.com/sympy/sympy/pull/16225 to enhance ODE
> solvers and computing eigen values faster as mentioned here
> https://github.com/sympy/sympy/issues/16207 .
> >> >> >>> >> > 3. This idea is not mentioned in the ideas page and is
> something of my own. If there is anything possible, then I can also work on
> extending functions like maximum, minimum, argmax, argmin, etc in calculus
> module. I have been working on the issue
> https://github.com/sympy/sympy/pull/18550 and I think there is some scope
> to extend these functionalities.
> >> >> >>> >> >
> >> >> >>> >> > On Sunday, February 23, 2020 at 1:32:20 AM UTC+5:30, Milan
> Jolly wrote:
> >> >> >>> >> >>
> >> >> >>> >> >> Hello everyone,
> >> >> >>> >> >>
> >> >> >>> >> >> My name is Milan Jolly and I am an undergraduate student
> at Indian Institute of Technology, Patna. For the past 2 month, I have been
> learning and exploring sympy through either contributions, reading
> documentation or trying examples out. This last month I have learned a lot
> of new things thanks to the well designed code-base, the structured way
> this community works and most importantly the maintainers who make it work.
> It has been a pleasure to be a part of the community.
> >> >> >>> >> >>
> >> >> >>> >> >> I am interested in participating for GSoC this year and I
> would like to work for this org during the summers if I am lucky. I
> particularly want to work on improving the current ODE module as it is
> given in the idea list. There is a lot of work that needs to be taken care
> of like:
> >> >> >>> >> >> 1. Implementing solvers for solving constant coefficient
> non-homogeneous systems
> >> >> >>> >> >> 2. Solving mixed order ODEs
> >> >> >>> >> >> 3. Adding rearrangements to solve the system
> >> >> >>> >> >>
> >> >> >>> >> >> These are not my ideas but I have taken inspiration from
> the ideas page but I am up for working on these. If someone can guide me
> regarding this then it would be really helpful.
> >> >> >>> >> >
> >> >> >>> >> > --
> >> >> >>> >> > You received this message because you are subscribed to the
> Google Groups "sympy" group.
> >> >> >>> >> > To unsubscribe from this group and stop receiving emails
> from it, send an email to sy...@googlegroups.com.
> >> >> >>> >> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/1033f581-abbb-4be5-a5b2-1988f4261535%40googlegroups.com.
>
>
> >> >> >>> >>
> >> >> >>> >> --
> >> >> >>> >> You received this message because you are subscribed to the
> Google Groups "sympy" group.
> >> >> >>> >> To unsubscribe from this group and stop receiving emails from
> it, send an email to sy...@googlegroups.com.
> >> >> >>> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHVvXxTeWturK6WmtHKxakLqbV1yhp5_KoTPs8vPtmbu8%3D2VxQ%40mail.gmail.com.
>
>
> >> >> >>> >
> >> >> >>> > --
> >> >> >>> > You received this message because you are subscribed to the
> Google Groups "sympy" group.
> >> >> >>> > To unsubscribe from this group and stop receiving emails from
> it, send an email to sy...@googlegroups.com.
> >> >> >>> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAMrWc1BZKcwjFvVQwZZ80P6s-CP62Tn_VN30zBEdjmqhrN44DA%40mail.gmail.com.
>
>
> >> >> >>>
> >> >> >>> --
> >> >> >>> You received this message because you are subscribed to the
> Google Groups "sympy" group.
> >> >> >>> To unsubscribe from this group and stop receiving emails from
> it, send an email to sy...@googlegroups.com.
> >> >> >>> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHVvXxRGFJC%2BGeowaNJcVFQsQsGq%2Bh0SW-jmYezsSzU5%3DvipcA%40mail.gmail.com.
>
>
> >> >> >
> >> >> > --
> >> >> > You received this message because you are subscribed to the Google
> Groups "sympy" group.
> >> >> > To unsubscribe from this group and stop receiving emails from it,
> send an email to sy...@googlegroups.com.
> >> >> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAMrWc1CYmTAwU4mFX%3DkOdZnmkzosN14VUAQBdteUETXas58n1w%40mail.gmail.com.
>
>
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> Groups "sympy" group.
> >> > To unsubscribe from this group and stop receiving emails from it,
> send an email to sy...@googlegroups.com.
> >> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/b2d61327-da27-4baf-a753-cf4069abfc78%40googlegroups.com.
>
>
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sympy" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sy...@googlegroups.com <javascript:>.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/38ad9558-b8e0-465a-aeb4-5ea782144b55%40googlegroups.com.
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/debf5cf4-2817-43ab-b4ad-64c60bf94c1e%40googlegroups.com.
