Carl: Ah yes, I was inattentive to the "otherwise" clause of the defintion.  Now the double-summation makes sense to me. 

I can't make sense of the math as it is presented.

To explain my confusion, let's forget about your problem for a moment.  Let's consider a real-valued function f defined on the interval [0,1] and another real-valued function g defined on the interval [5,6].  Question: What does the sum f(t) + g(t) mean?  Answer: The sum is meaningless—it makes no sense to add functions defined on different domains.

Now, going back to your problem, your functions b[n,m](t) are defined on generally non-overlapping subintervals, which leads to the question: What do you mean by that double-sum formula in your post?

To help others to help you, upload your worksheet.  Use the big green up-arrow that shows up in the window in which you type your response.

Since you have the result for one of the v values, what is preventing you from doing it for the other v values?

Consider uploading your worksheet so that people can see what you have done and what remains to be done.  To upload a worksheet, use the big green up-arrow that shows up in the window in which you type your response.

@I_Mariusz Your reaction is somewhat like saying a BMW coupe is not a powerful automobile because it can't do the job of a tank in a battlefiled.  Well, it can't, but that's not a good way to judge its usefulness.

@I_Mariusz Your equations are correct now, but unfortunately Maple is unable to solve them.

I haven't used Maple's PDE solvers at all, so I dug into the doucmentation to understand the cause.  So far as I was able to learn, Maple's numeric PDE solvers are not designed to solve elliptic PDEs.  Looking into MaplePrimes archives I found a few other requests for elliptic PDE solvers, and the respondants said that no such thing exists.

So I don't have a useful suggestion for you.  If I had to solve your problem, I would try one of the following:

1. Your domain is a rectangle, therefore implementing a finite difference scheme for a numerical solution should not be hard.
2. If I had more time and motivation, I would write a finite element scheme to solve the problem.
3. If I needed a solution immediately, I would use Comsol Multiphysics, but this would not be a useful option for you if you don't have access to Comsol.

@Ken_obi The title area is for the title of a message.  What you say should go in the body of the message, not in the title.

In particular, putting a link in the title doesn't do what you expect.

I don't understand the part that begins with "I differentiate the above equation ...".  You differentiate with respect to what?  And what does that have to do with a table?

@Markiyan Hirnyk Thanks for the link.  O'Rourke's theorem (page 126 in your referenced PDF) says that we need no more than floor( (n + 2h))/3 ) cameras, where n is the number of the vertices (counting vertices on the outer walls as well as on the holes) and h is the number of holes.

In the current problem we have 8 vertices on the outer walls and 4 vertices on the pollar, therefore n = 12.  We have one hole, therefore h = 1.  Then according to O'Rourke's theorem, the upper bound on the number of cameras is floor(14/3) = 4.  The solution that I posted earler, shows that 3 cameras will do, that is, the theorem's upper bound is an overestimate in this case.

@Markiyan Hirnyk Yes, I have.  I didn't see anything there pertaining to non-simple polygons.  Did you?

@vv The art gallery problem and the associated theorem by Chvatal/Fisk pertain to simple polygons, that is, polygons with no holes.  The "gallery" in the question asked here is not a simple polygon due to the pillar in the center.  There may exist extentions of the Chvatal/Fisk theorem to non-simple polygons but that is beyond my realm of knowledge.

@Markiyan Hirnyk That's quite curious and makes me wonder about the nature of this bug.  Your workaround is excellent when it works, but has its limitations.  The following still causes problems:

plots:-shadebetween(1/sqrt(1-x^2), 1/sqrt(1-x^3), x = 0 .. (1/2)*sqrt(3));

Two of the methods suggested on this page work and produce the correct result in this case:

1. The method suggested by acer
2. The method of "faking it" suggested by me, that is
   plots:-shadebetween(1/sqrt(1.0001-x^2), 1/sqrt(1.0001-x^3), x = 0 .. (1/2)*sqrt(3));
   
   

@DJJerome1976 Two ways to report bugs:

Method #1: Send mail to Support@maplesoft.com

Method #2: Look up the drop-down menu labeled "More" near the top of this page.  Within that menu select "Submit Software Change Request".

@darkspin1 I assume that when you wrote

v_1'(0)=v_2'(0)=v_1'(1)=v_2'(1)

you really meant

v_1'(0)=v_2'(0)=v_1'(1)=v_2'(1)=0.

Anyway, is there a reason that you insist on a discontinuous solution?  Your problem has a perfectly fine continuous solution where v1, v2, and u are constants:

 u = B/(1+j*B),

v1 = B/(1+j*B),

v2 = 1/(1+j*B).

@darkspin1 You have

f(u) = u+1 for u < 0 and u-1 for u>0

and

-v + j*u + f(u) = 0,

that is,

j*u + f(u) = v.

You claim that we can solve this equation for u in terms of v.  That is not correct.  If you plot the graph of v =  j*u + f(u) versus u, you will see that any horizontal line v = c  with -1 < c < +1 intersects the graph in two points.   Therefore there is no unique u corresponding to such a v.

I have not examined the rest of your problem, but the point noted above can explain why your solution is not what you expect it to be.