I would do it as

diff(u1(x, y), x, x)+diff(u2(x, y), x, y);
convert(%, D);
eval(%, x=0);
f:=unapply(%, y);

           f := y -> D[1, 1](u1)(0, y) + D[1, 2](u2)(0, y)

f(0);
                D[1, 1](u1)(0, 0) + D[1, 2](u2)(0, 0)

@vv I take the following

c = -1
b = +3
a = RootOf(_Z^16-4*_Z^15+24*_Z^14-68*_Z^13+156*_Z^12-416*_Z^11-152*_Z^10
   -784*_Z^9-5096*_Z^8+1912*_Z^7-16976*_Z^6+8144*_Z^5-15492*_Z^4+368*_Z^3
   +10128*_Z^2-9152*_Z+10816,index = 1)^2 + 3; # ~ 3.68

@vv 

I think it is not quite correct to argue that all inputs can be assumed
to be [-1 ... +1] (by homogenity, yes?).

Let be T := (the given term). The following shows a solution for c=-1 beyond.

rng:=-10..10;
eval(T, c=-1);
plots[implicitplot](%, a=rng, b=rng);

That suggest

T;
eval(%, c=-1); eval(%, b=3); [solve(%, a)]; evalf(%);

  [3.68516285830513, (and 2 complex, conjugated roots)]

Now for the very Root:

RootOf(... ,index = 1)^2+3;
3 <% and %<4;
is(%);
                                 true

(of course it is true as soon as this Root is real)

@John Fredsted I wanted to say: changing the type should not change the ID - then it would not be a problem at all (besides the poor search functionality)

it would be no problem if the ID of the thread would not change (and the ID of this thread should be 220445 though it seems to be "220445-")

Changing to r=1/t the task is Int(abs(cos(r))/r^2, r = r0 .. infinity), r0=100.

Now split in zeros of cos:

Int(abs(cos(r))/r^2,r = 2*k*Pi + Pi/2 .. 2*(k+1)*Pi+Pi/2):
vk:=%=value(%) assuming k::posint; # in terms of Si

# test it because of the other formal bug
vk;
Split(lhs(%), 2*k*Pi+1/2*Pi + Pi)=rhs(%);

#eval(%, k=21);
eval(%, k= RandomTools:-Generate(integer(range=16..1024)) );

#evalf(%); # choose higher precision to care for cancellations
evalf(lhs(%)) = evalf[3*Digits](rhs(%)):
evalf(%);

# k0=16 is the minimal solution of 100 <= 2*k*Pi+1/2*Pi

# now put it together
Int(abs(cos(r))/r^2,r = r0 .. 2*k0*Pi+1/2*Pi)+
 Int(abs(cos(r))/r^2,r = 2*k0*Pi+1/2*Pi .. infinity);
op(1, %) +
  Sum( Int(abs(cos(r))/r^2, r = 2*k*Pi+1/2*Pi .. 2*(k+1)*Pi+1/2*Pi),
    k = k0 .. infinity);
eval(%, r0=100);
subs(vk, %);
eval(%, k0=16);
eval(%, Int=int); lprint(%);
evalf[60](%);

  1/100*cos(100)+Si(100)-Si(65/2*Pi)+
  Sum(-Si(2*k*Pi+1/2*Pi)-Si(2*k*Pi+5/2*Pi)+2*Si(3/2*Pi+2*k*Pi),
    k = 16 .. infinity)

   0.00638313654598387814274426438551485772230779517363432723710212

Using t=1/r, splitting and hybrid numerical/symbolical attack I get
V:= .638313654598387814274426437304e-2 with 30 decimals

For the integral over 0 .. 1 one has to add
W:= .480002239689338854199545656886

I think the original does not show a bug - though the result is false.

I first make a copy of the worksheet (through the file manager), then save the worksheet (if possible - can not always be done in classical interface). Then I kill the process *structure*  mserver. In case of doubts I take the one with high CPU usage (personally I have only one, mostly).

I looked at the example sheets (on the authors page). They contain some nice examples. And 200 pages is a well-sized introduction.

PS: Maple now wants money for explaining their SW through user guides / handbooks? As far I as I remember that was free in older versions ...

Then perhaps I would try to use "Rank" (not sure if you want solutions over Z, not over Q).

@umar khan Find a file attached, taking into account Carl's remark MP_220307.mws

How about convert(%, Matrix) ?

Maple 18.2 finds a Sum, which it can evaluate numerically. Neat.

220095_Maple18.pdf

Splitting in Pi/2 (to support the integrator) results in an alternating "decreasing" sequence, summation error "is" the first term after cut off.

The overall result is ~ 0.44, so the error has to be roughly 1E-16. That is achieved at k ~ 10^7 for the integral over k*Pi+Pi/2 ... k*Pi+Pi, both by numerical integration or a symbolic solution.

@Christopher2222 Ok, I understand now. And, no, I can locate it