@AHSAN which you also asked.

In the attached, there are independent execution groups which implement

1. a corrected version of your "FDM" code. Note that all I did was fix syntax so that plots are produced - I have made no attempt to check whether or not your basic algorithm is correct.
2. an example of using the shooting method to convert your originall BVP with boundary conditions of the form u(point1)=alpha, u(point2)=beta, to an IVP with initial conditions of the form u(point1)=alpha, D(u)(point1)=gamma. Plotting solutions from the two methods shows that they are the same (as one would expect, because the shooting method, generally works). It also illustrates, that having converted to an IVP, it is possible to compute the solution "beyond" the right boundary of the original BVP problem

odeplots3.mw

with tables of results. Actually, for convenience, I stored the results in matrices. In each matrix the [1,1] value specifies the value of 'x': the remainder of the first column specifies the y-values at whihc reults are computed, for which I used y=-1..1 in steps of 0.1; the remainder of the first row shows the parameter being varied, so is either k=0.1..k=0.9 or wi=0.1..wi=0.9.

This should be pretty obvios from the output in the attached.

From the help page for dsolve/numeric (which I recommend you read)

For boundary value problems (BVP), a finite difference technique with Richardson extrapolation is used (For more information, see numeric,BVP).

Whilst it is occasionally useful to convert a BVP to an IVP using the shooting method I see no reason to do so for your particular problem.

odeplots2.mw

if you upload a worksheet (use the big green up-arrow in the Mapleprimes toolbar).

As written, your question doen't make much sense.

you have

stev := EStk/
S_TEV := E*(0.29*(1 + r_tev)^T + 0.71*(0.6*stev))

What does the first line of this mean?

It might be simpler to work out whata is going on if you uploaded a worksheet using the big green up-arrow in the Mapleprimes toolbar

try FileTools:-IsLockable() to make sure that no other process (eg Excel maybe) has a "lock" on the relevant file

@vv 

submitted an SCR for this issue, covering both the uppercase/lowercase problem, and vv's point about the validity of the solution only over a restricted range of the variables

@Navid555 

1. Rouben Rostamian is a well-respected responder on this site. When he writes something, I read it very carefully. I suggest you do the same - and don't try to get smart, because (s)he is waaaaay smarter than you are (or me for that matter).
2. You supplied the boundary condition D[1](u)(x, 0) = 0 about which you are now doubtful. As written  D[1](u)(x, 0) = 0 means differentiate the function u(x,t) with respect to the first variable ( ie 'x', the clue is in the [1] part)  and then evaluate the result along the line x=x and t=0. If you check my original response, I suggested that a boundary condition of the form  D[2](u)(x, 0) = 0 would be acceptable to Maple. The part of this expression  D[2](u) essentially means differentiate the function u(x,t) with respect to the second variable ie 't'(the clue is the [2] part) and then evaluate the solution along the line x=x and t=0,
3. You now state "I want to derivate respect to time and not x", so any such boundary condition would definitely start with  D[2](u), followed by the evaluation point, which may (or may not be)  (x,0)
4. Follow the advice you are given

@Navid555 

As I've already explained, you can't solve it in Maple using a numerical method.

Interestingly, if you temporarily ignore the boundary conditions and ask for an analytic solution with pdsolve(PDE), then Maple provides one!. However it cannot be a general solution because your PDE is  second order in 'x' and second order in 't', so any solution *ought* to contain four integration constants (which would be resolved by the four boundary conditions)  and the solutiion Maple returns only has two integration constants -I'm not sure what this solution represents

@bstuan 

commands from either the |LinearAlgebra() or VectorCalculus() packages only work with 3D vectors - see the attached for examples

If you are starting with a 2D- construct (eg a dsegment from the geometry package) then you will have to incorporate a zero for the third componennt somehow. It may be easier to use the desment command from the geom3d() package with all points lying on the plane z=0. It is the trivial to convert to 3D-vectors and use the CrossProduct() command from either the LinearAlgebra() or VectorCalculus() packages - This is also shown in the attached

