After some simplification the modified expression can become real-valued (eg. for positive omega). fsolve can be used for this example.

ps. Are you using Maple 2016.0, and if so have you considered upgrading to 2016.2?

Download fs.mw

Using Maple 2015.2,

restart;
ee := simplify(expand(exp(-(2*m-4)*exp(t)+t*(m+1))*(t-2*exp(t)))):
f2 := subs(foo=ee,m->evalf(Int(unapply(foo,t),0..infinity))):
plot(f2, 3..20);

or,

restart;
ee := simplify(expand(exp(-(2*m-4)*exp(t)+t*(m+1))*(t-2*exp(t)))):
f2 := subs(foo=ee,m->evalf(Int(foo,t=0..infinity,method=_d01amc))):
plot(f2, 3..20);

Why are you trying for output=Array(...)? And why with so few points? (With more points you could get a much smoother piecewise spline as an interpolation.)

Download fd2x_bvp.mw

This question has come up several times before, and you can find several old posts about it by entering the word colorbar in the Mapleprimes search.

One can manually edit the properties of the GUI Table inserted by plots:-display (to remove borders), and re-size it by dragging the borders. But such edits are lost upon re-execution.

Another possibility is to use the DocumentTools:-Tabulate command. Here is a variant on Adri's pointplot3d example.

tabulate_colorbar.mw

Unfortunately the worksheet renderer of this site is unable to inline the worksheet so that it's properly visible here.

For example here is an old post where I used Tabulate to align a 3d surface and a 2d densityplot for the colorbar. It's also possible to orient the colorbar horizontally, and locate it below/above the 3d plot. Using a 2d densityplot has the advantage that it can be constructed using the size option. However using a 2d densityplot can get tricky since one end of the hue rolls back to red. This may not match that of the 3d plot created with shading=zhue, with hue ending around magenta. So in that post I used,
    color=[f,1,1,colortype=HSV]
instead of
   shading=zhue
for the 3d surface plot.

Using the main menubar you can toggle off the item View -> Status Bar . That removes the status bar, in which the button appears (along with everything else in that bar). This aspect of the GUI's "View" is saved as a preference when the GUI is fully closed.

But I'm unaware of any way only to disable that "editable" button.

Your code assigns a value to Ha, but it appears as if you wanted the ode sys to vary with Ha=L[k].

[edit] Even if I've misunderstood the role you intend for Ha, or whether you still intend on looping, you might still utilize the visual labelling of the curves and a legend as below. [end of edit]

I'm not sure what you mean by "contour" here. Do you mean that you want to distinguish between the curves, say by color and a legend?

Download odelegend.mw

The differences in the Matrix between k=0.001 and k=0.0001 is on the order of 10^(-6), while the values themselves range from 0 to about 1.8. So you don't see the difference between frames.

I'm presuming that the computation of the data is doing what you intend.

How about plotting the difference instead?

ps. I don't see why you'd want to set Digits to 5.

Download Crank_scheme_4a.mw

I have a suspicion that this is a consequence of normal (as called by simplify) using the sign of the rational polynomial according to the lexicographic ordering of the variables.

Contrast these two cases, where variables are r and b versus r and s.

restart;
sign( (1-b/r)^(-1) );
                       -1

normal( sqrt((1-b/r)^(-1)) );
                    /    r   \1/2
                    |- ------|
                    \  -r + b/

restart;
sign( (1-s/r)^(-1) );
                        1

normal( sqrt((1-s/r)^(-1)) );
                     /  r  \1/2
                     |-----|
                     \r - s/

But, even if that speculation if correct, I'm not aware of a way to instruct kernel builtin normal to use a specific ordering for ascertaining the sign (or to enforce it somehow).

Which leaves "fixing up" the result, as recourse. One possibility here is:

H := u->simplify(sign(u)*numer(u))
        /simplify(sign(u)*denom(u)):

foo := sqrt((1-b/r)^(-1));

                      /   1   \1/2
               foo := |-------|
                      \1 - b/r/

evalindets(foo,ratpoly,H);

                       /  r  \1/2
                       |-----|
                       \r - b/

# or,

HH := u->simplify(sign(numer(u))*numer(u))
        /simplify(sign(numer(u))*denom(u)):

evalindets(foo,ratpoly,HH);

                       /  r  \1/2
                       |-----|
                       \r - b/

These aren't nearly as neat and quick as Axel's suggestion to turn the MeijerG call into a Sum.

Download MI_int.mw

You don't need to introduce a second plot, in order to utilize plots:-display.

restart;

ode:= diff(y(x),x)=2*x:

p1:=DEtools:-DEplot(ode,y(x),x = -2 .. 2,y = -2 .. 2, [[0.1,0]],
               labels=["",""],
               linecolour = red, thickness=1,
               color = "#00ccff",
               'arrows' = 'medium'                    
               ):

plots:-display(p1, axis=[tickmarks=[color=red]],
               font=["Lucida Sans",bold,12]);

The solve command is not supposed to emit an error. Your example is a bug. I will submit a bug report.

From the help page ?solve,details ,

  "If the solve command does not find any solutions, then it returns the empty
   sequence (NULL) (instead of an expression sequence or sets) or empty list
   (instead of a list of lists). This means that there are no solutions or the solve
   command cannot find the solutions."

and,

  "If the solve command cannot confirm that the solution set returned is complete,
   it sets the global variable _SolutionsMayBeLost to true and issues a warning."

So, no, it's not supposed to use an error to denote failure to find a solution. Nor is it supposed to return unevaluated.

I have reported quite a few similar bugs. There is some lack of defensive programming in the dispatch mechanism.

FWIW, turning the abs into (a multiplication by) signum can sometimes help, eg,

restart;
r:=evalc(Im(1/ln(x))):
solve(convert(r,signum),{x});
                            {0 < x}

And sure, you are free to wrap your solve calls in try..catch . In doing so you could even turn the error message into a WARNING. and/or set your own flag. Ie,

Download solve_wrap.mw

restart;
                
A:=Matrix([[1,2,3,4],[5,6,7,8]]);
X:=Vector(4,symbol=x);
B:=Vector([10,10]);

# general solution
G:=LinearAlgebra:-LinearSolve(A,B);

# free parameters in G
params:=indets(G,name);

# generate ten of them
sols:={seq(eval(G,[params[1]=0,params[2]=i]),i=0..9)};

# check them
seq(LinearAlgebra:-Norm(A.s-B), s=sols);

simplify( exp(LambertW(1, Z)) - Z/LambertW(1, Z) ); # ok
                               0

simplify( exp(LambertW(1, Z)/2) - sqrt(Z/LambertW(1, Z)) ); # oops
                               0

The kernel can only respect the timelimit when it polls the elapsed time and the internal state is safe to return from.

Both of those things can only occur at discrete intervals. The granularity affects overall performance. But the internal state issue can, almost of necessity, sometimes be very coarse. There are kernel builtins which have to finish.

Sometimes clear examples can lead to tweaking of the mechanism, in my experience.

Have you tried to find the successive statements on your code where the timelimit is overrun, but not interrupted?

If you Matrix equation has the form A.x=b (where A is a Matrix and b is a Vector) then see the LinearAlgebra:-GenerateEquations command.

Otherwise, show us the form of the Matrix equation.