restart;

kernelopts(version);

    Maple 2020.0, X86 64 LINUX, Mar 4 2020, Build ID 1455132

ans := convert( int(arccos(x)*arcsin(x),x), arcsin );

                    /                       (1/2)\                     
               1    |              /  2    \     |            2        
        ans := - Pi \x arcsin(x) + \-x  + 1/     / - arcsin(x)  x + 2 x
               2                                                       

                                  (1/2)
                         /  2    \     
           - 2 arcsin(x) \-x  + 1/     


simplify(convert( diff(ans,x) - arccos(x)*arcsin(x), ln) );

                               0

Executing a restart will cause the Startup Code to be re-executed.

Perhaps you worksheet contains a restart statement.

You could also use plots:-listplot for this. For example, using your definition:

plots:-listplot([seq(b(i),i=1..10)],
                color=red);

plots:-listplot([seq(b(i),i=1..10)],
                color=red,style=point,symbol=solidcircle);

You could, of course change the style and size of those plots.

See also here, where you could divide by the suitable power of 2.

The names a,b,c inside the procedure f are global names. The a,b,c in the call to solve within PARB2 have been declared as local. These are not the same names.

The names in the expressions returned by f (and assigned to gl1,gl2 within PARB2) are the global names. But the names in the set passed as the second argument to solve inside PARB2 are different, as they are local names. So inside PARB2 that call to solve is requesting solutions for names that don't actually appear inside the expressions assigned to gl1,gl2.

You could fix this mistake in several ways, including:
1) Don't declare a,b,c local to PARB2. eg. proctes_ac1.mw
or,
2) Inside PARB2, substitute global a,b,c in generated expressions assigned to gl1,gl2 with local a,b,c prior to calling solve.
or,
3) Recreate f within PARB2, using local a,b,c.
or,
4) Pass the names of the parameters a,b,c from the outer scope as additional arguments to PARB2, and use them in the solve call instead.
or,
5) Omit the second argument to solve as called within PARB2 eg. proctes_ac5.mw

I cannot tell which correction you would prefer. I haven't bothered to code all the above.

@woolyabyss The Online Help allows you to check for topics/commands not available in your older version.

For example, the online Help page for Topic dataplot shows the version in which it was released in its Compatibility section.

As for handling your data in Maple 17, you can plot a single Vector V using the command
   plots:-listplot( V )
You can could create a plot from two numeric Vectors X and Y with the command
   plot( <X|Y> )
And you can combine plots using the plots:-display command.

restart;

L:=1: c:=2: g:=0:
f:=(8*x*(L-x)^2)/L^3:
pde:=diff(u(x,t),t$2)=c^2*diff(u(x,t),x$2):
bc:=u(0,t)=0,u(L,t)=0:
ic:=u(x,0)=f,D[2](u)(x,0)=g:

sol:=pdsolve([pde, ic, bc],u(x,t)):

sol15:=rhs(subs(infinity=15,sol));

plots:-animate(plot,[sol15, x=0..1],t=0..1,frames=100);

This kind of question has been asked before, with several approaches given at various times (eg. here, here). 

Here are some examples.

restart;

ee := cos(Pi/16);

                                 /1    \
                        ee := cos|-- Pi|
                                 \16   /

s := Pi = v*16;

                         s := Pi = 16 v

eq := map(cos, s);

                      eq := -1 = cos(16 v)

E := expand(eq);

                        16                14                12
  E := -1 = 32768 cos(v)   - 131072 cos(v)   + 212992 cos(v)  

                    10               8               6
     - 180224 cos(v)   + 84480 cos(v)  - 21504 cos(v) 

                  4             2    
     + 2688 cos(v)  - 128 cos(v)  + 1


S := {solve(E, cos(v), explicit)}:

F := select(r->is(r=ee), S)[1]; # or test using float approximation

                                            (1/2)
                     /            (1/2)    \     
                   1 |/     (1/2)\         |     
              F := - \\2 + 2     /      + 2/     
                   2                             

# Here is your answer.
ee = F;
                                                (1/2)
                         /            (1/2)    \     
             /1    \   1 |/     (1/2)\         |     
          cos|-- Pi| = - \\2 + 2     /      + 2/     
             \16   /   2                             

# Various checks are possible. Here are some
# crude examples.

