Since then we have had

Maple 13
Maple 14
Maple 15
Maple 16
Maple 17
Maple 18
Maple 2015
Maple 2016

Maplesoft seems to do one major release per year (although I wouldn't want to bet on this being precise). So your release is about 8 years old. Providing help for people running seriously old versions is always problematic. Personally, I only have the last four Maple releases (17, 18, 2015, 2016) running on my machine. Maybe you assume that respondents here have every Maple version since the dawn of time immediately available - but this isn't true

If you have any future queries, it would be helpful if you would indicate that you are running a very old version

My original worksheet is incorrect - not sure what I was thinking of??

Attached now seems to give the "correct" answers and since it uses spherical polars whenever integrals are required, I guess I can say that it contains two further methods of obtaining the same solution(s) as you have obtained

BTW when the OP asked for "the surface integral)", my original worksheet (and the attached) assumed that what was required was the simple surface area. On reflection, even the latter is ambiguous. Does it include the area of the two 'flat' end-of-cylinder regions? Or is it the surface area of a sphere with sections removed at top and bottom. The attached assumes (as did my original) the former: if the latter then just add 2*Pi*r__cyl^2 to the answer obtained

sphTrunc2.mw

Added the equation of the the circumcircle as an output to my original worksheet - see attached

funWithTriangles2.mw

I'm seeing this on Maple 2016 - so this problem has been around through many versions

One thing I discovered by accident is that if you resize the Maple window so that the interrupt icon on the toolbar has to be redrawn, then the color of interrupt icon will go back to red. You can then click it again, and repeat the whole process to absolutely no effect whatsoever!

Your response just shows that you did not even read my original reply. So I will try again - just once. If you can't be bothered to read this and respond sensibly, don't expect to hear from me again.

1. Using a midpoint method avoids the issue of the singularity at the start point, as I stated in my original response.
2. However, as I also stated in my original response, even when using a midpoint method, your system generates complex values. Now there are ways to deal with ODE systems which produce complex values, but before I get into this, I would like you to confirm that you expect one or more of f(x), g(x), h(x) or r(x) to be a complex-valued function.
3. In the attached I have changed the problem endpoint to 15.  This makes little difference to your problem. Complex values are still generated, and the initial-value sub-problem still produces some pretty huge values for f(x), g(x), h(x). As my original reponse queried - is h(15)=~2e14 remotely plausible???
4. The worksheet you posted in you response is complete and utter rubbish. Your dsolve() command has, as its first argument 'odes'. However no quantity 'odes' is defined in this worksheet. You appear to be surprised when Maple issues an error message on being asked to solve a sytem of differential equations which does not exist!! Come on!!

badODEsys2.mw

No-one here is going to retype your code - so use the big green up-arrow in the MaplePrimes toolbar to upload your code.

The image you have shown contains several parameters (F1, F2, a, b, q - possibly others) which have obviously been assigned values - include these assignments.

Original code works in Maple 2016.1 (my default). It also works in Maple 2015.2.

However it returns unevaluated in Maple 18.02 ;-( which is the earliest Maple version I have loaded).

As you observe

comp( 3.14, evalf(Pi), 0.01)
comp( 3.14, evalf(Pi), 0.001);

works in Maple 18, so I am assuming it will work in all earlier versions (can't test)

There is nothing syntactically wrong with this approach. Suggest you actually upload the worksheet in which your error occurs. (Big green arrow in the Mapleprimes toolbar)

However it is considered 'bad practice' to extend sets in this way. In Maple a set is an immutable object, so adding an element actually requires adding an element to a copy of the original set. This is considered inefficient, can be slow, and eats memory for large sets. However Maple allows you to perform this operation for small(ish) sets, so this shouldn't be an issue.

At least two reasons

1. The dimensions of your matrices are incompatible with the multiplications which you want - if you write the first term of the first equation (ie A1^T*U*P1*A1  in terms of the dimension of the matrices, one has
    [4,1]*[4,4]*[4,4]*[1,4]. This matrix multilication is impossible. Now if these dimensions were  [1,4]*[4,4]*[4,4]*[4,1], the multiplications would be possible. But this would mean that A1, A2, A3, A4 are 4x1 matrices - not 1x4 matrices as you state.
2. Assuming that A1, A2, A3, A4 are 4x1 matrices, then each term in each of you equations will be a 1x1 matrix, and their sum will be a 1x1 matrix. The rhs of you equations means that the element in this 1x1 matrix is zero. Thus each of your four equations will contain 16 unknowns - the entries in U. If you believe you can solve four equations in sixteen unknowns, keep trying. Otherwise stop now, and think again

The remarks you make about the "residual" value and the 'steepness' of the function are exactly the conclusions I came to when producing my original post. solvePR.mw

This is why I used Digits=100 (probably a bit overboard), and the 'fulldigits' option on the fsolve() command. This combination got the residual down to O(10^-64), as shown in the worksheet in my second post solvePR2.mw

At the time I produced these, the OP had given no indication that 'r' had to be positive - which is why I checked both +ve and -ve values

I'm still finding it a little difficult to figure out exactly what you want. The attached worksheet

1. reads the data file into a matrix
2. plots data simply by accessing appropriate matrix columns
3. assigns matrix columns to various data names (eg T__1, v_Luft, whatever)
4. plots data by using the assigned data names
5. gives an example of plotting data with revised tickmarks on the x-axis

dataPlot2.mw

See attached where I have substitued back into original solutions, and saved the output. Results of back substitution give 7.247..........*10^(-64)

solvePR2.mw

Consider the procedure and the function

restart;
p:=proc(z)
        local a;
        return a*z;
   end proc;
f:= z-> a*z;

Now both p(2) and f(2) will return '2a' as in '2*a'.. Furthermore

eval( p(2), a=3); #will still return 2a (as in 2*a)
eval( f(2), a=3); #will return 6

So functions defined using the arrow operator have no concept of local variables - any parameters (quantities not passed as arguments) are definitely global. On the other hand if a quantity is defined as 'local' in a procedure, then it *stays* local to that procedure.

If a quantity defined as local to a procedure is returned by that procedure, it can become very awkward to deal with, as in the above eval() command. The name 'a' in the condition a=3, is not the same as the name 'a' returned by the procedure, which is why the first eval() command above does not evaluate to 6

I have a slight issue with the use of declare(), in that (so far as I am aware), it is 'display-only', and for input I still have to use the form with the explicit dependence on argument. The only way I know to get around this, and achieve the most compact output display possible(?) is to use a combination of declare() and alias() - whihc means that the explict argument dependence is unnecessary on input, and doesn't appear in output. See the attached for examples

writeDE.mw

Using both of these commands just to make input a little shorter and output a little prettier is not something I (usually) bother with. For me it falls in the category of "more trouble than it is worth!"