Update: I thought I would check this out in V10.1. I found no difference in DSolve
, but I was able to an answer relatively quickly (compare with my original attempt). It's in a different form than the original, but it's equivalent.
Using the same substitution as Chip Hurst in his Apr 22 answer, and after some coaxing, I got to this solution:
testk = 0 == -16 c m^2 Cos[x] k[x] - c (-7 Sin[x] + Sin[3 x]) k'[x] +
Cos[x] Sin[x]^2 (m^2 (3 + 4 m Cos[x] + Cos[2 x]) Tan[x/2]^(2 m) +
4 c k''[x]);
ode = testk /. x -> x[u] /.
First@Solve[{h'[u] == D[k[x[u]], u],
h''[u] == D[k[x[u]], u, u]}, {k'[x[u]], k''[x[u]]}] /.
k[x[u]] -> h[u] /. x -> ArcCos /.
Tan[ArcCos[u]/2]^a_ :> ((1 - u)/(1 + u))^(a/2) // FullSimplify;
solu = DSolve[ode, h, u];
Assuming[m ∈ Integers && m >= 0,
fubar = Simplify[h[Cos[x]] /. First@solu] /.
Exp[A__*ArcTanh[Cos[x]]] :>
Simplify[ExpToTrig[Simplify[TrigToExp[E^(A ArcTanh[Cos[x]])]]]] //
Simplify
];
solx = Function @@ {x, fubar}
(*
Function[x, (1/(8 c m (-1 + 4 m^2))) *
(m^3 (-((-1 + Cos[x])^2/(1 + Cos[x])))^m *
(1 + 4 m^2 + 4 m Cos[x] + (-1 + 4 m^2) Cos[2 x]) +
4 c (-1 + Cos[x])^m *
((-1 + 4 m^2) C[1] - m C[2] + 2 m ((-1 + 4 m^2) C[1] + m C[2]) Cos[x]) *
Cosh[m (Log[1 + Cos[x]] - Log[2 Sin[x/2]^2])] -
4 c (-1 + Cos[x])^m *
((-1 + 4 m^2) * C[1] + m C[2] + 2 m ((-1 + 4 m^2) C[1] - m C[2]) Cos[x]) *
Sinh[m (Log[1 + Cos[x]] - Log[2 Sin[x/2]^2])])]
*)
Check:
Assuming[m ∈ Integers,
testk /. k -> solx // FullSimplify
]
(* True *)
Original solution found
For what it's worth, using the same substitution as Chip Hurst in his Apr 22 answer, and after some coaxing, I originally got to this solution:
solx = Function[x,
1/(4 Sqrt[
m^2]) (2 C[1] (1 + 2 Sqrt[m^2] Cos[x]) Cot[x/2]^(-2 Sqrt[m^2]) - (
2 C[2] (Sqrt[m^2] - 2 m^2 Cos[x]) Cot[x/2]^(2 Sqrt[m^2]))/(-1 +
4 m^2) + ((m^2)^(
3/2) (1 + 2 m Cos[x] + (-1 + 4 m^2) Cos[x]^2) Tan[x/2]^(2 m))/(
c (-1 + 4 m^2)))]
Unfortunately, crashes, trying different things, memory leaks or something messing up Simplify
and FullSimplify
or other confusing behavior, plus stupidly copying and saving the wrong step means there is one step missing in the path to the solution.
Check:
testk /. k -> solx // Simplify
(* True *)
[It is arguably a simpler solution, but I did not discover a way to transform the new solution to this one.]
One of the problems is that applying the assumption that m
is an integer causes different things to happen under the hood in simplification. But some simplifications are valid whether m
is an integer or not. The following example shows that an early application of the assumption slows things down quite a bit. Simplifications are usually done under time constraints, which may lead to failure.
ode /. First@solu //
Simplify[#, m ∈ Integers && u ∈ Reals] & // AbsoluteTiming
(* {17.843582, True} *)
ode /. First@solu // Simplify //
Simplify[#, m ∈ Integers && u ∈ Reals] & // AbsoluteTiming
(* {7.273103, True} *)
It is a sheer guess that this has something to do with the problem.
DSolve
use$Assumptions
(Simplify
,Refine
,Integrate
etc.), but otherwise I don't thinkDSolve
uses it. I thinkDSolve
gets stuck trying to figure out how to reduce the problem to integrals. $\endgroup$