evalf(%);

                  0.9807852804 = 0.9807852805

is(ee = F);

                              true

convert_radical_example.mw

Here is another (though the call to factor might require a radical extension for other examples, which we might be able to obtain using, say, evala(Subfields(...)) ).

restart;
P:=op(1,convert(cos(Pi/16),RootOf));
                    8         6         4        2    
         P := 128 _Z  - 256 _Z  + 160 _Z  - 32 _Z  + 1

Rs:=simplify(radnormal~([solve(factor(P),explicit)]),size):
R:=select(r->is(r-cos(Pi/16)=0),Rs)[1];
                                            (1/2)
                     /            (1/2)    \     
                   1 |/     (1/2)\         |     
              R := - \\2 + 2     /      + 2/     
                   2                             

simplify(R-cos(Pi/16));
                               0

convert_radical_example2.mw

Firstly, you could read the appropriate Help pages, for example those wtih topic:
  dsolve,numeric/BVP
and
  dsolve,numeric_bvp,advanced

Next, you could try running your example with the appropriate infolevel set. For example (and, assuming that the incomplete example you provided is actually part of some boundary-value problem),

restart;
kernelopts(version);
    Maple 18.02, X86 64 LINUX, Oct 20 2014, Build ID 991181
ode := 1/100*diff(y(x),x,x)+exp(y(x))*diff(y(x),x)
       -1/2*Pi*sin(1/2*Pi*x)*exp(2*y(x)) = 0:
bcs := y(0) = 0,y(1) = 0:
newode := (1/10*(1-lambda)+1/100)*diff(y(x),x,x)
          +exp(y(x))*diff(y(x),x)
          -1/2*Pi*sin(1/2*Pi*x)*exp(2*y(x)) = 0:
infolevel[`dsolve/numeric/BVP`]:=2:
ds:=dsolve({newode,bcs},numeric,continuation=lambda):
dsolve/numeric/BVPSolve: solving BVP using trapezoid-richextrap method
dsolve/numeric/BVPSolve: using hardware floating point routines
dsolve/numeric/BVPCont: computing initial solution profile by continuation
dsolve/numeric/DeferredCorrect: correcting for order 2 error
dsolve/numeric/BVPSolve: got absolute error of 2.91951576497438481 with O(h^2) method
dsolve/numeric/BVPSolve: Computed required error to be 1.11651167704591 for an adjustment factor of 1.61705122459415
dsolve/numeric/BVPSolve: Increasing mesh from 32 to 52 points
dsolve/numeric/DeferredCorrect: correcting for order 2 error
dsolve/numeric/BVPSolve: ####Entering stage 3####
dsolve/numeric/BVPSolve: refining solution to desired accuracy using Richardson extrapolation
dsolve/numeric/RichardsonExtrap: Start Richardson extrapolation using mesh multiplication, original grid is 52 points
dsolve/numeric/RichardsonExtrap: correcting for order 2 error using a grid of 103 points
dsolve/numeric/RichardsonExtrap: correcting for order 4 error using a grid of 154 points
dsolve/numeric/RichardsonExtrap: correcting for order 6 error using a grid of 205 points
dsolve/numeric/RichardsonExtrap: correcting for order 8 error using a grid of 256 points
dsolve/numeric/RichardsonExtrap: correcting for order 10 error using a grid of 307 points
dsolve/numeric/BVPSolve: ####Entering stage 4####
dsolve/numeric/BVPSolve: Estimated error with interpolation to be 8.94901865584014e-005
dsolve/numeric/BVPSolve: Increasing mesh from 52 to 81 points
dsolve/numeric/BVPSolve: refining solution to desired accuracy using Richardson extrapolation
dsolve/numeric/RichardsonExtrap: Start Richardson extrapolation using mesh multiplication, original grid is 81 points
dsolve/numeric/RichardsonExtrap: correcting for order 2 error using a grid of 161 points
dsolve/numeric/RichardsonExtrap: correcting for order 4 error using a grid of 241 points
dsolve/numeric/RichardsonExtrap: correcting for order 6 error using a grid of 321 points
dsolve/numeric/RichardsonExtrap: correcting for order 8 error using a grid of 401 points
dsolve/numeric/RichardsonExtrap: correcting for order 10 error using a grid of 481 points
dsolve/numeric/BVPSolve: Estimated error with interpolation to be 4.6173768506504e-006
dsolve/numeric/BVPSolve: Increasing mesh from 81 to 98 points
dsolve/numeric/BVPSolve: refining solution to desired accuracy using Richardson extrapolation
dsolve/numeric/RichardsonExtrap: Start Richardson extrapolation using mesh multiplication, original grid is 98 points
dsolve/numeric/RichardsonExtrap: correcting for order 2 error using a grid of 195 points
dsolve/numeric/RichardsonExtrap: correcting for order 4 error using a grid of 292 points
dsolve/numeric/RichardsonExtrap: correcting for order 6 error using a grid of 389 points
dsolve/numeric/RichardsonExtrap: correcting for order 8 error using a grid of 486 points
dsolve/numeric/BVPSolve: Estimated error with interpolation to be 1.11619447896115e-006
dsolve/numeric/BVPSolve: Increasing mesh from 98 to 107 points
dsolve/numeric/BVPSolve: refining solution to desired accuracy using Richardson extrapolation
dsolve/numeric/RichardsonExtrap: Start Richardson extrapolation using mesh multiplication, original grid is 107 points
dsolve/numeric/RichardsonExtrap: correcting for order 2 error using a grid of 213 points
dsolve/numeric/RichardsonExtrap: correcting for order 4 error using a grid of 319 points
dsolve/numeric/RichardsonExtrap: correcting for order 6 error using a grid of 425 points
dsolve/numeric/RichardsonExtrap: correcting for order 8 error using a grid of 531 points
dsolve/numeric/BVPSolve: Estimated error with interpolation to be 5.61718208533154e-007

