@aoakindele Sorry, but I don't know how to overcome the "matrix is singular" error from the BVP solver. My guess is that this is not caused by an input error on your part; rather, it's something inherent to the problem.

@aoakindele The total differential order (essentially, the sum of the orders of the highest-ordered derivatives of each dependent variable) of your system of ODEs is clearly 5. The number of boundary conditions must be equal to the total differential order PLUS the number of parameters that have NOT been given numeric values. You have tried to add a new boundary condition to the originally posted system:

(1+epsilon)*(D@@(F))(inf)=gamma*theta(inf)

(Note that this still contains the error that I just told you how to correct!) In order to add a new boundary condition, you need to do one of

• remove one old boundary condition,
• remove the numeric value from one parameter,
• add one new parameter.

This is a mathematically necessary limitation; it's not a limitation imposed by Maple.

@aoakindele The 2nd derivative of F at inf can be denoted (D@@2)(F)(inf).

@nm I think that you're failing to understand the contrasted logical terms necessary and sufficient. I am not trying to tell you a method that will prevent the cancellation (in other words, is sufficient to prevent the cancellation); I don't know how to prevent it. What I'm trying to tell you is that it would be impossible for there to be any cancellation-preventing method in Maple that used -(s - 1)/((-2 + s)*(s - 1)) as part of its input (in other words, it is necessary that the factored denominator not be used) because such an expression doesn't really exist in Maple. The common factor is immediately cancelled from the user input, and it's not recoverable. Likewise, the fraction 2/4 cannot exist in Maple.

@ecterrab You wrote:

• The problem with mathit is that it removes blank spaces, while in Maple, it is valid to have "symbols" with blank spaces.

Why should the Latex be crippled in order to conform with valid Maple syntax? Shouldn't the goal be to produce valid mathematical typesetting? To my mind, symbols with spaces are not valid mathematical typesetting. Thus, I wouldn't mind if the Latex command rejected them completely (with an appropriate error message).

@nm To avoid cancellation it is necessary (but, apparently, not sufficient) that the denominator be expanded. If it's not, then the cancellation will happen before the argument is passed and regardless of whether quotes are used. This is called automatic simplification, and I thought that it was what you were referring to (because you mentioned the quotes). So whatever additional steps that you need to take to prevent the cancellation, you'll still need to expand the denominator.

Never mind responding. I just figured out why dsolve didn't catch it.

@acer Please see the comment that I just posted (with the same title) to Tom's Answer. The exact same thing applies here. The primary reason that I mention it is that I don't understand how it's possible that dsolve didn't catch this. 

@tomleslie

Tom, your version of the ODEs contains an error carried over from the OP's code: In the last line, F is used as a coefficient rather than as a function. 

@aoakindele Please don't waste my time (and it takes much longer to write these posts on my phone) by posting worksheets that still contain errors that I just told you how to correct. The worksheet above still contains the Pr and alpha errors.

By focusing on the explicit error messages, one often ignores the true errors, which often don't produce error messages. 

@aoakindele 

Please read the extensive additions that I just made to my Answer above.

I have no Internet connection right now, and I'm posting from my phone. That means that I can't view the worksheet that you just posted. If you post it inline (i.e., explicitly displayed), I'll likely be able to answer your question. 

@pik1432

ToInert(expr) might give the expression transversal that you're looking for, although I usually find it to be excessively detailed, and I wish that one could selectively expand just the subparts that one was interested in. And beginning every operator's name with the 7 characters _Inert_ makes it hard to read and is so unnecessary.

A more readable (but not programmatically friendly) alternative is dismantle(expr). However, this is an older command, and some of its information is out of date. 

The commands addressof and disassemble do allow for selective expansion of subparts, but all the information is numeric: memory addresses and expression-type key numbers (called dagtags).

@fatemeh1090 All I did was make a numeric comparison (evalf) of the two sides of the equation for a few points u and nu using 1000 instead of infinity as the upper limit of summation. 

I do not know the mathematics needed to answer your other questions. 

I don't have Internet access at the moment. I'm posting this from my phone, which of course doesn't have Maple.

@mmcdara The difference is just an issue of the design; it doesn't have any mathematical significance. If the first argument to solve is in a set or list, then the returned results (if any) include the variable(s). If there's only a single item being solved, and it isn't in a set or list, then the solution is returned without the variable. This capriciousness is quite a nuisance. Compare:

solve(x-1);
solve({x-1});

It seems that the real parts of both sides of the red-boxed equation match (for real nu and u), but the right side has a huge imaginary component also. This may be due to a difference in the way the Legendre functions are defined in Maple and in your source reference; I don't know. It appears to me that the I*Pi/2*LegendreP(n - 1/2, cosh(nu)) contributes only to the imaginary component. Perhaps you should get rid of it.

For nu=1, u=1, I get an imaginary component approximately 10^435.