The term G*M/R^2 does not appear alone in your second expression. Before your second attempt, the value of work is actually G*M*m*h/R^2 . Mathematically G*M/R^2 divides that expression, but subs is a syntactic replacement mechanism. This is one of the reasons why the algsubs command exists.

Is this what you wanted to accomplish?

Download Gravity_ac.mw

The following all works ok for me using either Maple 2017.3, or Maple 2017.2, or Maple 2017.0 on 64bit Linux.

It also includes an example in which the color shading goes from green through purple to blue (by surface height), without using the colorscheme option at all.

All the examples which do not use the colorscheme option will work in Maple 17.02 (released 2013), including the one in which the color shading goes from green through purple to blue (by surface height).

Perhaps you could upload a .mw worksheet in which it does not work, so that we could try and diagnose the issue.

Download plot3d_color_20172.mw

You need to use := instead of just = when making an assignment.

The concatenation operator (with evaluation of the suffix) in modern Maple is done using the cat command. (It was dot in the very distant past, but not now. In modern Maple the dot is used for multiplication.)

The name index is protected. Use another name.

Is this what you were trying to do?

Download coeff_max1.mw

It's more effiecient to use an indexed name rather than a concatenated name, but in that case use another name since D is protected and has a particular meaning.

Download coeff_max2.mw

If you have no other reason to retain the coefficients then there's no need to assign them separately to any new names.

Download coeff_max3.mw

I find that manual rotation (or even selection) of an implicitplot3d t makes my Linux machine bog down, especially when the grid or numpoints setting is high.

But, here, the jaggedness of the boundary can be reduced quite a bit with a higher grid setting of an explicit plot3d or contourplot3d result. And manual rotation, etc, seems to behave better.

I include a few small contour values, to illustrate the restricted domain better.

I zip the worksheet because the saved file is large, due to large plot structure which present a problem for inlining here.

3d_cont.zip

restart:
with(plots):
Omega:=5*Pi:
gamma1:=8*Pi:
gamma2:=0.002*Pi:
x1:=100*Pi:
omega2:=200*Pi:
gamma0:=0.2*Pi:
G:=20*Pi:

lambda1:=(1/(2*Pi))^2*(G*Omega*gamma0/(2*(0.25*gamma0^2+Delta^2))):
lambda2:=(1/(2*Pi))^2*(-G*Omega*Delta/((0.25*gamma0^2+Delta^2))):
lambda3:=(1/(2*Pi))^2*gamma1+lambda1:
lambda4:=(1/(2*Pi))^2*(0.2*omega2-G^2*Delta/(0.25*gamma0^2+Delta^2)):
lambda5:=(1/(2*Pi))^2*(2*x1^2*omega2/((omega2^2+gamma2^2))):
f:=epsilon-(lambda1+sqrt(-lambda2^2+Y*(lambda3^2+(lambda4-lambda5*Y)^2)))^2:
contourplot(solve(f,epsilon), Delta =-25*Pi .. 25*Pi, Y=0..1,
            contours=[0.01,0.1,0.5,1,4,8,12,16,20], axes=boxed, color=black,
            tickmarks=[3, 3], linestyle=1, grid=[501,501],
            gridlines=false, view=[-25*Pi .. 25*Pi,0..1]);

plot3d(solve(f,epsilon), Y = 0 .. 1.0, Delta=-25*Pi..25*Pi,
       style=surfacecontour, color=khaki, labels=[Y,Delta,E1],
       tickmarks=[3,3,3], grid=[351,351], view=0..20,
       orientation=[180,0,-180], lightmodel=none);

plots:-contourplot3d(solve(f,epsilon), Y = 0 .. 1.0, Delta=-25*Pi..25*Pi,
                     contours=[0.01,0.1,0.5,1,4,8,12,16,20], color=khaki,
                     labels=[Y,Delta,E1],
                     tickmarks=[3,3,3], grid=[551,551], view=0..20,
                     color=black, thickness=2, orientation=[180,0,-180]);

If you are still using Maple 13 (released in the year 2009) then remove the option size=[...] which I added only to try and make the offset a little better. I figured that you didn't want the text to cross the y-axis.

Download gk_text.mw

If I'm not mistaken then (to use your terminology) below I create functions Y(H,S,C) as opposed to Y(C,S,H).

First I use the fact that the data is regularly spaced (even if not evenly spaced) and call the Interpolation:-SplineInterpolation command added in Maple 2018. This produces a value of 0.897 for H=4, S=5, C=4.5 I think. And an animation of an interpolated surface seems to go from CPC level to level reasonably nicely.

Then I treat the data as if it were irregularly spaced, and call the Interpolation:-RadialBasisFunctionInterpolation and Interpolation:-Kriging commands, also added in Maple 2018. Results for H=4, S=5, C=4.5 are close to 0.89  and 0.9 respectively. But the animated interpolations (animated over CPC values) get a little goofy. I suspect that the dearth of data points might do them in.

Let me know if I've made a mistake.

Download law_ac.mw

It means e[1..-1, 2] which means all the rows (entries from row position -1 to 1) and column 2. 

The "-1" means the last entry, and is a handy way to program since you don't have to remember/use the total number of rows.

In 2D Input mode that indexed reference is typeset as subscripted.

Inside the Maple Help window there is an icon at the top of the displayed help-page, which allows you to toggle between 2D Input mode and 1D Maple Notation (plaintext, red code) for the input of the Examples. If you hover over the top icons you can tell which does which.

When toggled to 1D Maple Notation that subscripted reference in the input should appear as the plaintext red code containing e[1..-1, 2] .

If you have a 3x3 Matrix assigned to the name e, then e[1..3, 2] denotes the whole of the second column, and is equivalent to e[1..-1, 2] as well as e[.., 2] .

