(ps. there is no Maple 2018 product to select, so I selected Maple 2017 from the menu).

The new UNTIL keyword added to Maple 2018 seems to me to be confusing and a useless addition to the Maple language.

First of all, using it in a DO loop, one does not use an closing END DO as normal. This makes it harder to use, since one is used to seeing an END DO to close each DO. They align physically better, which makes the code easier to read.

In addition, I can't think of anything that can't be done using current language constructs that needs this new keyword. Can someone? 

Adding a whole new keyword to make one type maybe few less characters seems like  a bad language design. A language constructs should be orthogonal to each others for the language to remain simple and clean. Adding more keywords for the fun of it should be avoided if something can be written using exisiting language constructs.

n := 37:
do
  n := n + 1
until isprime(n);
n;

very confusing to read. It has no end do. At first, I did not see where the loop ends. And the above can be done in many other ways allready, one direct way could be

n := 37:
do
  n := n + 1;
  if isprime(n) then
     break;
  fi;
od;
n;

And it is more clear as well since the DO is aligned with the END DO and I find the logic clearer with no new keyword added. Another way could be

n:= 37:
found_prime := false:
while not found_prime do
   n:= n + 1;
   found_prime := isprime(n);
od:
n;

I am sure there are other ways to do this.

Could someone please show an example where UNTIL is really needed and will make the code much more clear that justifies adding it to the language?

I am having trouble getting Maple 2017.3 with latest Physics update to give solution to Burger's PDE for viscous fluid flow with the following initial condition. May be I am not doing something right. I tried different HINTS, but no luck.

Maple can solve the PDE without the initial conditions.

May be a Maple expert can find work around or show what I might be doing wrong.

restart;
pde := diff(u(x, t), t) + u(x, t)*diff(u(x, t), x) = mu*diff(u(x,t),x$2);
ic  := u(x,0) = PIECEWISE([0,x>=0],[1,x<0]);
sol := pdsolve({pde,ic}, u(x, t)) assuming mu>0;

Maple returns () as solution.

This PDE can be solved analytically. Here is Mathematica' solution

ClearAll[u,x,y,mu]
pde = D[u[x,t],{t}]+u[x,t]*D[u[x,t],{x}]==mu*D[u[x,t],{x,2}];
ic  = u[x,0]==Piecewise[{{1,x<0},{0,x>=1}}];
sol = DSolve[{pde,ic},u[x,t],{x,t},Assumptions->mu>0]

This is on Maple 2017.3 under windows

After obtaining solution from pdsolve(), I tried to see if Maple can convert it to hyperbolic trig functions by calling `convert(sol,trigh)`. 

I waited and waited and nothing happened. Then clicked on the `interrupt current operation` button at top of menu. 

But I found that mserver.exe has hanged in a loop. Taking 100% CPU and still running. So Had to terminate it from task manager.

Question is: It is ok if Maple can't do the conversion, but why does it hang? Maybe if I want for one hr it will finish, I do not know. But the important part, why does `interrupt current operation` does not work, in the sense that the mserver.exe is still running?

Is this common thing to happen? Should this be fixed? 

Here is example

restart;
interface(showassumed=0);
pde:=diff(u(x,y),x$2)+diff(u(x,y),y$2)=0;
f:=x-> piecewise(x>0 and x<1/2, 2*x, x>1/2 and x<1, 2-2*x);
bc:=u(0,y)=0,u(1,y)=0,u(x,0)=f(x),u(x,2)=f(x);
sol:=pdsolve([pde,bc],u(x,y)) assuming x>0,y>0;

The above works OK and generates a solution. Now the next call hangs mserver.exe

convert(sol,trigh);

In case your Maple version can't solve the above PDE. Here is the solution obtained, so you can try this below without having to solve the PDE

sol := u(x, y) = Sum(8*sin((1/2)*n*Pi)*sin(Pi*x*n)*(exp(Pi*n*(3*y-2))-
         exp(Pi*n*(3*y-4))+exp(Pi*y*n)-exp(Pi*n*(y-2)))*exp(-2*Pi*n*(y-2))/(Pi^2*n^2*(exp(4*n*Pi)-1)),
            n = 0 .. infinity);
convert(sol,trigh);

I also tried convert(rhs(sol),trigh); but it made no difference.

I might be doing something wrong since I expected Maple to be able to solve this. Could some Maple manage to make Maple solve the following beam PDE problem taken from a textbook?

This is what I tried.

restart;
pde:=diff(u(x,t),t$2)+diff(u(x,t),x$4)=0;
bc:=u(0,t)=-12*t^2,u(1,t)=1-12*t^2,D[1,1](u)(0,t)=0,D[1,1](u)(1,t)=12;
ic:=u(x,0)=x^4,D[2](u)(x,0)=0;
sol:=pdsolve({pde,ic,bc},u(x,t));

But Maple returns no solution.

I am using Maple 2017.3 on windows.

I am trying to see if Maple can solve Laplace PDE inside the disk in polar coordinates. Standard textbook problem. Radius of disk is `a`. The boundary conditions on the disk is `f(theta)`. One of the conditions needed also is that the solution is finite in the center of the disk.

I do not know how to tell Maple that the solution should be finite in the center of the disk. If I do not give this conditions, Maple gives me strange looking solution, which does not look like anything close to the standard series solution one gets from hand solution. There is not even a series solution.

This is what I tried

restart;
pde:=diff(u(r,theta),r$2)+1/r*diff(u(r,theta),r)+1/r^2*diff(u(r,theta),theta$2)=0;
bc:=u(a,theta)=cos(theta);
sol:=pdsolve([pde,bc],u(r,theta)) assuming r<=a,r>0

Now, how to tell it that `u(0,theta)` is bounded? So that the `ln(r)` solution do not show up? Adding `u(0,theta)<infinity` to the boundary conditions, gives error

restart;
pde:=diff(u(r,theta),r$2)+1/r*diff(u(r,theta),r)+1/r^2*diff(u(r,theta),theta$2)=0;
bc:=u(a,theta)=cos(theta),u(0,theta)<infinity;
sol:=pdsolve([pde,bc],u(r,theta)) assuming r<=a,r>0

The standard solution to this PDE is

Where `c0` and `cn` and `kn` above are found from boundary conditions at $u(a,\theta)$.

How can one get Maple to give the above solution? How to tell it that $u$ is bounded at $r=0$?