Hello pdsolve experts:  

Using Maple 2018.2.1 and Physics 292 on windows 10.

pde := diff(w(x,y),x)+ (arccot(x)^n *y^2 + y-  arccot(x)^n )*diff(w(x,y),y) = 0;
pdsolve(pde,w(x,y));

When I try

PDEtools:-charstrip(pde,w(x,y))

It does not generate error.

Should pdsolve have generated this error message instead of returning no solution?

Maple currently can't integrate things like sin(x)^n or cos(x)^n. These have antiderivative in terms of  hypergeometric functions.

Is there a technical reason why Maple at version 18 still can't integrate these? Will it be able to in next version?

int(cos(x)^k, x) 
int(sin(x)^k, x) 

fyi, These are the antiderivatives

Same problem for tan(x)^n....  I am asking because Maple is able to solve many ODE's but some results contains unevaluated integrals such as the above. 

When making this call to dsolve

restart;
ode:=diff(y(x),x)=1:
stopat(dsolve);
dsolve(ode,y(x));

Then in the debugger, I see that dsolve signature is

dsolve := proc(ODEs::{anything} := NULL, 
                {atomizenames::truefalse := true, build::truefalse := false, type::name := 'none'})

When typing print(ODEs) inside the debugger, it gives "diff(y(x),x)=1" which is correct.

But where is the second argument I passed to dsolve in the above call, which is "y(x)" gone?  I also do print(_nparams) inside the debugger and Maple returns 1 and not 2.

I expected to see 2 since I passed in two arguments to dsolve.

dsolve actually works without passing y(x), as follows

dsolve(ode);

And it seems Maple figure inside what is the dependent variable.

But my question is, is the second argument being thrown away before calling dsolve? If not, why it does not show in the debugger?   Is there some other pre-processing being done between the time the user calls dsolve() and the time the debugger is called?

I found a case where pdetest fails when called after another call to pdetest. I am using Physics version 272 from the clould. Using Maple 2018.2.1 on windows 10

restart;
u:='u';x:='x';t:='t';
pde := diff(u(x, t), t) + diff(u(x, t),x) =0;
sol:=pdsolve(pde,u(x,t));
pdetest(sol,pde);
    #0  OK
   
#restart;
u:='u';x:='x';t:='t';
pde:=diff(u(x,t),t)+diff(u(x,t),x)=0;
bc:=u(0,t)=0;
ic:=u(x,0)=sin(x);
sol:=pdsolve([pde,ic,bc],u(x,t)) assuming x>0;
pdetest(sol,pde);
   
     #sol := u(x, t) = -sin(-x+t)*Heaviside(-t+x)   #OK
     
     #-Dirac(-t+x)*sin(x)*cos(t)+Dirac(-t+x)*cos(x)*sin(t)+
      Dirac(-x+t)*sin(x)*cos(t)-Dirac(-x+t)*cos(x)*sin(t)   #WRONG should be 0
 

If I run the above again, but with restart call in between active, so that all is cleared, then pdetest gives 0 as expected on the second pde, with the same solution

restart;
u:='u';x:='x';t:='t';
pde := diff(u(x, t), t) + diff(u(x, t),x) =0;
sol:=pdsolve(pde,u(x,t));
pdetest(sol,pde);
   #0   #OK
   
restart;
u:='u';x:='x';t:='t';
pde:=diff(u(x,t),t)+diff(u(x,t),x)=0;
bc:=u(0,t)=0;
ic:=u(x,0)=sin(x);
sol:=pdsolve([pde,ic,bc],u(x,t)) assuming x>0;
pdetest(sol,pde);
   
   #0   #OK !! 

can any one explain why this happens?  Is this a bug? It seems like pdetest caching problem. it remembers something from the last call and this affects the result it gives for the next call.

any work around?

I thought in Maple the standard was to use _C1, and _C2, etc... for constants in the solutions returned.

Sometimes Maple mixes _C1 and c[2] in the same result. Is this common, to be expected sometimes and is OK? I noticed this only recently. 

I was thinking may be some part of Maple code still was not updated to use _C1 notation? Here is an example

restart;
pde:=diff(u(x,t),t)+ diff( u(x,t),x )^3 + 6 * u(x,t)* diff(u(x,t),x) = 0;
sol:=pdsolve(pde,u(x,t));

which gives

sol := u(x, t) = -(3/2)*_C1^2+3*(t*_c[2]+x)*_C1-(3/2)*(t*_c[2]+x)^2-(1/6)*_c[2]

With latest Physics updates  268