Maple does not have yet very good tools for this kind of manipulations. Some steps towards the desired form may be:

eq2:=8*(-(-If*(q*ks^4/If^(1/2))^(3/5)+Tcr*Delta*Ds*ks^3)/Delta/Ds/ks^3)^(3/2) = qs/(Delta*GRAVIT*Ds^3)^(1/2);
assume(If>0,ks>0,q>0,Tcr>0,Delta>0,Ds>0,qs>0,GRAVIT>0);;
use RealDomain in solve(eq2,If) end use:
p:=%;
s:=op(indets(p,`+`)):
subs(s=u,p);
simplify(%) assuming u>0;
If=subs(u=s,%);
map(x->x^(7/10),%);
simplify(%);


    (7/10)
  If       =

                 (1/3)             (1/3)     (2/3)       2/3   3/5
        (4 GRAVIT      Tcr Ds Delta      + qs     ) Delta    ks
        ----------------------------------------------------------
                                     1/3  3/5
                             4 GRAVIT    q

 

A first guess about it. In my choice f1(t)=exp(-t) [there was a typo above], the rhs tends fast to 0, so it approches to your choice f1(t)=0. Then, for f1(t)=0, the Abel eq. for r(t)

d2 := (r(t)+1/3)*diff(r(t),t)+r(t)^2-4/3*r(t)-5/9 = 4*f1(t)/exp(t);

admits two constant solutions, the roots of a quadratic:

eval(d2,[diff=0,f1=0]);
solve(%,r(t));

                          2
                      r(t)  - 4/3 r(t) - 5/9 = 0

                              5/3, -1/3

So, the issue is that the solution for the Abel eq. for r(t) and a root of the cubic for r(t) are close to 5/3 for these examples when t is large enough. But there is a disagreement where r'(t)<>0 (ie near the initial point). So, something is wrong with the solution in the cubic. May be a typo or an error in the calculations. I have not checked them yet.

PS. Asymptotically, for t-> infinity, this root 5/3 of the quadratic is a root of the cubic. Using the definitions of above:

eqs:=subs(r(t)=5/3,p(t)=pt,q(t)=qt,f1(t)=0,eq);
                                                2
  eqs := 1/2 ((t sin(t) + cos(t)) Ci(t) + cos(t) )

                                    2   /   3      3
        (4 t Ci(t) + cos(t)) exp(-t)   /  (t  Ci(t) )
                                      /

series(eqs,t=infinity,2);
                                O(1)
                               -------
                                     2
                               exp(t)

It is a real pain! Moreover as the help system of Maple 12 Classic is broken. Look at this thread.

I would do this way:

with(PDEtools):
with(codegen,fortran):
with(CodeGeneration,Fortran):
alias(Q = Q(x, y, t), H = H(x, y, t), S = S(x,y,t) , B = B(x, y, t)):
declare(Q(x, y, t), H(x, y, t), S(x,y,t), B(x, y,t)): 
interface(showassumed=0);
qs:=aa/(1-p)*abs(Q)^mm/(H-B)^mm*abs(1,Q);
diff(H, t) = -(diff(Q, x))-diff(qs,x) assuming Q::real,Q<>0;

H[t] = -Q[x]-aa/(1-p)*abs(Q)^mm*mm*signum(Q)^2*Q[x]/abs(Q)/((H-B)^mm)+aa/(1-p)*abs(Q)^mm/((H-B)^mm)*signum(Q)*mm*(H[x]-B[x])/(H-B);

I would do this way:

with(PDEtools):
with(codegen,fortran):
with(CodeGeneration,Fortran):
alias(Q = Q(x, y, t), H = H(x, y, t), S = S(x,y,t) , B = B(x, y, t)):
declare(Q(x, y, t), H(x, y, t), S(x,y,t), B(x, y,t)): 
interface(showassumed=0);
qs:=aa/(1-p)*abs(Q)^mm/(H-B)^mm*abs(1,Q);
diff(H, t) = -(diff(Q, x))-diff(qs,x) assuming Q::real,Q<>0;

H[t] = -Q[x]-aa/(1-p)*abs(Q)^mm*mm*signum(Q)^2*Q[x]/abs(Q)/((H-B)^mm)+aa/(1-p)*abs(Q)^mm/((H-B)^mm)*signum(Q)*mm*(H[x]-B[x])/(H-B);

seems correct about the tutor (it was not about Maple). For me it describes a problem with the design of the tutor.

seems correct about the tutor (it was not about Maple). For me it describes a problem with the design of the tutor.

I mean for symbolics and properties (eg at the end of  this article the numeric version is mentioned as distinct). I believe that following more faithfully the Mathematics cannot be the wrong way. If improvements are no longer made because of fear, the future of the system is short.

Yes, it would be much nicer. Sadly, 'userinfo' seems to be used at discretion of the developer: some parts of the system are much more verbose than others. Here also, a better standard is needed.

Yes, it would be much nicer. Sadly, 'userinfo' seems to be used at discretion of the developer: some parts of the system are much more verbose than others. Here also, a better standard is needed.

You can do this:

with(IntegrationTools):
V := Int(exp(x)*sin(x), x);

                             /
                            |
                      V :=  |  exp(x) sin(x) dx
                            |
                           /
trace(IntegrationTools:-Parts):Parts(V, sin(x));
{--> enter IntegrationTools:-Parts, args = Int(exp(x)*sin(x),x), sin(x)

                          f := exp(x) sin(x)


                                x := x


                                w :=


                             dv := exp(x)


                             v := exp(x)


                             du := cos(x)

<-- exit IntegrationTools:-Parts (now at top level) = exp(x)*sin(x)-Int(exp(x)*cos(x),x)}

                                   /
                                  |
                 exp(x) sin(x) -  |  exp(x) cos(x) dx
                                  |
                                 /

You can do this:

with(IntegrationTools):
V := Int(exp(x)*sin(x), x);

                             /
                            |
                      V :=  |  exp(x) sin(x) dx
                            |
                           /
trace(IntegrationTools:-Parts):Parts(V, sin(x));
{--> enter IntegrationTools:-Parts, args = Int(exp(x)*sin(x),x), sin(x)

                          f := exp(x) sin(x)


                                x := x


                                w :=


                             dv := exp(x)


                             v := exp(x)


                             du := cos(x)

<-- exit IntegrationTools:-Parts (now at top level) = exp(x)*sin(x)-Int(exp(x)*cos(x),x)}

                                   /
                                  |
                 exp(x) sin(x) -  |  exp(x) cos(x) dx
                                  |
                                 /

I think that a new property, 'extended_real' say,  should be added to the property lattice, equivalent to:

OrProp(real,-infinity,infinity);

 which corresponds to what is described here.

ie the issue here, is programmed, hence within reach.

the intersection ('AndProp') of properties 'real' and 'infinity' should be "empty", ie 'BottomProp', but:

AndProp(real,infinity);
                       AndProp(real, infinity)