I know how to solve 2 coupled DE analytically, but when there are 3 or higher number of coupled DE it becomes cumbersome to solve it analytically. So I am trying to solve it numerically. Any help would be appreciated.
There are many methods. I recommend to you the four order Runge-Kutta, popular in my times (30 years ago). You can use the MatLab routines like ode45 or ode15s. I attach a manual that I wrote for my students many years ago. Unfortunately, it is in Spanish, but the FORTRAN codifications of first example may be useful.
Runge-Kutta is definitely the way to go. I attached a ZIP file that contains two examples, one using 4th order and one using 6th order for two common ODEs. I also included the executable, compiled with Digital FORTRAN 6.1, which I have used for years, although I mostly work in C. I have a lot more examples in C, but this is all I have in FORTRAN that still works.
It seems we are talking about a rather simple problem (difficult to solve analytically doesn't mean it is also difficult to solve numerically.) If that is the case, a Runge-Kutta method with adaptive step size should be more than enough. There are plenty of variations about the Runge-Kutta algorithm general idea, but I would recommend the Runge-Kutta-Fehlberg method, because it is generally faster. Whatever you do, do not use a fixed step size method; such methods are just for introducing students to the topic, and should never be used in real problems.
So, the short answer is: use the Runge-Kutta-Fehlberg method, fourth-fifth scheme (often abbreviated as RKF45). In many "real-world" cases, RKF45 should be able to solve the problem in a matter of milliseconds, and with excellent accuracy. Plenty of textbooks explain that method in detail, but if you want to see how RKF45 performs in practice, [Link 1] at the end of this text might be of some help (that paper is about an implementation of RKF45 I wrote some time ago for the Maxima Computer Algebra system, but should be enough to show how the algorithm performs in several example problems.) For a very good Fortran 90 implementation of RKF45 you can use right away, see John Burkardt's code [Link 2].
For many people, a Runge-Kutta method of relative step size is the first and the last word on the topic. However, things are often more complicated than that. It is not uncommon for a problem to be difficult to solve numerially, although it looks like a rather simple system of differential equations. There are several reasons for that, but the "usual suspect" is stiffness. Stiffness is a large topic by itself, so suffice to say that stiff problems are hard to solve numerically using any implicit numerical method (this includes all Runge-Kutta variations and many others). For stability reasons, the implicit numerical method is forced to use a very small integration step after some point, and never escapes the "trap", even when it should. This results a huge amount of integration steps, long computation times, or even complete inability to solve the problem. Details about the reasons of stiffness and examples of stiff problems can be found in [Link 1]. You will see that it is surprising how a simple-looking problem turns out to be stiff.
So, for stiff problems, the method I recommended earier, RKF45, might be of some use, but it's definitely not the way to go. Several special implicit methods, designed for solving stiff differential equations, do exist, but I would recommend a more sophistiated algorithm, able to switch from non-stiff to stiff mode and vice versa. A ready-made implementation of such an algorithm can be found in ODEPACK (by Hindmarsh et al., see [Link 3].) ODEPACK is a collection of excellent ODE solvers I would recommend without hesitating. The most sophisticated solver in that package is the LSODAR solver and its double-precision version, DLSODAR, which I would recommend as my final answer. ODEPACK and all its necesary dependencies can be downloaded from Netlib (see [Link 4]).
ODEPACK is written in Fortran 77, and each solver requires many imperative input arguments. It's not hard to use, but if you prefer a simpler way to go you may find DLSODAR_F95 (a Fortran 95 module I wrote some time ago) useful. DLSODAR_F95 is basically a Fortran 95 interface for DLSODAR which sets most required parameters automatically, so it is easier to use; you can optionally set all DLSODAR parameters as well, although you will probably never need to do so. DLSODAR_F95 also contains some useful utilities. See [Link 5] for details.
If, for some reason, you prefer another ODEPACK solver, other than DLSODAR, and if you end up using that solver for a long time, you will probably want to write a module similar to DLSODAR_F95.
Link 1: https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxwanBhcGFzb3R8Z3g6MWM4YTcxYmI5NTY0YTU1Ng
Link 2: https://people.sc.fsu.edu/~jburkardt/f_src/rkf45/rkf45.f90
Link 3: https://computation.llnl.gov/casc/odepack/
Link 4: http://www.netlib.org/odepack/
Link 5: https://sites.google.com/site/pjpapasot/fortran/libraries/dlsodar_f95
Each system of ordinary differential equations can be solved with the Euler method. All you need is Excel and a small enough step. There are also variable-step methods available - eg the Merson method. Fortran is not needed, all you need is an easily accessible Turbo Basic. Regards,
First, a system of ordinary differential equations should NOT be solved with the Euler method. This is just the most primitive method, and its only use is to introduce students to the subject, exactly because it is simple. However, the error of the Euler method increases rapidly as you integrate, and the net result is a completely inadequate method for anything other than the first class lesson in the topic.
Second, "Fortran is not needed", and we must use... Excel? Or... Turbo Basic? For scientific work? I am sorry but the only sane way to interpret this is as a joke.
Well, ...................., Professionals and beginners are in this forum. The Euler method is a simple method. Its accuracy can be adjusted by the size of the step. It is very easy to implement this method in Excel. Of course, using this method and Excel, I will not solve, for example, the two-point boundary value problem in connection with the minimization/maximization of Hamilton's function. However, one can show for educational purpose the solution of Lorenz equations (three differential equations), and also show deterministic chaos in form of strange attractor.
The programming language is only a tool. It does not affect the quality of scientific work. Using the PC and Turbo Basic with the double precision option, one can make accurate calculations. I could give hundreds of examples. Of course, I will not propose to anyone PC and TB to invert the square matrix 1000x1000 or to minimize the function of 1000 variables.
In addition, the scientific idea is important, not the tools used to implement it. Regards,