There is a collspased (hidden) Execution Group in the Document Block in the Table Cell in the 4th row and 3rd column.

That's the same row whose first column Cell contains "inclination angle of the swash plate".

The problematic Cell curretly shows a TextArea component whose current entry is "1.2".

To reveal it, use the mouse pointer and select the content of that Cell (or an larger selection that contains that Cell). Then, while it is selected, use the main menubar item View->Group and Block Management->Expand Document Block. After that the offending Execution Group will be visible, below the Execution Group that contains the TextArea.

Delete the problematic Execution Group, which contains a call to the Tutor. You can use Ctl-Delete for that. The Select the upper Execution Group's content (the TextArea), and use the menubar item View->Group and Block Management->Collapse Document Block.

That corrects the problem with the Tutor launching every time the sheet is executed in its entirety.

There is another mistake. The Action code on that TextArea component in the Cell in the 4th row and 3rd column contains some code. Right-click on it invoke the "Edit Content Changed Action..." popup menu item, so as to edit that code. The mistake is that it is missing the final end use; line.

acer

Notice how the mL and g in your axis label are in italic. But if you used :-min in the label then it would be typeset in upright (roman).

It would look better if all these unit symbols and abbreviations (prefixed or not) were typeset consistently. And one simple way to get that effect is to create the axis labels using the Unit() command.

For example, using your previous code,

plot(fprod(t), t = -2..2,
     labels = [typeset("Time (", Unit(min), ")"),
               typeset("Rate (", Unit(mL/(min*g)), ")")],
     color = "blue");

acer

Is this what you mean?

restart:

ode:=diff(x(t), t, t)+(1000*(x(t)^2-1))*(diff(x(t), t))+x(t) = 0:
sollistA:=dsolve({ode,x(0)=-1,D(x)(0)=-0.8},numeric,output=listprocedure):

# method 1, numerical differentiation, after dsolve. Not generally robust.
X:=eval(x(t),sollistA):
plot(t->fdiff(X(tt),[tt,tt],{tt=t}), 0..1);

# method 2, isolate higher derivative from the original ode, if you can,
# and evaluate each function on the right using the listprocedure.

rhs(isolate( ode, diff(x(t), t, t) ));
DDXA:=eval(%, sollistA):
plot(DDXA, 0..1);

# method 3, augment the original DE with an extra equation,
# and then use that function from the listprocedure.

sollistB:=dsolve({ode,diff(x(t),t,t)=ddx(t),x(0)=-1,D(x)(0)=-0.8},
                 numeric,output=listprocedure):

DDXB:=eval(ddx(t),sollistB):
plot(DDXB, 0..1);

acer

The first of these just happens to work (but you can also force it with a few `collect` calls and a mapped simplify...).

It might be possible to harangue the terms so that the "Nu" name appears at the left of each product. I didn't go there.

Download Polysimp.mw

acer

Without attempting to manipulate your procedure's body in order to deal with the numeric difficulties more gracefully...

Download trighplot.mw

acer

Just assign the result of plots:-display to P.

  P := plots:-display( P1, P2 ):

Then P is a structure that contains both. So then either of the following will once more show it.

  plots:-display( P );

  print( P );

Also, in an earlier question you mentioned animating, if I recall. If so then try,

  plots:-display( P1, P2,... Pn, insequence=true );

which again you can assign to a new name.

acer

See section 6.5 of the Programming Manual, under the subheading "The remember, cache, and system Options".

acer

You didn't provide values for a, D1, and D2. So I just made some up.

If you wanted you could also treat those as parameters (in the dsolve/numeric sense).

Below, I'll treat q as a parameter for dsolve. See here for details on that.

Download odecurves.mw

acer

The curve is almost flat in the given range of x=-4..4. So to get an idea of the qualitative aspects of the curve one can increase working precision (to deal with accuracy issues), subtract off the ostensibly constant part, and manually create tickmarks.

Download flat.mw

The method=_d01amc seems to work fast here, in Maple 18.02. That is a compiled NAG Library function designed for semi-infinite integrands.

This is a hint that the problem was in something like an attempt at either expanding the integrand or poking at it for discontinuities in evalf/Int's internal control mechanism. For similar problems seen in the past a workaround has often been to force a suitable method or to unapply the integrand to get an operator rather than an expression.

If you raise Digits to 15 in your original, and use 5 steps, then the results appear to concur with those from forcing this method.

I was also able to simplify the integrand more compactly.

I also changed your initial constants to exact values (ie. 1 rather than 1.0, etc). It's quite often better to keep floats out of things... as much as possible until after you've finished simplifying expressions.

Download int_question.mw

The printed results A[i,2] of the above, using epsilon=1e-8, were,

                       -1.06754466261525
                       -1.05325302242161
                       -1.03558981773781
                       -1.01386179523186
                       -0.987289540024826
                       -0.955029158917161
                       -0.916216297715231
                       -0.870041095327763
                       -0.815862074159109
                       -0.753362760097712

That ran very fast, in my Maple 18.02 on 64bit Linux.

And (only) raising Digits to 15 in your original with epsilon=1e-5, and using 5 steps, I got,

                       -1.05325301997235
                       -1.01386179283364
                       -0.955029156513430
                       -0.870041093087944
                       -0.753362758062382

acer

Download cotrule.mw

Now, did you also prefer to have cos(N*h)+cot(N*q+A)*sin(N*h) instead of sin(N*h+N*q+A)/sin(N*q+A) ?

acer

This is a very common mistake. The formal parameters A, omega, and k of your original procedure SW are not the same as the (in this example, global) A, omega, and k in the expressions W1, W2, and W.

Here are two ways to make it work.

restart;
with(plots):

W1:=A*cos(omega*t-k*x):
W2:=A*cos(omega*t+k*x):
W:=W1+W2:

SW:=(A,omega,k)->animate(plot,[eval([W1,W2,W],[:-A=A,:-omega=omega,:-k=k]),
                               x=-4..4,color=[red,green,blue],
                               scaling=constrained],t=0..5,frames=10):

display(SW(2,2*Pi,5),insequence);

AltSW:=unapply('animate'(plot,[[W1,W2,W],
                               x=-4..4,color=[red,green,blue],
                               scaling=constrained],t=0..5,frames=10),
               [A,omega,k]):

display(AltSW(2,2*Pi,5),insequence);

acer

If you have your heart set on using a RealRange, then you can test the condition using the is command. Note that if...then will utilize evalb in your original, which is insufficient.

evalb( 0.5 in RealRange(0,1) );

                                                0.5  in  RealRange(0, 1)

is( 0.5 in RealRange(0,1) );   

                                                          true

If you don't need to mess about with Open() end-points then you might find it simpler to do it as follows,

0.5>=0 and 0.5<=1;

                                                          true

If the RealRange is being passed to you as a result of another computation you could also try it like so. Again, this doesn't account yet for the Open endpoints cases -- if you have such then using is might be simpler,

r := RealRange(0,1):  # given elsewhere...

0.5>=op(1,r) and 0.5<=op(2,r);

                                                           true

acer

Download megawatts.mw

acer

I chose the height for the 2D part to be minz+(minz-maxz)*0.1 using the min and max of the 3D part. It has not meaning, in terms of the expression `ee` that is plotted as the surface. Change that if you wish.

Download surfcont.mw

acer