Differentiating eq1
and changing nothing else yields a complete solution:
eq1[Ne] = D[Simplify[H[Ne]^2 - 1/3*W[Ne]], Ne];
Scaled plots:
With[{funcs = {1, 10, 10^5} Through[{x, y, H}[t]]},
Plot[funcs /. First@sol1 // Evaluate, {t, 0, 3},
PlotLegends -> funcs]
]
What difference does it make?
If eq1
is an algebraic equation, then the system is a DAE and there only only one numerical integrator that NDSolve
can use, namely "IDA". Also the algebraic equation H[Ne]^2 - 1/3*W[Ne] == 0
must be satisfied. There seems to be a problem getting started, the mysterious error tests failure NDSolve::nderr
. If we remove AccuracyGoal -> 18
, which is probably unachievably high for this system, then integration starts but runs into an NDSolve::ndsz
error at Ne == 0.02772779893157676
. As Ne
approaches 0.02772779893157676
, H[Ne]
approaches 0
. Since H[Ne]
is determined by H[Ne]^2...
, two things happen: The positive and negative branches of the square root approach each other (which will the numerical solver choose, when they are very close?), and H[Ne]
begins to change rapidly ($\sqrt{u}$ has a vertical tangent at $u=0$). NDSolve
halts because it can't keep the estimated error low.
By differentiating eq1
, H[Ne]
is now determined by its derivative. The derivative still goes to infinity when H[Ne]
goes to zero, but somehow the stiff solver in LSODA handles it, with what it estimates is an acceptable amount of error. Note that mathematically, it is ambiguous what should happen at H[Ne] == 0
. Both the positive and negative square roots are valid solutions. In this case, it so happens that the numerical solver goes for the positive H[Ne]
, which may be pleasing if H[Ne]
represents a physical magnitude. One thing I did not investigate is whether H[Ne]
was actually approaching zero as a limit, or it just got close enough that the numerical solver "thought" it was. The computed values only get down to around 10^-8
(or 10^-11
if WorkingPrecision -> 24
). If it is supposed to cross zero every oscillation, then there is work to be done.