13015 Reputation

12 years, 296 days

MaplePrimes Activity

These are replies submitted by tomleslie

@Tamour_Zubair

With N=5 and t=0..3, your dependent varaibles have numerical values in the range +/-10^27.

With N=6 and t=0..3, your dependent varaibles have numerical values in the range +/-10^45

With N=7 and t=0..3, you dependent varaibles have numerical values in the range +/-10^63

So every time you increase the number of equations in your system, the numerical range of the dependend variables increases by about 10^18. Based on the above, with N=8, one might expect the dependent variables to have numerical values in the range +/-10^81, which is about the same as the number of atoms in the known universe

I always get worried when I see numbers like this. Ask yourself some serious questions.

1. If you are modelling some "real-world" phenomenon, what range of values would you expect for the dependent variables? You ought to be able to make a rough guess!
2. Do you really believe that your system can produce values greater than the number of atoms in the universe? If so, how?, why?, what are you modelling?

Don't understand the question...

You state

Thanks a lot for this. I cannot use builton command beacuse system of ODE's increase as i will increase the value of "N".

For a start, there is no 'N' in your worksheet, so what is increasing? The number of ODEs? the complexity of the ODEs?

Why do you think that you can produce some "magic code" which will work better than Maple's built-in ODE solvers?

Maybe if I understood the real problem you are trying to solve, I could make sensible suggestions

Have you ever considered...

using the big green up-arrow in the Mapleprimes toolbar to upload worksheets which are causing you a problem?

That way, responders here can execute your worksheet, figure out  possible improvements, and do all kinds of useful stuff.

On the other hand you can upload a video which doesn't show (most of) your code, so cannot be read , cannot be executed, cannot be analysed, and hence is unlikely to be "improved"

1. Rule 1 - upload an executable worksheet
2. Rule 2 - if you think there is a "better" approach, stop thinking and apply Rule 1

Or...

You could set the animation speed using the FPS box in Maple's animation toolbar

When vectors are given angle brackets...

you still don't need the InertForm() package, entering data as strings, then parsing strings etc etc - Sure it will work, but that is the conplicated way to do something simple. See the attached for a "simple" variation on my original answer, based on the following observations

1. entering data as strings - cumbersome and unnecessary
2. "parsing" such entries - cumbersome and unnecessary
3. of course the above approaches will "work", but why bother? Isn't the attached just - well, simpler?
 > # # One possible variant of OP's desired expression #   Set:= `%+`(  1/3%*<3^(1/2), -3^(1/2), 3^(1/2), 0>,               -1/3%*<3^(1/2),  3^(1/2), 3^(1/2), 0>               +3*<2,1,1,0>             ); # # Quick check on export+import to/from MathML #   a:= MathML:-Export(Set):   MathML:-Import(a);
 (1)
 > # # Another possible variant of OP's desired expression #   Set:= `%+`(  1/3%*<3^(1/2), -3^(1/2), 3^(1/2), 0>,               -1/3%*<3^(1/2),  3^(1/2), 3^(1/2), 0>,                <2,1,1,0>             ); # # Quick check on  export+import to/from MathML #   a:= MathML:-Export(Set):   MathML:-Import(a);
 (2)
 >

I don't care...

whether you use "worksheet mode", "Document mode", "1-D Input", "2D-input" what. You can save the worksheet on your local machine as a file with extension ".mw". Upload this file to this site using the big green up-arrow in the Mapleprimes toolbar

First thing...

post an executable worksheet using the big green up-arrow in the Mapleprimes toolbar - because no-one here is going to re-type your stuff from a useless "picture"

I'd also...

take a long hard look at the boundary condition

theta(0, t) = 1 + b(1 - cos(varpi*t))

'b' has been defined as 1, so the above is equivalent to

theta(0, t) = 1 + 1(1 - cos(varpi*t))

The second term on the rhs will be interpreted as as a function named '1' with an argument (which is irrelevant) because in Maple the construction 1(x) will return 1, so the above bc evaluates to

theta(0, t) = 2

I'm guessing that this isn't what you intended!

An observation...

which applies to the response you have given, as well as that gien by dharr.