bvp_infolevel.mw

I get this in Maple 2018.2 and Maple 2020.0 (64bit Linux). This is a shorter and slightly different example.

restart;
kernelopts(version);
    Maple 2020.0, X86 64 LINUX, Mar 4 2020, Build ID 1455132

sum1 := Sum(1/((11-2*n)!*(n-1)!*(29+2*n)!),n=2..3):

value(sum1) ;
                              173                    
          -------------------------------------------
          7439866535798024349359988963016704000000000

simplify(sum1);
Error, (in evalr/evalr) too many levels of recursion

foo:=convert(sum1,GAMMA);
              3                                           
            -----                                         
             \                                            
              )                      1                    
     foo :=  /    ----------------------------------------
            ----- GAMMA(12 - 2 n) GAMMA(n) GAMMA(30 + 2 n)
            n = 2                                         

combine(foo);
                               0

simplify(foo);
                               0

value(foo);
                              173                    
          -------------------------------------------
          7439866535798024349359988963016704000000000

simplify(sum1);
                               0

I'll point out that simplify(sum1) returned 0 at the end, although earlier it produced a recursion limit error. On some runs combine(foo) would also error out like that, with foo in GAMMA form.

simplify_ex_ac.mw

And one more short example (without the (n-1)! in the denominator). simplify_exac2.mw

Someone might mention that add is a better choice for adding up a finite number of terms. But that seems a mere sidebar here. The following is also interesting, where the case that N<5 is pushed aside.

restart; sum(1/((11-2*n)!*(29+2*n)!),n=2..N,formal=true);

                             3079                     
         ---------------------------------------------
         130088533681106143868879347831013376000000000

restart; sum(1/((11-2*n)!*(29+2*n)!),n=2..N,formal=false);

  Error, (in SumTools:-DefiniteSum:-ClosedForm) summand is
  singular in the interval of summation

And,

restart;
combine(Sum(1/(GAMMA(7-2*n)*GAMMA(1+2*n)),n=2..3,formal=false));
                               0

restart;
combine(Sum(1/(GAMMA(7-2*n)*GAMMA(1+2*n)),n=2..3,formal=true));
                               0

It looks like your plan is to have the module local atable be assigned the actual table, rather than just a name that refers to that table. For example,

TestLibrary := module()
    export aset,atable:
    option package:

    aset := myset:
    atable := eval(mytable);
end module

If -- as you had it -- the module local is only assigned the name of the table (ie. mytable) then that's what gets stored in the archive.

This evaluation behavior is special to a few data structures, including table and Record -- but not list, set, Matrix/Vector/Array.

