@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.

@ianmccr The correct quotation marks are `$`, not '$'.

To approximately handle the situation "as x tends to infinity", set ub to a finite value such as 5. Then redo with ub=10 (for example). If the values of a1, a2, a3 do not change significantly, then you'll know that you're converging on the limit as x -> infinity.

After the values are extracted from the list, where would you like them to be put?

@nm You wrote:

• So having "export" on ModuleCopy in the child was the problem.

Yes, and it's mostly just a syntactic problem: Anything that's local or export in the parent is considered to be already declared in the child, including keyword procedure names like ModuleCopy.

• Then the child constructor (since it overwrote the base class constuctor method) has now to duplicate all this work. right?

Amazingly, no, it's not overwritten. On help page ?object,create, the 3rd paragraph of the subsection "Inheritance" is this extremely cryptic paragraph:

• Static members will be shared with the base class, or not, depending on the value they have in the base class. Static members whose value is a procedure or module with a ModuleApply function (methods) will be reinstantiated in the derived class. All other static members (i.e. data members) will be shared with the base class.

This is saying that when a procedure (or appliable module) is declared static in the parent and reassigned in the child, it is not overwritten; rather, the child gets its own static procedure distinct from the parent.

• It would be better if Maple OOP allowed child class constructor to call base class constructor directly as in Java and C++ and all other OOP languages.

The child is allowed to invoke the parent's copy of any redefined procedure by using the module-prefix (:-) syntax. According to the 7th paragraph from the same subsection:

• A method in a derived class that replaces an inherited method can invoke the base class' method by calling it explicitly. For example, a method M inherited by class T from class T0 but then reassigned in T, can call the original method using T0:-M().

I believe these 8 paragraphs are the only documentation of inheritance. It's shocking that the Examples section of this help page doesn't have any example of inheritance.

@vs140580 Your code looks fine, very close to what I would've done. I don't know enough to address your other questions regarding scaling at the moment. Don't "massage the data" too much trying to raise R^2.