@griffgruff Your statement is clear enough although I don't understand why you asssume that del(u) is normal to the boundary.

That would be the case only when the Dirichlet data is constant.  But you say that it isn't.  If so, then your del(u) is not normal to the boundary, and therefore you cannot calculate the vector n from it.

You need to give that some additional thought.

@griffgruff You say that u is a solution of a PDE and at the same time u represents the domain's boundary. That would be the case only if the boundary is a level curve of u, that is, u(x,y) is specified as a constant on the boundary.

@Kitonum You seem to have misiterpreted the question.  The vectors n and del(u) are unrelated.  The desired answer is  n(x,y)^+ . del_u(x,y), where

n := (x,y) -> < n1(x,y), n2(x,y) >;    # assuming n1*2 + n2^2 = 1
del_u := (x,y) -> < diff(u(x,y),x), diff(u(x,y), y) >;
 

@waseem

Do:

dsol := dsolve(ODEs);

to see what the general solution looks like.  Then you may apply any boundary conditions that you like.

@ivanfanthony You have four equations in the five unknowns, S(t), I(t), E(t), J(t), R(t).  You need to supply one more equation.

Additionally, the symbols I and gamma are reserved for internal use in Maple.  You should use some other symbols instead of those.

@ilpadrino As tomleslie has pointed out, you have a system of seven equations that involve nineteen symbols {b1, b2, ca, cb, cc, jmax, s1, s2, t, t1, t2, t3, t4, t5, t6, t7, tf, v1, v2}.  The best you can hope for is to solve for seven of those symbols.  You haven't said which seven.  Say it without a "..." in your statement.

@Christopher2222 In Maple's Tools menu go to:

Tools -> Options -> Interface

Inspect the item labled "Open worksheet at startup".  Select one of the three possible choices.  Probably you want the "New, blank" choice.

After selecting it, click on "Apply Globally" .

@tomleslie A link to his worksheet is at the very top of his original post.  It's called Пример02.mws.

This looks like a bug to me.  A workaround is to solve the PDE:

diff(u(x, y), x, x)+diff(u(x, y), y, y) = a,

and then substitute Pi for a.

PS: Actually Maple is able solve the more general case where the right-hand side is an arbitrary function f(x,y).

restart;
pde := diff(u(x, y),x,x) + diff(u(x,y),y,y) = f(x,y);
pdsol := pdsolve(pde, u(x,y), series, order = 4);
pdetest(pdsol, pde);

The test result in not zero but that's alright -- what we get is the difference between f(x,y) and its Taylor series expansion. That's what we expect when we are looking at a series solution.

@ecterrab

Dear Edgardo, I certainly did not mean to criticize or belittle your wonderful contributions to Maple in general, and to the pdsolve utility in particular. If I didn't like it, I wouldn't use it, would I?

It seems to me that the offense that I have caused is due to the use of the phrase "not reliable" in the discussion. Admittedly, that phrase when taken in isolation is both unkind and very untrue. But there is context—the question asked was whether one may rely on the uniqueness of solutions returned by pdsolve. My answer was that no, we may not rely on pdsolve for that since it does not return all possible solutions. That's a statement of fact, and I believe that you don't disagree with it.

At any rate, hereby I sincerely apologize to you for any unkind language that I may have used and any offense that I may have caused. Cheers!

@Mariusz Iwaniuk The solution returned by Wolfram is the unique solution of the problem under the two assumptions that we (a) seek solutions in the positive quadrant; and (b) want a solution that tends to zero as we approach infinity.

There are infinitely many solutions to that problem if we remove those assumptions.  For instance::
    u(x,t) = A*sin(c*x)*sinh(c*t)
is a solution for any A and c.

@ecterrab Thanks for your extensive input as usual.  I know that you are quite responsive to requests for software improvements and I truly appreciate that.

I must say, however, that ignoring the u=0 solution is rather odd.  In this particular case everything is out in the open and we plainly see that there is a zero solution even though Maple does not return it.  But in general this calculation could be a part of a large project where in some cases we have a nonzero solution and in some other cases we have a zero solution.  Treating the two cases differently just asks for unnecessary headache.

But the main point of what I was saying was that the homogeneous problem in my post has infinitely many solutions.  The fact that one of them is u=0 is immaterial.  Maple returns nothing.  That was a response to vv's  "I wonder whether the Maple solution is reliable as a unique solution".  The point of my example was to illustrate that no, we cannot tell whether the solution returned by pdsolve is unique, since pdsolve seems to drop solutions even if there are infinitely many of them.

As to your solution of the OP's problem, you wrote "For that, you need to have installed the latest Physics Updates".  I don't quite see why we need the Physics Updates for that since vv has already shown how to solve the problem without it.  Perhaps the latest Physics Update is already bundled in Maple 2018?

@vv Solving elliptic equations is new to Maple 2018.  It appears that some well-posed problems are now solved correctly, but I wouldn't trust everything that comes out of it.  Take, for instance:

restart;
pde := diff(u(x,y),x,x) + diff(u(x,y),y,y) = 0;
bc := u(x,0)=0, u(0,y)=0;
pdsolve({pde,bc});

Maple 2018 returns no solution while it is clear that there are infinitely many solutions.  In particular, u=0 is a solution!

PS: Corrected earlier typo where I had written u(x,t) for u(x,y).

@vv The problem seems to be (intentionally?) designed to mislead.  The choice of x and t as the independent variables gives the impression that this is a hyperbolic PDE / wave equation, while it is not.  Its leading term, -diff(u(x, t), t, t) - diff(u(x, t), x, x), is the Laplacian operator, and therefore the PDE is elliptic.  Normally one would write x and y for the independent variables in such a situation.

To obtain a well-posed problem for an elliptic PDE, one needs to specify a domain, typically a rectangle, such as 0 < x < 1 and 0 < y < 1, and then specify boundary conditions on all four sides.  In the statement of the current problem the upper range of t (that is, y) is unspecified.  Instead, a relationship is given between the values of u(x,1/2) and u(x,1) which is retrofitted precisely to agree with a targeted solution.  That is quite artificial; if we changed the terms in that relationship in the slightest way, the problem would cease to have a solution.

@das1404 The gap between the line segments is due to drawing the segments independently.  If you draw the broken line in one piece, the gap won't be there.  See if this works in Maple 7.

restart;
with(plots):
do_frame := proc(s)  # makes a single frame, 0 <= s <= 1.
  local U,L,R;
  U := pointplot([0,0],[0,1], connect);
  L := pointplot([[0,1],[-0.5-0.5*s,1.5-0.5*s],[-1,2]], connect);
  R := pointplot([[0,1],[0.5+0.5*s,1.5-0.5*s],[1,2]], connect);
  display([U,L,R], color=red, thickness=12):
end proc:
nframes:=40:  # of frames
display(seq(do_frame(k/nframes), k=0..nframes),
    insequence, axes=normal);