@sursumCorda 
I found an exception from your golden ratio discovery that works as expected

solve(0 <= ln(a/2) + ln(1 + a));

In this case also an additional relation between 0 and 1 does not change the result (as in my last reply to dharr).

solve({0 <= ln(a/2) + ln(1 + a),a>1/2});

So these things seem to come together.

@Joe Riel 

Thank you for the workaround but for what reason warnings disapear (in case of varphi without t)?

Is it a (new?) mechanism that Maple does not issue the same warnings after two times?

Just for your information: Here are related posts where I was more concerned to make warnings apear:

https://www.mapleprimes.com/questions/235722-Why-A-Restart-Is-Needed-To-Get-A-Helpfull

https://www.mapleprimes.com/questions/235770-Why-No-Warning-Is-Returned-With-2D-Input

@dharr Interesting findings!

The logarithmic substitutions for the original statement with ln

solve({a > 0, ln(a) + ln(1 + a) >= 0}, a);

lead to the statement you have given that the semi-algebraic solver solves successfully (and correct IMO).

solve({a>0,a*(a+1)>=1},a);

For me it looks like that the output is not assembled correctly (i.e. < and <= are treated the same way).

Here is another output that looks incorrectly combined in an OR fashion instead of AND

solve({0 <= ln(a) + ln(1 + a), 1 <= a}, a)

 With -1<a we are back to

@sursumCorda

To your question: "But there is no warning message. Why?"

In an other instances warnings on lost solutions are passed to the user (see my reply to mmcdara).

The output of inequal plot looks old. Maybe it bypasses a newer mechansim to handle warnings to the user.

It could be that in your case the warning is suppressed by an "output handler" and not by solve.

However, I still can't see why the solution a = 2/(sqrt(5) + 1) should be treated as a separate solution. For different input the boundary of a domain is included in soluitons with a <=. In my opinion, it appears that solve could be enhanced in this particular case.

@mmcdara your code pasted in 2D

Lost_boundary.mw

@rcorless 

Maybe of interest: Maple can now analytically verify that this is a solution.

I did not know that there is an explict solution appart from a series approach. Does the "magnificent book" give details how that explicit solution can be derived? I would like to understand if and how such a derivation can be reprocuded with Maple.

Reply_HarmonicOscillator-1.mw

@sursumCorda 

The effective use of the empty symbol surprised me. I thought `` makes expression "inert" to simplification. Now a see the opposite: convert/D fully evaluates 

Do you have any explanations (or documentation beyond help(emptysymbol)) for this?

@Carl Love 

Retrospectively I can see it now.

@acer 

Thank you for taking the time to describe this detail of returning an unevaluated eval call in an easy to understand way.

I did assume that the inert functions where returned unevaluated by convert(…, D).

I have attached all possible combinations of defining IC/BCs in common math output notation (i.e., understandable also for non-Maple users) with relevant commands. Maybe it's better practice to define an IC/BC with eval(Diff…) instead of Eval(diff…), which makes convert(...,D) work without eval.  Let's see.

By the way, your foo example is a good addition to eval, Eval, D and more. Evaluating something at a point that is not returned  in a  fully evaluated representation but can (only?) be displayed with eval(...,1) which outputs the internal representation touches essential aspects of Maple worth understanding.

Download Convert_inert_IC_to_D_notation_in_various_combinations.mw

@mmcdara 

Better rendering.

Your code does not return "domains" in the same way with Maple 2023. I cannot make sense of Maples output in both cases.

Replacing < by = combined with allsolutions gives a reasonable expression for the subdomain ranges.

Domains-2_M2023.mw

Yours:

With 2023 nothing is returned for f(1)

@sursumCorda 

Finally I found something which is, combined with your DETools commands, an acceptable way.

Thanks again

Download 236511-How-To-Integrate-This-Ode-And-How-To-1_reply_2.mws

I think you meant: ...the term I * Int(f(x), x).

This one works:

I*Int(f(x), x) = something - 2*I*Int(f(x), x);
isolate(%,Int(f(x), x))

@Rouben Rostamian  

I understand that there is no such solution. I am looking more for Maple techniques that provide “elegant” solutions. What I could achieve did not match my expectations (especially my failed substitution attempts). In this respect you have given a good example for the first integration step: Exclusive use of equations and high-level commands.

I had the hope that there could be a forward integration step (using only de and bc) coming to the same result as with your solution (maybe with a clever combination of DETools commands or the Physic package).

(The backward step you have taken in combination with a dsolve command that preserves the integration variable and removes the second integration constant is something I have to think about. This could become handy on other occasions.)

I have spared out the second integrations step which is of topic of my questions Q1 and Q2 and has to be approached differently for the pendulum and the elastic beam since the first one is an initial value problem whereas the other is a boundary value problem. I hope I can find a satisfying solution myself.

Thank you for providing the best way for Q1 and Q2 in one go so far!

@Rouben Rostamian  

As I haven't found a solution to this ODE using top-level Maple commands, my objective is to replicate the steps outlined in a publication that solves this ODE manually. I have outlined my random path of experiments in the attached reply.

Your way is smart since it avoids manual substitution of a boundary condition at all and prevents the dead ends one is confronted with when a solution returned from Mapel can’t be differentiated with respect to the independent variable (like Student:-ODEs:-ODESteps({bc, de})). So, thumbs up for that, but how could I have figured that out myself? Is this really the "best" way in the sense of good ode solving practise to avoid manual or "terrible" ways?

I have to admit this ode and its sibling has attracked my attention beyond practical need. First of all, there is everyday physics behind everyone knows: bending of elastic beams and the pendulum.  Secondly, as I have realized in the meantime, the second integration step can’t be formulated in terms of boundary conditions or initial conditions Maple accepts.

Maplesoft has done quite some efforts of providing education material and packages. It's good and I myself have learned allot. I can’t judge if these odes are of value form an educational standpoint. However, I wanted to highlight some problems (in particular defineing and handling ICs and BCs) and related questions a student may encounter. This is kind of a secondary objective.

Download mw-1_reply.mw

@sursumCorda 
I think your way to Q1 with 2 out of more than 130 (!) DETools commands is not terrible. The missing bit for me when I got this Error

was that I can potenially make an ODE exact by multiplying it with an integration factor. If this is the only way, Student:-ODEs:-Integrate could have added a hint.
Also: Strange that the examples of ?DEtools,firint sometime come with _C1 and c__1.

Even if "terrible": Why does this comes as an exponent?Edit: fount the explanation

Let's see if there are less terrible ways.

Thank you