Carl Love

Carl Love

28110 Reputation

25 Badges

13 years, 119 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are answers submitted by Carl Love

If you're talking about a boundary value problem (BVP) in ordinary differential equations (ODEs), then variable grid sizing is handled automatically by dsolve. It can be controlled with the options initmesh and maxmesh.

If you're talking about partial differential equations (PDEs), then these are called multigrid methods. These are far beyond what's currently implemented in Maple for the numeric solution of PDEs. You'd need to program your own. It'd be an extensive project, but ultimately doable.

Yes, using vectors is almost necessary. I can think of a convoluted way without vectors, but it's just an academic exercise and definitely not worth the trouble.

If you know that you're going to be exporting to Excel, you should probably be using Vectors from the very start, with datatype= hfloat. This would probably be more computationally efficient than lists. Note that you don't need to know the final number of elements in a Vector while you're building it, and that it's far, far more efficient to build a variable-length Vector than a variable-length list.

If you're using Maple 2019, there's some new syntax that simplifies building variable-length Vectors. Go to the help page ?assignment and read the section "Special Semantics of the ,= Assignment Operator". 

Use the setting

interface(prettyprint= 3):

This is usually set as the default. Somehow yours got changed. (Oddly, this is at least the second time recently that I've seen a user report this.) You can make it the default by using the menu commands Tools => Options => Display => Output Display => (2-D Math Notation or Typeset Notation) => Apply Globally.

 

The topic is called cluster analysis. You'll find much information on the Web about it. I wrote some Maple code a few years ago to do it. Someone who is better at searching MaplePrimes than I am should be able to find it.

I see nothing wrong in your worksheet. Radical algebraic expressions can appear in numerous equivalent forms, for example 1/sqrt(2) = sqrt(2)/2. Your collect command does nothing in this case: The result of your asympt is a series structure that's automatically collected into powers of k, so collect isn't needed.

To go backwards, switch the from and to and add by -1: Change the second for-loop header to

for i from n-1 to 1 by -1 do ...

Note that your n-2 was also incorrect; it should be n-1. The order of the prepositions forfromto, and by doesn't matter.

Your ODEs can both be factored, as is shown by you getting multiple solutions when solving for the (highest order) derivative. Perhaps in those cases odeadvisor only analyzes the simpler factor. If there are multiple factors, you could map odeadvisor over them.

This is a start for how to get plots (a) and (b):

Given their similarity, it's no surprise that these two plots contain the same information in different formats. The relationship that connects the two plots is D__chemo = q__infinity * t__cure (total dose = constant administration rate * time administered). In other words, the vertical axis on both plots is the product of the horizontal axes of the individual plots. And t__cure is found by solving N(t) = 1 for (or perhaps N(t) = 0.5 is a better choice). In other words, the patient is cured when the number of live cancer cells is less than 1.

Outline of steps:

  1. Replace s(t) and q(t) with s__infinity and q__infinity in the ODE system.
  2. Make these formal parameters to the dsolve command by using option parameters= [s__infinity, q__infinity].
  3. Use the events option of dsolve to set a "trigger" for N(t) = 1 or N(t) = 0.5.
  4. Call dsolve to return the solution procedure, which I'll call dsol. This only needs to be done once.
  5. Write a procedure (I'll call it t_cure) that accepts a numeric value of q__infinity as its parameter and returns the corresponding value of t__cure by passing q__infinity to dsol as a parameter and integrating until the event "trigger" is "fired" and reading the value of t
  6. Set a value of s__infinity via dsol(parameters= [s__infinity= ...]).
  7. Use procedure t_cure to make a semilogplot of t__cure vs. q__infinity over some reasonable interval based on the plot (a) that you want to end up with. The purpose of this semilogplot is just to collect numeric data; there's no need to look at it if your goal is just to get plots (a) and (b).
  8. Extract the two-column data matrix from the plot via op([1,1], ...). The first column is values of q__infinity, and the second is t__cure.
  9. Multipy the two columns elementwise. These are the values of D__chemo.
  10. Go back to step 6. Repeat with different value of s__infinity
  11. Using regular plot with mode= log on both axes, plot D__chemo vs. q__infinity; this is plot (a). Do likewise for D__chemo vs. t__cure; this is plot (b). 

Add the option axis[2]= [mode= log] to the plotting command.

All that you need to do is to change specfun to specfunc.

Another type that you might find useful is typefunc(mathfunc).

You'd use subsindets if you want to take the items found by indets, modify them, and then substitute the modifications for the originals in the original expression.  It's very powerful.

You are trying to merge a static plot and an animation. A convenient way to do that is the background option to animate. Like this:

plots:-animate(
   plots:-arrow,
   [eval([p, ptan], s= A)[], width= 0.3, length= 4],
   A= 0..3, digits= 10,
   background= plots:-spacecurve(p, s= 0..16*Pi, numpoints= 1000)
);

 

The session transcripts that you show do not illustrate the phenomenon that you claim. In your first example, the error message about Physics:-diff is coming from your procedure gds which should be using Physics:-diff. In your second example, the unevaluated Determinant is external to procedure dst.

There is no bug illustrated here, nor even undesirable behavior, regardless of whether you use sec or seq. Rouben's example, however, does show a different form of undesirable behavior---a change in the global state.

Here's the worksheet:
 

restart:

RLC:= R*diff(x(t),t$2) + L*diff(x(t),t) + x(t)/C = 0;

R*(diff(diff(x(t), t), t))+L*(diff(x(t), t))+x(t)/C = 0

IC:= x(0)=10, D(x)(0)=0;

x(0) = 10, (D(x))(0) = 0

params:= [R=10, L=20, C= 1/100]:

Sol:= dsolve(eval({RLC, IC}, params));

x(t) = (10/7)*exp(-t)*sin(7*t)+10*exp(-t)*cos(7*t)

plot(eval(x(t), Sol), t= 0..5);

#Original square wave function:
step:= t-> piecewise(t < 0, 0, 1):
f:= t-> sum((-1)^n*step(t-n), n= 0..50):

#
#It's equivalent to this simpler function:
f:= t-> piecewise(floor(t)::even, 1, 0):

plot(f, 0..5, axes= frame, title= "Square Wave",thickness= 4, gridlines= false);

RLC2:= lhs(RLC) = 200*f(t/3);

RLC2 := R*(diff(x(t), t, t))+L*(diff(x(t), t))+x(t)/C = 200*piecewise((floor((1/3)*t))::even, 1, 0)

Sol2:= dsolve(eval({RLC2, IC}, params), numeric):

plots:-odeplot(Sol2, [[x(t), diff(x(t),t)]], t= 0..25, numpoints= 1000, thickness= 2, title= "Phase portrait", gridlines= false);

plots:-odeplot(Sol2, [t, x(t)], t= 0..25, numpoints= 1000, thickness= 2, title= "Solution curve", gridlines= false);

 


 

Download RLC.mw

You made a small mistake while solving. When you divide through by 10, the last term becomes 10*x. You have 50*x.

Here's how to check your work with Maple:
 

restart:

RLC:= R*diff(x(t),t$2) + L*diff(x(t),t) + x(t)/C = 0;

R*(diff(diff(x(t), t), t))+L*(diff(x(t), t))+x(t)/C = 0

IC:= x(0)=10, D(x)(0)=0;

x(0) = 10, (D(x))(0) = 0

params:= [R=10, L=20, C= 1/100]:

Sol:= dsolve(eval({RLC, IC}, params));

x(t) = (10/7)*exp(-t)*sin(7*t)+10*exp(-t)*cos(7*t)

plot(eval(x(t), Sol), t= 0..5);

 


 

Download RLC.mw

This will work for both sums and products, and many other types as well:

op(0, expr)(op(2.., expr))

First 134 135 136 137 138 139 140 Last Page 136 of 395