@nm 
This is what I get running your worksheet just posted, after checking that there is no initialization whatsoever, nothing interfering (BTW have you tried running this in cmaple?) :

So I get the right, expected result, not an Error interruption. And the date is not July 25, though also not yesterday. That is puzzling. I will take a look at the related internals later today.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@yvnog 
This is a different question ... Have you tried opening Maple, and in an input line, enter > Physics:-Version(latest), press Enter, and wait for the package to get installed? If that doesn't work, would you mind please to take a screen shot so that we can see the message? Thanks.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi @Josecherukara 
Could you please upload a worksheet (use the Green arrow) with your attempt and where is that you don't know how to move forward?

Best!

I will take a look at this today.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

It means that your ODE, of third order, got reduced in order by one, and the resulting 2nd order linear ODE is not solvable with the current algorithms, but its solution can be represented with DESol, (equivalent to RootOf but for differential equations). So, since the order got reduced by one, you see an integration constant around, that appeared in the reduction process. @C_R 's explanation below is equivalent to this one.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Great everything. I will look at this one right away.

@acer 
Interesting observation, and indeed I goofed: if elision was working with standard typesetting in previous releases, there is a problem to fix; also related to the described "hangs when running wrapped by timelimit". I suppose I didn't notice either because of never using standard typesetting. Also because this was first reported as a bug in dsolve, it is not. Then as "the result of the computation is different depending on typesetting = standard or extended - it is not. All long descriptions. I only noticed the elision issue (worked in previous releases) after reading your succinct reply, @acer .

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@nm 
You say "So it looks also like the Length of output calculation is affected by typesetting level." That conclusion is wrong, as per what you see messaged on the screen: with typesetting = extended, the GUI just refrains from displaying such a large output (that is so large that it would steel valuable time just to be processed), while when you set typesetting = standard (which is not Maple's default), that intercept mechanism is not present. Note the output is always the same. This is about its display, not about the output.

Regarding the mechanism itself, it is a valuable one. There is no value in displaying a brutally huge expression of who-knows-how-many pages of length, so avoid that and save the time it takes to transform that in superb mathematical typesetting.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@vv, @nm, thank you both for alerting-about/investigating this. These bugs need to be fixed. Coding anything advanced requires looking at these issues as highly relevant. OK. In the meantime, use `ODEtools/radnormal`; I coded it 25+ years ago to workaround issues in radnormal when the computational flow goes into differential equation Maple territory.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.

It has never happened before that someone would send to dsolve a problem with initial or boundary conditions AND, in addition, indicated to dsolve the use of this or that method. The problem is of course correctly solved without you indicating the method dsolve should use. On the other hand, I can see (your post now) that it could happen, and the code is not testing for that, going out of the round when tackling the problem. I will fix that unusual situation and upload a fix in one of the next Maplesoft Physics Updates.

NOTE Jul/5: The use of methods when tackling ODE + IC/BC is now implemented and the problem resolved, as mentioned here.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi @hendriksdf5
Yes and No. Yes: that is one of the help pages; the help page for Physics:-Define is more detailed. No: I meant for you to open the Maple help pages themselves, not a website help page. So:

• Open Maple
• Input, literally: ?Physics,Tensors

where the ? makes the help page open. Likewise, input, literally: ?Physics:-Define and the help page for Define will open, directly in your computer, even if you don't have wifi.

Also, while computer algebra is great in general, taking advantage of it requires a quick look at the help page of every new command you use. The impression that we save time by skipping that step is false.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

I am unable to reproduce this 'hang', regardless of passing or not the argument arbitraryconstants=subscripted, and no matter the value indicated as timelimit. Also, arbitraryconstants=subscripted is already Maple's default, why are you passing that argument? 

I'd suggest you remove your maple.ini and try again to see if you still have a problem. 

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@vv, @acer
All valid points are yours, I think. Still @mmcdara also has a valid point, that I prefer: respect the choice of whoever posted, answer or comment, don't transform it, don't go with "I know better, my intention is good", or think it, but please do not act it, your good intention does not legitimate the action. If you feel there is imperfection (subjective), then let the imperfection be part. I've also seen some of my comments/answers transformed, with good intentions. Still, I'd have preferred to let me manage my own posts.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@nm
The isssue is order of precedence. In
map(((X -> odetest(X, ode)) assuming (0 < x, [sol])))
the left-hand side of assuming is (X -> odetest(X, ode)), while what you want is as @C_R indicated:
map(X -> (odetest(X, ode) assuming x > 0), [sol])
In short: the precedence of assuming is higher than that of the arrow operator ->. In situations like this, it is practical to input 
trace(`assuming`, statements = false) so that you see - for example - the order of precedence, and in general what is assuming receiving to its left.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.

@vv 
Although your observation was correct, odetesting lhs-rhs = 0 was succeeding, note that odetest does not expect any particular form of an implicit solution (the other statement of your answer). In this context of ODE solutions, implicit solution means that y(x) is not isolated on the left-hand side, only that. The problem was that in a nested sequence of conditionals, one branch was missing, handicapping the code - not the form of the solution.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft