What you have described is quite specialized and I certainly don't have the necessary knowledge to construct a mathematical model of it.  If you have constructed a mathematical model and your difficulty is in its implementation in Maple, then post your worksheet and point out where Maple help is needed.

You will need to be more specific.  Plotting this function over 0..1000 is instantaneous:

plot(sin(t/100), t=0..1000);

@nm In Linux, Maple is launched from a script file in Maple's installation directory.  The script file processes command-line options and sets some environment variables before launching the binary executable.

I must have learned about the "–standalone" option from browsing that script file because the option does not seem to be documented anywhere.  Perhaps that's because it's specific to Linux?  I don't know.  There are some other useful undocumented options there.  The "–j" option, for instance, may be used to increase the Java heap memory allocation size which is sometimes necessary when doing extensive graphics.

I don't know about Windows, but in Linux the command-line option "–standalone" starts an independent Maple process.  There ought to be something equivalent in Windows.

I know how to solve that problem but I would rather not do your homework for you.

I will be happy to show you how to do it in Maple if you show me how you would go about solving it by hand.

@Mo_Jalal To plot u(x,1) we do:
pdsol:-plot(u, t=1);

To obtain solution values, we define U:
U := pdsol:-value(u);
Then U(0.8, 0.2) returns
            [x = 0.8, t = 0.2, u = 0.161382120212466312]
There are a lot of other ways.  Have a look at the help page on pdsolve,numerc.

As you have suspected, those initial conditions are totally wrong.  To pose a proper set of initial and boundary conditions, you need to provide more information about the problem that these equations are supposed to model.  Here I will provide one set of plausible assumptions but these may be entirely different from what you really need.

The main trick here is the introduction of the new variables u_t, u_tt, etc., which converts your original 3rd order system to a first order system.

Download mw.mw

@nm Thanks for a very clever workaround.  Your suggestion can be a good general advice for anyone working with such series solutions.

@Maple_lover1 There have been many requests for a color bar feature in Maple's 3D graphics but unfortunately there is no native support yet for color bars in Maple.  I am hoping that it will be added some day.

If you search for "color bar" in this website's search box, you will see quite a number of hits and a lot of suggestions on hacking together color bars with the currently available tools.  None of these strike me as aesthetically pleasing or easy to use. 

If you insist on color bars, then I can see a justification in your attempt to convert Maple code to Matlab.

Your program refers to PlyTable but as far as I can see, it cannot read its value.  To verify that, print the value of the CurrentAngle within your main loop, as in

for i from 1 to NumberPlies do:
    CurrentAngle := PlyTable1[i,1]:
    printf("i = %d, CurrentAngle = %a\n", i, CurrentAngle);
    ...

 By the way, why do you have a colon after "do"?  Remove it.

A general advice: There is an old saying to the effect that for any problem that you cannot solve, there is a simpler problem that you cannot solve.  Try that one first.

Your current program is too complex to debug. I suspect that you received it from someone else and are trying to modify it.  If that's the case, you will be better off by writing your own version, from the beginning and without bells and whistles.  Start simple.  Do away with widgets that can hide data.  You may make your program fancier later, after you have established a foothold and verified that the plain version works.

@acer The solution is to remove the f(x) := whatever syntax from Maple altogether.  As a help to new users, an attempt to f(x) := whatever should trigger an error message with a text like "did you mean f := x -> whatever?".

@acer Thanks for the explanation.  That's indeed an unexpected behavior (a polite way of saying a "bug").  I still don't understand why gamma(1) evaluates to −0.07281584548.  Do you know where that number comes from?

@dearcia Maple is unable to plot the arrows in your original version because the vector field is undefined on the planes x=0, y=0, and u=0.  To avoid the singularity, don't go near those planes. Adjust the plotting region like this:

 x = 0.1 .. 1, y = 0.1 .. 1, u = -1 .. -0.1

@PhD_Wallyson I don't have access to articles 1 and 3.  Send them to me and I will have a look.

@ Oh, I see, this model is a lot more complicated than I would have expected.  I wouldn't be able to devote the necessary time to go into its details.  I hope that someone else in this forum will.