@C_R When we're talking/writing casually of Maple programming, the words "function" and "procedure" are often used interchangeably. But when these words are used as keywords for types in Maple code, they are very different; indeed, they are disjoint. The f in your procedure header is declared function. This won't work. You can make that procedure or appliable (which is a supertype of procedure).

@Christopher2222 Reversing the order of the exponentiations (and, here, just using symbolic variables to emphasize the generality) we have

(x^r)^n = x^(r*n); simplify(%) assuming n::integer;

for any x and r and any integer n.

Your title "Cube root to the third...." states this reverse-order case. I think that you meant the title to be "Cube root of the third power doesn't simplify."

@NurinFYP No, it's not the same error message! The latest error is because you used beta[1] in the equations when you should've used beta__1.

All of your errors have been very simple errors that I could spot in seconds without even seeing your actual worksheet. I'm not saying that you should be able to spot them in seconds, but these trivial typos are not something worth giving up about.

@Jamie128 Surprisingly, I don't think that there's a simple way to get forget to forget everything (i.e., all "remember tables").

@NurinFYP You should change all the uppercase Zeta in your equations to lowercase zeta, or simply use another variable. 

@NurinFYP I think "global variables" is a bit of a misnomer. What it means here are "unassigned parameters"---variables representing fixed numbers whose numeric values haven't been assigned yet. They are allowed if you declare them with a parameters option. But in this case, I think it's just because of a typo. You assigned the value of ic4 where I think you meant ic3.

There is nothing special about forget that makes it unsuitable for use in a loop. Is there something from its help page that you're having trouble understanding?

You said that there are 3 nonzero entries per row. Is the matrix tridiagonal (i.e., A[i,j] <> 0 implies |i - j| <= 1)? Are there symbolic variables in the entries? If so, how many distinct variables are there? Do they occur only in rational functions (quotients of polynomials)? Are the numbers all rational numbers?

The Fortran program shown is stated to be a translation of an Algol program. Try to find that Algol program. Algol is much closer to Maple than C is.

To use FindTransitiveOrientation, set kernelopts(opaquemodules= false), then call GraphTheory:-FindTransitiveOrientation. You must use the module prefix GraphTheory:-, not the with command.

However, why not just call 

GraphTheory:-IsComparabilityGraph(..., transitiveorientation)

If the coefficients 10^5 and 10^7 are changed to "reasonable" values and the discretization mesh is enlarged with the maxmesh option (to, say, maxmesh= 2^15), then there doesn't seem to be a problem solving this. With the large coefficients, it's having trouble controlling the absolute error.

I don't know what exactly would be a good rescaling, but a starting point is perhaps defining CA2:= x-> s1*CA(s2*x) (I suggest on paper, at least at first, not in Maple), and finding values for s1 and s2 that work when the BVP is recast in terms of CA2(x).

(There is a way to get rid of the immediate "initial Newton iteration" error called a continuation parameter (see ?dsolve,numeric,bvp); but as soon as you do this, you'll get the absolute error control error message.)

It's not clear to me which of these two things you mean (and, understandably, you may not have realized that these two things were distinct possibilities):

1. You don't want to see displayed the functional dependence on t, but you want Maple to remain aware of it for computational purposes.
2. You want to change functional variables such as F(t) into simple scalar variables such as F.

@Prakash J I haven't checked this for your particular system, but I've numerically solved many very similar systems (typically boundary-layer problems from fluid dynamics). Using the default options, I'd expect convergence to 4 or possibly 5 significant digits for a1, etc. Getting more digits likely requires adjustment of several specialized dsolve options.

I just want to emphasize that @vv just mentioned evalf(convert(L, Sum)), not sum. The form Sum will guarantee that a numeric summation algorithm is used, not some other type of numeric algorithm.

@plouffe By using a decimal point, as you did in 4.0, you significantly reduce the likelihood that Maple will do anything useful with your expression.

If you use evalf(Sum(...)), then a numeric summation algorithm will be used, not a numeric algorithm for LerchPhi. If there is any bug here, it has nothing to do with sum but rather with numeric evaluation of LerchPhi.

You say that introducing decimal points "usually works". I strongly recommend against doing it. Perhaps it usually produces some numeric result, but they are often of dubious accuracy. The command to get numeric results (almost always of guaranteed accuracy) is evalf, not putting decimal points at random places in your expression.