You can type it in as e[1..-1, 2] whether in 2D or 1D input mode.

If you would like to have the typeset 2D Input display in the subscripted forn then use the key-strokes   e Ctrl-Shift-underscore -1 . . 1 , 2 .  You can read more on the Help page for topic worksheet,documenting,2DMathShortcutKeys .

For the given example, since e has been assigned the Matrix of eigenvectors, then the second column is an eigenvector associated with the second eigenvalue v[2] (the second entry of the Vector v of eigenvalues).

I suspect that it is recognizing that point-release Maple 2018.2 is available, but the label in the popup is outdated.

Here's a 3D point-plot with the A[i] values used to determine a hue.

I rescaled so that the smallest A[i] gets red (hue value = 0.0), and the largest gets (roughly) magenta (hue value = 0.85).

But of course you can make any rescaling you want from the A[i] values into the 0.0 .. 1.0 range.

Download essai_ac.mw

The way in which the result is formatted for pretty-printed display as 2D Math output should be not be a primary concern for how the output expression will be handled in further computation.

For further computation, it is the structure that matters. The lprint command can provide a more accurate representation of the actual structure than does 2D typesetting/pretty-printing.

If both examples make sense in context, then as long as they are handled OK then why worry?

If you really prefer a form where both are displayed in the same manner then how about using D (either when inputting, or by using convert on the diff form)?

  D[1](u)(0,t) = A(t);

  D[1](u)(L,t) = A(t);

There were syntax mistakes in your piecewise construction.

Download waseem_test_ac.mw

Here are some ideas. (This site won't render it inline, as its backend Maplenet is old...)

student_md_question_2_ac.mw

Replace all instance in your code of lower with Lower, and all instances of upper with Upper.

There seems to be a problem with some procedure under Eigenvectors using the unquoted global name lower when invoking the Matrix constructior. (A bug, which I shall report.)

While you're making changes, you could also create your Matrix with the option shape=symmetric. Ie,
    M:=Matrix(2*n+1, shape=symmetric);
That way, if you ever decide to instead call Eigenvectors(evalf[15](M)) to get floating-point results there will be no zero imaginary components, ie. the results will be real floats.

The bug with the name lower only seems to affect the exact case, and Eigenvectors(evalf[15](M)) seems to not suffer from it. (We could probably find the offending line quickly in the debugger...)

[edited] I'll adjust my surmise about the precise cause. It goes wrong under LUDecomposition, but not because the option value contains the name lower unquoted, or in how it calls the Matrix constructor. Rather, it looks like a bug in the Matrix constructor itself. Eg,

restart;
lower := 1:

Matrix(2,'shape'='triangular'['lower']);
Error, (in Matrix) triangular[] storage expects name parameters

restart;

lower := 1:

interface(prettyprint=1):
trace(rtable):

Matrix(2, shape=triangular['lower']);
  execute rtable, args = triangular[lower], 1 .. 2, 1 .. 2, fill = 0,
  storage = triangular[1], subtype = Matrix
Error, (in Matrix) triangular[] storage expects name parameters

Matrix(2, shape=triangular['lower'], storage=triangular['lower']);
  execute rtable, args = triangular[lower], 1 .. 2, 1 .. 2, fill = 0,
  storage = triangular[lower], subtype = Matrix
                                   [0  0]
                                   [    ]
                                   [0  0]

There are internal routines of SolveTools:-Inequality , for linear systems, which are unprepared for arguments that contain relations which are a function of `<>`.

After such `<>` relations are generated internally, then as they get passed to such an internal procedure then that kind of error message attains.

I can reproduce the error message you've seen. (I edited the inequalities in your Question, and inserted a missing comma after what is now the first in your list.)

I did a cursory look through the related internal routines, and did not see any obvious reason why they shouldn't be able to handled `<>` present in their primary input. But I see one of two things which make me a little suspicious. If I simply change the parameter specification of those procedures to allow `<>` alongside the other kinds of relation in the input then I so obtain some result for your system.

It is not as quickly solved as the new system generated from the substitutions you suggested. I am unsure of the best way to try and verify whether the two answers (when re-expressed in the original variables, say) represent the same solution space.

Download ineqsystem.mw

If plots:-inequal is correct (especially in its lines) above then there may be some discrepencies in some part of the computed distinction between inequality and strict inequality. It might be better/necessary to have the altered routines convert all `<>` relations into alternate form, as their very first step.

A := unapply(eval(C(2,3),:-t=T),T):

A(0), A(0.5), A(0.3);

It would be less awkward if you did not have the unnecessary creation of Ld as an operator (using unapply) inside the procedure C., as well as not assign to Ld(t)[i]. I suspect that does not accomplish what you're expecting.

restart;
with(LinearAlgebra):
C:=proc(k,M) local N,P,m,L,T,j,Ld,n,i; 
N:=2^(k-1)*M:
P[0]:= t -> 1:
P[1]:= t -> t:
for m from 2 to M-1 do
   P[m]:= unapply(expand((2*m-1)*t*P[m-1](t)/m - (m-1)*P[m-2](t)/m), t)
end do: 
L:=proc(n,m) local a,b; 
  a := (2*n-2)/2^k; 
  b := 2*n/2^k; 
  return piecewise(a <= t and t <= b, P[m](2^k*t-2*n+1)*sqrt(((m+1)/2)*2^k))
end proc:
T := Vector(N):
for j from 1 to N do T[j] := (j-1/2)/N end do; 
Ld := Vector(N);
for n from 1 to 2^(k-1) do 
  for m from 0 to M-1 do
i := n+2^(k-1)*m:
Ld[i] := L(n,m)
     end do
end do:

return Ld:  
end proc:

A := unapply(C(2,3),t):
A(0), A(0.5), A(0.3);