Whichj  of these is most appropriate depends very much on precisely what manipulations you intend to do with these vectors

   restart;
   with(VectorCalculus):
#
# 2-D vectors so this will generate an error
# 
   V1:=<a, b>;
   V2:=<c, d>;
   CrossProduct(V1,V2);
#
# 3-D vectors so this will work
#
   V3:=<a, b, 0>;
   V4:=<c, d, 0>;
   CrossProduct(V3,V4);
  restart;
  with(LinearAlgebra):
#
# 2-D vectors so this will generate an error
#
  V1:=<a, b>;
  V2:=<c, d>;
  CrossProduct(V1,V2);
#
# 3-D vectors so this will work
#

  V3:=<a, b, 0>;
  V4:=<c, d, 0>;
  CrossProduct(V3,V4);

  restart;
  with(geom3d):
#
# Define essentially 2D segments in this 3D package, by setting
# the z-values of all points to 0
#
  dsegment( d1, point(p1, [a__1, a__2, 0]), point(p2, [b__1, b__2,0]));
  dsegment( d2, point(p3, [c__1, c__2, 0]), point(p5, [d__1, d__2,0]));
#
# Convert to vectors
#
  V1:=Vector(`-`(coordinates~(DefinedAs(d1))[]));
  V2:=Vector(`-`(coordinates~(DefinedAs(d2))[]));
#
# Either CrossProduct command "works"
#
  LinearAlgebra:-CrossProduct(V1, V2);
  VectorCalculus:-CrossProduct(V1, V2);
  

segVec.mw

functions perfectly - see the attached

None of the "Exercises" at the end have been attempted - so please upload a worksheet which demonstrates an "error"

homework.mw

@Carl Love 

but the problem is that coloring is performed on the basis of how many iterations were taken to achieve onvergence, rather than to root value obtaained - thus instead of obtaining a "three-color" graph one obtains a more continuous gradation. (On defaults the number of iterations will be between 0 and 25 - so one *ought* to get an image with 26 colors). However an interesting feature is thatif one ignores the coloring, the overall "structure" of the final image is very similar. See the attached.

It is not obvious to me why "converged value" and "number of iiterations to achieve any converged value" should be related. I'm still thinking about this, but the onlyplausible  explanation I've come up with so far is that when using a starting value which is close to a "boundary" between "converged values", then more iterations will be necessary

I may revisit this problem, but it's past my bedtime.

For some reason the image rpoduced by the attached code does not appear inline on this site - so you are going to have to download the attached to see what I'm getting at

Download newtFrac.mw

@dirk1000 

which are a simple way to avoid premature evaluation, particularly where conditional statements are involved, which cannot be "evaluated" for non-numeric quantities.

However other methods are available. An alternative, some would say more "hygienic", method is shown in the attached. By rewriting the function f2() to return something "sensible" for non-numeric inputs , the uneval quotes in the plot statements become unnecesary

BTW your approach of using a f2__DC() to call f2() seems like aridiculously complicated way to generate the same behaviour availabble from a simple frem() command

Download duty2.mw

This (pretty amazing!) bug exists in Maple 18, Maple 2015, and Maple 2016, but has been fixed in all subsequent releases.

See the two worksheets below, one in Maple 18 and one in Maple2017 for comparison

Download intBugMaple18.mw

Download intBugMaple2017.mw

1. 51 linear equations in the 51 unknowns a[0]....a[50]
2. Each of these equations has its right-hand-side equal to zero (implicitly).
3. So the obvious solution is a[0]=a[1]=a[2]=..=a[50]=0.
4. Why would you expect any other solution?

@bstuan 

1. Stop trying to use something (the backSolver tutor) which is obviously broken. You have probably wasted hours on this, when 10 minutes on learning to code will provide a solution
2. State the problem you are actually trying to solve - and if you can't solve it, someone here will