(And before I make this observation, I want to make it clear that I have been playing with this problem for a while, and so far haven't come with anything significant)

My issue with both Rouben's response (and that of dharr), is that both imply that the velocity in the x-direction changes. My simple-mided brain says that there is no "force" in the x-direction, hence there can be no acceleration in the x-direction, hence the x-velocity cannot change.

So the question for boith Rouben and dharr - why does the x-velocity change? What force is causing this?

Or possiblle...

as shown in the attached

 > restart;   expr:= diff(u(t,x,v),t)+v*diff(u(t,x,v),x)+diff(u(t,x,v),x)*int(u(t,x,v)*v*exp(x),v)-v*diff(u(t,x,v),v)*sin(v)*int(v*diff(u(t,x,v),x),v)=0;   kf:=convert(FunctionAdvisor(known_functions, quiet), set):   seq( `if`(member(op(0,j), kf), j, NULL), j in indets(expr, function));
 (1)
 >

Hmmm...

However the following "toy" example shows usage of both the CodeGeneration:-Python() command and the Python() package, just to give some idea of what is possible.

 > restart:   alias(CG=CodeGeneration):   alias(P=Python): # # Define a not-too-trivial" procedure in Maple #   detHilbert:=  proc(n::posint)                     uses LinearAlgebra;                     return Determinant( HilbertMatrix( n ) );                 end proc: # # Compute one value for later comparison purposes #   evalf(detHilbert(10));
 (1)
 > # # Generate "Python code" for the above procedure (as a string) #   pycode:= CodeGeneration:-Python(detHilbert, output=string);
 (2)
 > # # Define the above procedure within Python #   Python:-EvalString( pycode, output=none ); # # Execute the Python procedure (in Python) #   Python:-EvalString("detHilbert(10)")
 (3)
 >

This is version-dependent...

Maple 2022.1 produces the attached - which at least avoids the Float(undefined) issue

 >
 >
 (1)
 >
 >
 >
 >
 >
 (2)
 >
 (3)
 >
 (4)
 >
 (5)
 >

You state...

Even for j=1, lets say red colour curve, there are two curves there

As I explained before, technically there is one curve, with a gap in it because the relevant equation for yj(r) generates complex values.

To see onlyone section of each curve , you can plot with r=0..10 or r=-10..0, rather than r=-10..10 as shown in the attached.

 > restart;   expr:=[ [ (1.428571429*(r^2+.49-4*r*(r^2+.49-2*exp(-.1/r))/(2*r-.2*exp(-.1/r)/r^2)))*csc((1/3)*Pi),           sqrt(16*r^2*(r^2+.49-2*exp(-.1/r))/(2*r-.2*exp(-.1/r)/r^2)^2+.49*cos((1/3)*Pi)^2-2.040816327*(r^2+.49-4*r*(r^2+.49-2*exp(-.1/r))/(2*r-.2*exp(-.1/r)/r^2))^2*cot((1/3)*Pi)^2)         ],         [(1.428571429*(r^2+.49-4*r*(r^2+.49-2*exp(-.1/r))/(2*r-.2*exp(-.1/r)/r^2)))*csc((1/3)*Pi),           -sqrt(16*r^2*(r^2+.49-2*exp(-.1/r))/(2*r-.2*exp(-.1/r)/r^2)^2+.49*cos((1/3)*Pi)^2-2.040816327*(r^2+.49-4*r*(r^2+.49-2*exp(-.1/r))/(2*r-.2*exp(-.1/r)/r^2))^2*cot((1/3)*Pi)^2)         ],         [(5.*(r^2+0.4e-1-4*r*(r^2+0.4e-1-2*exp(-.2/r))/(2*r-.2*exp(-.2/r)/r^2)))*csc((1/3)*Pi),           sqrt(16*r^2*(r^2+0.4e-1-2*exp(-.2/r))/(2*r-.2*exp(-.2/r)/r^2)^2+0.1e-1*cos((1/3)*Pi)^2-25.*(r^2+0.4e-1-4*r*(r^2+0.4e-1-2*exp(-.2/r))/(2*r-.2*exp(-.2/r)/r^2))^2*cot((1/3)*Pi)^2)         ],         [(5.*(r^2+0.4e-1-4*r*(r^2+0.4e-1-2*exp(-.2/r))/(2*r-.2*exp(-.2/r)/r^2)))*csc((1/3)*Pi),          -sqrt(16*r^2*(r^2+0.4e-1-2*exp(-.2/r))/(2*r-.2*exp(-.2/r)/r^2)^2+0.1e-1*cos((1/3)*Pi)^2-25.*(r^2+0.4e-1-4*r*(r^2+0.4e-1-2*exp(-.2/r))/(2*r-.2*exp(-.2/r)/r^2))^2*cot((1/3)*Pi)^2)         ]        ]:
 >
 > # # From the above, the first and second parametric # curves will the have the same "x-value" and #  "y-values" of opposite sign, so the second # parametric curve is identical to the first # parametric curve exceptfor a reflection in the x-axis. # # The same applies to the third and fourth parametric # curves - identical except for reflection in x-axis #   plot( [seq( [expr[j][], r=-10..10], j=1..4)],           -13 .. 5,           -5 .. 5,           color=[red, blue, green, black]);   plot( [seq( [expr[j][], r=0..10], j=1..4)],           -13 .. 5,           -5 .. 5,           color=[red, blue, green, black]);   plot( [seq( [expr[j][], r=-10..0], j=1..4)],          -13 .. 5,          -5 .. 5,          color=[red, blue, green, black]);
 >
 >

works for me...

without error in Maple  2022.1 on Windows.

So doesn't look like a Maple version issue.

Soesn't look like an OS issue - at keast for Linux/Windows

maybe MacOS issue?

Run the attached (which does a version check) and upload hte output

 > restart: interface(version);
 (1)
 > with(plots):
 > equ1 := BesselJ(sqrt(17)/2, 10*sqrt(t)*sqrt(2))/t^(1/4) + BesselY(sqrt(17)/2, 10*sqrt(t)*sqrt(2))/t^(1/4):
 > equ2 := BesselJ(sqrt(17)/2, 10*sqrt(t)*sqrt(2))/t^(1/4) + 5*BesselY(sqrt(17)/2, 10*sqrt(t)*sqrt(2))/t^(1/4):
 > equ3 := BesselJ(sqrt(17)/2, 10*sqrt(t))/t^(1/4) + 5*BesselY(sqrt(17)/2, 10*sqrt(t))/t^(1/4):
 > tmax   := 30: colors := ["Red", "Violet", "Blue"]: p1 := plot([equ1, equ2, equ3], t = 0 .. tmax, labels = [t, T[2](t)], tickmarks = [0, 0], labelfont = [TIMES, ITALIC, 12], axes = boxed, color = colors): ymin := min(op~(1, op~(2, op~(2, [plottools:-getdata(p1)])))): ymax := max(op~(2, op~(2, op~(2, [plottools:-getdata(p1)])))): dy   := 2*ymax:
 > legend1 := typeset(C[3] = 1, ` , `, C[4] = 1, ` , `, Omega^2 = 50): legend2 := typeset(C[3] = 1, ` , `, C[4] = 5, ` , `, Omega^2 = 50): legend3 := typeset(C[3] = 1, ` , `, C[4] = 5, ` , `, Omega^2 = 25): p2 := seq(textplot([tmax-2, ymax-k*dy/20, legend||k], align=left), k=1..3):
 > p3 := seq(plot([[tmax-2, ymax-k*dy/20], [tmax-1, ymax-k*dy/20]], color=colors[k]), k=1..3): display(p1, p2, p3, view=[default, -ymax..ymax], size=[800, 500])
 >

Well...

@Tereso
'f(x,y)^2+(z-1)^2=0  still requires z=1 for the same reason as before so you are probably better to use a 2-D implicitplot and transform it to 3D, as in the attached "toy" example.

Whatever algorithm implicitplot3d() is using doesn't seem to work very well when one of the coordinates is restricted to a single value :-(

 > restart;   with(plots):   with(plottools):   p1:=implicitplot( x^2+y^2=9, x=-10..10, y=-10..10):   f:=transform( (x,y)->[x,y,1]):   display(f(p1));
 >
 >