## 5323 Reputation

9 years, 271 days

## So many basic syntax errors...

that the code you present is basically unfixable. Now just becuase I like making guesses, I'm going to make the following observations/recommendations

1. learn the difference between a function with an argument nad an indexed variable: for example x(0) is the function x() with the argument 0, x[0] is the zeroth element of indexable variable 'x'. These are two entirely different concepts.  If you don't understand the difference, then don't write any code until you do!
2. learn the difference between an indexable quantity (eg x[0]) and one with an inert subscript (eq x__0). If you choose to use Maple's 2D input option then this will "appear" the same in both input and output lines - although, of course, they have entirely different meanings. If you don't understand the difference, then don't write any code until you do!
3. don't use the same name as the index variable in a "for" loop and then as the index variable in any statement (eg add() ) within that "for" loop. You *might* get away with this ( Maple's scoping rules are pretty good), but it is a high-risk activity.
4. don't try to define a variable in terms of itself - for example in your code you have various places where you write something like x[n+1]=add(x[n], n=0..m). Note that this violates recommendation (3) above, but let's just assssume for the moment that Maple's scoping rules will handle this, and that the two quantities labelled 'n' on either side of this assignment are entirely distinct - so that (for example) Maple will (may?) interpret this as x[2]=add(x[n], n=0..m). Consider what happens if n=2 on the lhs and m=2. Then the statement becomes x[2]:=x[0]+x[1]+x[2]. So you are trying to assign x[2] in terms of itself. This is known as "recursive assignment" and will never work.
5. If I guess what you actually mean when you commit any/all the errors above and try to fix it then I will get something like the attached. (I have also assumed that when you defined the parmeter 'u' and then never used it, you actually meant the parameter 'mu' which is used but never defined - of course this could be one of the many guesses where I'm wrong

Anyhow for what it is worth, the attached *might* be of some use - but you will have to check every single guess I have made

 > restart; m := 10; S[lambda] := sum(S[b]*lambda^b, b=0..m): L[lambda]:= sum(L[b]*lambda^b, b=0..m): G[lambda]:= S[lambda]*L[lambda]: ft := unapply(G[lambda], lambda): for i from 0 to m do     A1[i] := (D@@i)(ft)(0)/i!; end do;
 (1)
 > beta:= 0.04: lambda:= 0.4: delta:= 0.3: d:= 0.01: e:= 0.1: a:= 0.2: k:= 0.6: mu:= 0.03: q:= 0.8: x[0]:= 9: w[0]:= 3: y[0]:= 1: v[0]:= 4: m := 3:
 > for n from 0 to m do     x[n+1]:= x[0]+lambda*t-d*int(add(x[jj], jj=0..n), t=0..t)              -              beta*int(add(x[jj], jj=0..n)*x[n]*v[n], t=0..t);     w[n+1]:= w[0]+(1-q)*beta*int(add(x[jj]*v[jj], jj=0..n), t=0..t)              -              e*int(add(w[jj], jj=0..n), t=0..t)              -              delta*int(add(w[jj], jj=0..n), t=0..t);     y[n+1]:= y[0] + q*beta*int(add(x[jj]*v[jj], jj=0..n), t=0..t)              -              a*int(add(y[jj], jj=0..n), t=0..t)              +              delta*int(add(w[jj], jj=0..n), t=0..t);     v[n+1]:= v[0] + k*int(add(y[jj], jj=0..n), t=0..t)              -              mu*int(add(v[jj], jj=0..n), t=0..t); end do
 (2)
 >

## Many ways to do this...

of which the attached is only one

 > restart;   with(plots):   with(plottools):   d1:= display        ( [ display            ( circle              ( [-6,0],                6,                color=red,                thickness=2              )            ),            plot( 6*sin(x),                  x=0..4*Pi,                  color=red,                  thickness=2                )          ]        ):   F:= proc(t)            display            ( [ display                ( line                  ( [-6,0],                    [6*cos(t)-6, 6*sin(t)],                    color=blue,                    thickness=4                  )                ),                pointplot                ( [t, 6*sin(t)],                  symbol=solidcircle,                  symbolsize=24,                  color=blue                )              ],              scaling=constrained            );       end proc:    animate( F, [theta], theta=0..4*Pi, background=d1, frames=100);
 >

## Not an explanation...

but if I were trying to achieve the same(?) thing, I'd probably wirte the attached - which *seems* to work

 > p:= proc()            local x:=1,                  v:= ;            return v;       end proc;   ans:=p();
 (1)
 >

## A solution...

It is not too difficult to "reproduce" the calculation in the paper you reference, which is done in the attached

 > restart;   interface(version);
 (1)
 > # # Set up system for the paper supplied by the OP. # The two "important equations in that paper are # numbered eq1 and eq37 - so use the same labelling here #   eq1:=v__beta(r,beta)=2*R__i^2*(R(beta)^2-r^2)/R(beta)^4;   eq37:=diff(v__r(r, theta, beta),r)*r*(R__f-r*cos(theta))+v__r(r,theta,beta)*(R__f-2*r*cos(theta))+r*diff(v__beta(r,beta),beta)=0; # # According to the text eq1 is subject to the additional # condition that # # R(beta)=R__i+2*beta*(R__f-R__i)/Pi # # so make this substitution in eq1 #   eq0:=R(beta)=R__i+2*beta*(R__f-R__i)/Pi;   eq1a:= subs(eq0, eq1); # # Then susbtitute this result in eq37 to produce the # "ordinary linear first-order differetnial equation" #   eq37a:=simplify(expand(subs(eq1a, eq37)));
 (2)
 > # # Solve the above differential equation #   sol1:=simplify(dsolve(eq37a, v__r(r, theta,beta))); # # The solution contains an arbirary function # _F1(theta, beta) in the "undifferentiated" variables # so I am arbitrarily(?) going to set this function to 0 #   sol2:=eval(sol1, _F1(theta, beta)=0);
 (3)
 > # # The above solution *looks* very similar to the desired # solution (labelled eq2 in the OP's reference paper), but # trying to massage sol2 above to exactly match the form # the form given in the paper could take for ever! # # Easier just to reproduce eq2 (from the paper) here #   eq2:=v__r(r, theta, beta)=4*Pi^2*r*(R__f-R__i)*R__i^2*((Pi*R__i+2*(R__f-R__i)*beta)^2-Pi^2*r^2)/((Pi*R__i+2*(R__f-R__i)*beta)^5*(R__f-r*cos(theta)));
 (4)
 > # # Check that the right hand side of the ODE solution above # and eq2 (from the paper) are the same, by subtracting them. # # Answer should be zero! #   simplify(rhs(sol2)-rhs(eq2));
 (5)
 > # # Knowing that the solution obtaine by dsolve() above is # "correct", OP's original worksheet wants to compute # this for some given values of parameters #   d:=10: c:=10: LI:=4: R__i:=d/2+LI: R__f:=c+d/2+LI: # # so that the solution sol2 becomes #   sol2;
 (6)
 >

## Observation...

Maple18, Maple 2015, and Maple 2016 all return "infinity"

Maple 2017, Maple 2018 and Maple 2019 all returrn Pi*R

Looking at the "updates" in Maple 2017 (see ?Advanced Math), there is a whole section on improvements associated with symbolic integration. So I guess whatever the original problem, one of these updates fixed it.

## You can't...

do a contour plot of a vector field, since the former is magnitude-only and the latter contains both magnitude and direction. You can produce a contour plot of the magnitude of the vector field, which is what I have done in the attached

 > restart;   with(VectorCalculus):   with(plots):   epsilon:=.01: # # Define the potential and plot it #   pot := 1/sqrt(x^2+y^2+epsilon)-1/sqrt((x-.25)^2+y^2+epsilon):   contourplot(pot, x=-0.5..1, y=-0.5..0.5, grid=[100,100]); # # Take the gradient of the potential - which should be the # electric field #   v := VectorField( Gradient( pot, [x,y] ), 'cartesian'[x,y] ): # # Produce a field plot #   fieldplot(v, x=-0.5..0.5, y=-0.5..0.5, arrows=THICK, color=red, anchor=tail); # # OP wants a contour plot of the electric field. However # a contour plot is magnitude-only. Presumably OP wants the # contour plot to represent the purely the magnitude of the # vector field #   contourplot(Norm(v)(), x=-0.5..1, y=-0.5..0.5, grid=[100,100]);
 >

## A lot of syntax problems...

which I *think* I have fixed in the attached. This involved removing lots of redundant stuff and a fair amount of editing so the chances that I got everything correct is not that great. I suggest you read/check this very carefully

For some reasom this site is not displaying worksheets correctly today, so you will have to download/execute

someODEs.mw

## Confusing objective...

the attached will calculate/plot both speed() and L() for any numeric argument.

Unfortunately the MApleprimes uploader sppears to be broken - again- and will not display the contents of this file on this site so you will have to download/execute

speedandL.mw

## Things to investigate...

My ability to help is limited by the fact I only have a 'bare' copy of Matlab with no addOns/toolboxes, other than the Maple toolbox. However the following observations may be helpful

From the Matlab 'HOME' tab, Add-Ons -> Manage AddOns does not identify the Maple toolbox as a conventional add-on. In fact it does not appear in this list at all. Suggests that one cannot use Matlab'x Add-On manager

On the other hand, from the Matlab 'HOME' tab Set Path shows two Maple-related entries, in my case at the bottom of the list. These entries are

C:\Program Files\MATLAB\R2019b\toolbox\maple
C:\Program Files\MATLAB\R2019b\toolbox\maple\util

So I *assume* that when one installs the Maple toolbox, the Matlab default pathdef.m file (located in C:\Program Files\MATLAB\R2019b\toolbox\local for a "default" installation) is edited to include these "Maple-related" entries. Presumably also, during the Maple toolbox installation, references to the "default" Matlab symbolic toolbox are removed from the pathdef.m file.

So the first thing experiment I would try

1. Uninstall the Maple toolbox
2. Verify that the default symbolic toolbox is working
3. Copy the pathdef.m file to somewhere convenient
4. Reinstall the Maple toolbox
5. In a decent editor check the differences between the "current" pathdef.m file and that saved at step (3) above. They *ought* to be different - references to the default symbolic toolbox removed and references to Maple included
6. At this stage (ie with the Maple toolbox installed and "active"), use the Matlab toolbar HOME->Set Path dialogue to remove the two Maple entries
7. Path changes take place "immediately" (ie no restart is necessary), this ought to disable the Maple toolbox (without "unistalling" it
8. Assuming that everything has worked until now find the references to the defalt symbolic toolbox obtained at step 5) above, and again using the HOME->Set Path dialogue, use the Add folder option to reinstate these.
9. Verify that the default symbolic toolbox is now working
10. Again assuming that everything is OK, you can now "toggle" beween default and Maple symbolic toolboxes just by using the Add Folder and Remove Folder options in the Set Path dialogue

## The brain-dead way...

As has already been noted it is not clear whether you mean 12^(6^5), or (12^6)^5.  The attached does both

 > restart:
 > doWork:=proc( N::posint)                 local p,                       num:=N,                       digsum:=add                               ( irem                                 (num, 10, 'num'),                                 p=1..length(num)                               );                 if   irem(digsum, 3)=0                 then printf( "      %a is divisible by 3\n", digsum):                 elif isprime(digsum)                 then printf( "      %a is prime\n", digsum):                 else printf( "      %a is nether prime nor divisible by 3\n")                 fi:           end proc:   doWork(12^(6^5));   doWork((12^6)^5);
 37845 is divisible by 3       153 is divisible by 3
 >
 >

## Don't really see what you are trying to ...

You can't use Maple's in-built numeric solver when you have three boundary conditions on the same dependent variable - you have Z(0)=1, Z(1)=exp(1) and Z(3/4)=exp(3/4). In the attached I have used a simple "shooting method" approach to convert the last of these conditions into an additional condition at x=0, by generating an appropriate value for  D[1\$2](Z)(0).

Once this has been obtained then you can use Maple's dsolve() with the 'numeric' option to obtain the desired(?) solution

Check the attached

 > restart:   f:= 0:   Y:= 1+x-58/9*x^2-3*x^2*exp(1)+64/9*x^2*exp(3/4)+40/9*x^3+4*x^3*exp(1)-64/9*x^3*exp(3/4):   odesys:= [ diff(Z(x), x\$4) = 0.001*diff(Y, x\$4)+0.999*(f+exp(-x)*Y*Y),              Z(0) = 1, Z(1)=exp(1),  D(Z)(0) = 1, D[1\$2](Z)(0) = icVal]:   getSol:= proc( alpha )                  global odesys:                  if   type(alpha, numeric)                  then return evalf                              ( rhs                                ( dsolve                                  ( eval                                    ( odesys,                                      icVal=alpha                                    ),                                    numeric                                  )(3/4)[2]                                )-exp(3/4)                              );                  else return procname(alpha)                  fi;            end proc: # # Generate the value for  D[1\$2](Z)(0) which will # "replicate" the BC Z(3/4)=exp(3/4), then solve the # resulting system #   ans:=fsolve( getSol, 0..2):   sol:=dsolve( eval( odesys, icVal=ans), numeric): # # Plot the solution of the ODE with the modified boundary # condition #   p1:= plots:-odeplot( sol, [x, Z(x)], x=0..1); # # Plot the difference between the ode solution # and exp(x) - note that this difference is "zero" # at x=3/4 #   p2:= plots:-odeplot( sol, [x, Z(x)-exp(x)], x=0..1);
 >
 >

## The bad news...

Maple and Matlab are two completely different software packages. This has a few consequences

1. Code which runs in Maple will not run in Matlab
2. Code which runs in Matlab will not run in Maple

The attached will run in Maple

 > restart;   j:= 500:      tp:= 0.07*j: Ap:= 0.25: Aq:= 0.3:     tq:= 0.03*j:   tr1:= 0.05*j: Ar:= 2:      As:= 0.4:  tr2:= 0.04*j: ts:= 0.04*j:   tt:= 0.17*j:  At:= 0.4:   u1:= 0:   u2:= (Ap/2)*(sin((2*Pi*t/tp)+(3*Pi/2))+1):   u3:= 0:   u4:= -(Aq/tq)*t:   u5:= (((Ar+ Aq)/tr1)*t)-Aq:   u6:= -(((Ar+ As)/tr2)*t)+Ar:   u7:= ((As/ts)*t)- As:   u8:= 0:   u9:= (At/2)*(sin((2*Pi*t/tt)+(3*Pi/2))+1):   u10:= 0:   with(plots):   display( [ plot(u1, t=1..0.1*j),              plot(u2, t=1..tp),              plot(u3, t=1..0.08*j),              plot(u4, t=1..tq),              plot(u5, t=1..tr1),              plot(u6, t=1..tr2),              plot(u7, t=1..ts),              plot(u8, t=1..0.1*j),              plot(u9, t=1..tt),              plot(u10,t=1..0.08*j)            ],            view=[0..100,-1..3],            axes=boxed          );
 >

## Assuming...

that you actuallly do have the data as a matrix, then

ExportMatrix(fileName, matrixName)

ought to work.

To recall this information

M:=ImportMatrix(fileName)

will retrieve the matrix

## One way...

is shown in the attached

 > restart; # # Define a simple function called 'delta' #   delta:= (k::integer, r::integer)->`if`( k-r-1=0, 1, 0 ): # # A couple of examples #   delta(5,4);   delta(5,3);
 (1)
 >

## Hmmmmmm...

well

1. In the first place I don't see why you are using spline fits, since the process you invoke is
1. define a function
2. plot the function
3. extract data from the plot
4. fit this data using splines to produce an approximation of the function which you already know at step (1) above
5. use this approximate "fit" in subsequent calculations. Why????
6. Hence I have removed all the spline fit stuff - it is pointless in the worksheet you supply
2. You state that "in graph t=4000 my result is illogical". Actually no -it is entirely logical and has to to with the magnitudes of the functions h(x) and r(t) used in defining the boundary and initial conditions. The first of these is zero unless 5000<x<10000: within this range it never exceeds ~1.2*10-37 so could be considered very, very small with "little impact" on the overall PDE solution. On the other hand the initial condition C(0, t) = r(t) is identically zero for t<3600 and t>21600, but between these values, it gets very big, very quickly. For your first four plots, ie t= 2, 1000, 2000, 3000, C(0,t) is identically zero. For the case you find illogical (ie t=4000), the boundary condition evaluates to C(0,t)=2.88*10^7. I (for one) am not really surprised that when you move from a region where a boundary condition evaluates to 0, to one where the same boundary condition evaluates to 2.88*10^7 then one might expect a significant change in the PDE solution

More details are given in the comments in the attached

 > restart;
 > with(plots):   with(plottools):   with(CurveFitting):
 > f:= x -> piecewise( 0 < x and x <= 5000, 0,                       5000 < x and x <= 7500, 0.008*x - 40,                       7500 < x and x <= 10000, -0.008*x + 80,                       10000 < x and x <= 15000, 0                     );   Ic:=plot( f(x),             x = 0 .. 15000,             color = blue,             legend = ["Initial Condition"],             labels = ["x", "concentration"],             axis = [tickmarks = [5, subticks = 1]]           );
 > g := t -> piecewise( 0 < t and t <= 3600, 0,                        3600 < t and t <= 10800, t/240-15,                        10800 < t and t <= 21600, -t/360+ 60,                        21600 < t and t <= 36000, 0                       );   Bc:= plot( g(t),              t = 0 .. 36000,              color = green,              legend = ["Boundary Condition"],              labels = ["time(s)", "concentration"],              axis = [tickmarks = [10, subticks = 1]]            );
 > v := 0.5: alpha := 15: mu := (-v)/(2*alpha): beta := v^2/(4*alpha):   h := x -> f(x)/exp(-mu*x):   r := t -> g(t)/exp(-beta*t): # # As defined above the function f() has a maximum of of 20 # at x=7500. However at this x-value, the value of exp(-mu*x) # as given by eval(exp(-mu*x), x=7500) will be 1.935576042*10^54 # so that the maximum value of the function h() will be h(7500) # which comes out to be 1.033284127*10^(-53), which is pretty # close to zero for all practical purposes # # Hence when the OP uses C(x, 0) = h(x) as a boundary condition, # this is identically zero for x<5000 and x>10000. It is also # very close to zero in the range 500021600. But somehere # around t=10800, it becomes 30/2.862518552*10^(-20) or about # 1.048028142*10^21. Since the denominator decreases exponentially # as t increases the value of r() will continue to increase # beyond the nominal maximum in the function g(), reaching a peak # of about 2.9*10^38 somewhere around t=21350 as can be seen # from the second of the following plots #   plot(r(t), t=3600..21600);
 > # # Bearing in mind the range of values illustrated above for # h(x) and r(t), consider the PDE and the BCs/ICs # # For any value of t<3600, the boundary condition C(0,t) is # identically zero. Hence (roughly speaking) the values of # C(x,t) for t=2,1000,2000, 3000, are governed mainly by the # the form of the ODE and the BC C(x, 0) = h(x). Since h(x) # is always "tiny" all of these solutions will be "tiny" as # seen in the first plot below # # However for t>3600 (as in the plot case t=4000), the value # of C(0,t)=r(t) becomes "huge" (r(4000)=2.88*0^7) with a # consequent effect on the PDE solution as seen in the second # plot below #   PDED := diff(C(x, t), t) = 15*diff(C(x, t), x, x):   IBCD := C(x, 0) = h(x), C(0, t) = r(t), D[1](C)(15000, t) - mu*C(15000, t) = 0:   pdsD := pdsolve(PDED, [IBCD], time = t, range = 0 .. 15000):   display( [ pdsD:-plot(C(x,t), t = 2,    color = red),              pdsD:-plot(C(x,t), t = 1000, color = blue),              pdsD:-plot(C(x,t), t = 2000, color = green),              pdsD:-plot(C(x,t), t = 3000, color = orange)            ]          );   pdsD:-plot(C(x,t), t = 4000, color = black);
 >