You might want to read the Help pages for table , in particular the 5th bullet point which describes that a table has special evaluation rules. See also last name evaluation .

Attached is a revision that preserves the table, upon savelib and restart.
TestLibrary_ac.mw

You attached a data file, but you stil have not attached any worksheet showing your actual code.

In a few of your responses you included something like code, as text. But it was all incomplete, and with different sizes than the attached data, and very incomplete since none of it worked alone. And there were syntax errors in extracting particular columns.

Anyway, the following works for me. I used LinearAlgebra:-Dimensions to pick off the number of rows and columns of the imported data. I used square brackets to index into the Matrix -- over a range -- to extract a single column as Vector.

signalplot_ac.mw

Yes, there are problems here. For example, using Maple 2019.2 or Maple 2020.0,

restart;
assume(0 < a, a < R);

K := 2*Pi*Int(sin(phi)
              *Int(rho^2,
                   rho = sin(phi)*R - sqrt(sin(phi)^2*R^2 - R^2 + a^2)
                         ..
                         sin(phi)*R + sqrt(sin(phi)^2*R^2 - R^2 + a^2)),
              phi = arccos(a/R) .. Pi - arccos(a/R)):

value(K);

                -Pi^2*R*a^2

#
# The following call to `simplify` merely changes the radical
# in the inner limits of integration to,
#
#    ( -R^2*cos(phi)^2 + a^2 )^(1/2)
#
simplify(K, trig):
value(%);

                2*Pi^2*R*a^2

#
# The following call to `combine` merely changes the radical
# in the inner limits of integration to,
#
#    ( -2*R^2 + 4*a^2 - 2*R^2*cos(2*phi) )^(1/2)/2
#
combine(K):
value(%);

                2*Pi^2*R*a^2

Below we can seen that the inner integral is not the problem. The problem comes from the elliptictrig method which is one of those that int tries for the outer integral, and whose result -- when it does not fail -- gets preferred and returned.

One possible way to avoid the problem is to force int to use a method other than the problematic elliptictrig. This means not using the nicely typeset 2D Input integral, so I'll use plaintext 1D Maple Notation instead. Below I'll continue in the same session, with the same assumptions on a and R.

PP := int(rho^2,
          rho = sin(phi)*R - sqrt(-R^2*cos(phi)^2 + a^2)
                ..
                sin(phi)*R + sqrt(-R^2*cos(phi)^2 + a^2));

     1/3*(sin(phi)*R+(-R^2*cos(phi)^2+a^2)^(1/2))^3
    -1/3*(sin(phi)*R-(-R^2*cos(phi)^2+a^2)^(1/2))^3

P  :=  int(rho^2,
           rho = sin(phi)*R - sqrt(sin(phi)^2*R^2 - R^2 + a^2)
                 ..
                 sin(phi)*R + sqrt(sin(phi)^2*R^2 - R^2 + a^2));

     1/3*(sin(phi)*R+(sin(phi)^2*R^2-R^2+a^2)^(1/2))^3
    -1/3*(sin(phi)*R-(sin(phi)^2*R^2-R^2+a^2)^(1/2))^3

# Those are the same. The problem is with the outer integral.
simplify(PP-P);

                     0

int(P*sin(phi),phi=arccos(a/R)..Pi - arccos(a/R), method=elliptictrig);

                  1       2
                - - R Pi a 
                  2        

# The following returns unevaluated.
int(PP*sin(phi),phi=arccos(a/R)..Pi - arccos(a/R), method=elliptictrig):
op(0,%);

                    int

int(P*sin(phi),phi=arccos(a/R)..Pi - arccos(a/R), method=ftoc);

                        2
                  R Pi a 

int(PP*sin(phi),phi=arccos(a/R)..Pi - arccos(a/R), method=ftoc);

                        2
                  R Pi a 

When no method is specified the integration of ("simplified" form) P produces the wrong result from the ellitictric method, which gets selected and returned automatically. When no method is specified the integration of the (unsimplified form) PP produces the acceptable result from the ftoc method, since the elliptictrig method fails to produce anything.

Thus a workaround is to force the ftoc method for such examples that otherwise go wrong with the elliptictrig method. That may not always convenient to set up, however.

I have previously seen several similar problematic examples with that method. I'll submit a bug report.

int_oddity.mw

Here is the original nested integral, using 2D Input and with the inner integral typeset and the outer integral forcing method=ftoc. The limits of integration are as in the original, and the desired result attains.

int_ftoc.mw

My personal preference is for a cutout view, so that any relationship between the particular edges of the washers with the surfaces can be seen.

In order to keep the GUI responsive, it helps considerably to keep the frame data smaller. By using a grid=[2,49] option for the washer construction they can retain the same look as default, while taking less memory resources. The benefit is great enough that a modest number of washers can be shown together in the frames.

restart;
F:=proc(yy, ea) local hh,opts,phi,r,y; uses plots;
  opts := style=surface, color=gold, grid=[2,49];
  display(seq([
    display(plot3d([[r*cos(phi),r*sin(phi),y],
                    [r*cos(phi),r*sin(phi),y+h]],
                   r=y^2..sqrt(8*y), phi=0..ea, opts),
            plot3d([[y^2*cos(phi),y^2*sin(phi),hh],
                   [sqrt(8*y)*cos(phi),sqrt(8*y)*sin(phi),hh]],
                   hh=y..y+h, phi=0..ea, opts)),
    display(polygonplot3d([[y^2,0,y],[y^2,0,y+h],
                           [sqrt(8*y),0,y+h],[sqrt(8*y),0,y]]),
            polygonplot3d([[y^2*cos(ea),y^2*sin(ea),y],
                           [y^2*cos(ea),y^2*sin(ea),y+h],
                           [sqrt(8*y)*cos(ea),sqrt(8*y)*sin(ea),y+h],
                           [sqrt(8*y)*cos(ea),sqrt(8*y)*sin(ea),y]]),
      transparency=0.5)][], y=0..yy, h));
end proc:
numframes:=15: h:=2.0/(numframes): endangle:=4*Pi/3:
P:=plot3d([[r*cos(phi),r*sin(phi),r^2/8],[r*cos(phi),r*sin(phi),r^(1/2)]],
          r=0..4, phi=0..endangle,
          style=surface, color=["Green","Blue"], transparency=0.75):
plots:-animate(F,[y, endangle], y=0..2-h, frames=numframes,
               background=P, paraminfo=false,
               lightmodel=light2, glossiness=1.0, scaling=constrained,
               axes=normal, labels=[z,x,y], orientation=[-60,70]);

washers_ac.mw

Naturally, it can be done similarly for shells.

@mikerostructure Yes, I have Maple 2020.0, and I use right-click to export 3D plots on a regular basis.

I usually export to .png format. If your problem is with .eps export specifically then this would a good time to mention it. (For me, .eps export of your simple example does make my machine's CPU ramp up for a couple of seconds -- the export file is not small. But it doesn't crash.)

Another possible point of interest may be whether you have a particular language setting in Maple's GUI.

In your followup comments you've started mentioning a problematic file. Is there a reason that you cannot upload and attach that particular file to a Comment here, using the green up-arrow of the Mapleprimes editor? If the problem occurs when you re-execute it from scratch then perhaps you could even "Edit/Remove All Output" within it, for an easier, smaller upload.

This is numerical error, yes. The particular behavior depends on the working precision.

Your Document has a line that assigns to the name Digit . If you changes that to be Digits instead then you can easily adjust the working precision and see what happens when it is run with Digits=15,16,17,18, etc.

If this expression is assigned to name expr, say, then you can compare with expand(expr) and combine(expand(expr)). Compare with the values that occur in the numerator of your original expression.

Note that by default this plotting call will try and utilize evalhf to do the plotting in hardware double precision. That switches to so-called software floating-point when Digits>15.

This particular plotting command will also switch from evalhf  to sofware floats as a fallback if it detects a Float(undefined) result. There is a small range from about t=14880.0 to t=14902.7 in which the expression evaluates to 0.0 because roundoff error has occured but yet not underflow/overflow. For t above that range it will fall back to software float mode (and the curve again appears even at 0.45). This attachment demonstrates this behaviour 1_ac2.mw

The particular fashion in which numerical error occurs for this example is different for forced software floats at Digits<15 versus hardware double precision. There are ways to force software floats for Digits<=15 . (see attachment)

(Inlining documents to Mapleprimes seems to be broken right now.) Here is an attachment that demonstrates that forcing of software floats at lower Digits : Download 1_ac.mw