@amrramadaneg 

Do not post any more images!!!!!!! I can barely read them, I can't execute them and I can't debug them - they are useless.

If you can obey the instruction you are now being given for the third time, you might get some help, otherwise you are on your own

Upload a maple worksheet using the big green up-arrow at the right-hand end of the second row in the above toolbar

@amrramadaneg 

In the sentence from my previous post

Upload a maple worksheet using the big green up-arrow at the right-hand end of the second row in the above toolbar

Which is the word you do not understand?

@mela 

If |I consider your response to Markiyan then you claim that you now have the following nine equations (I don't know where the 10-th one went)

eq1; P[v] = w^(1-gamma)*r[star]^gamma;
eq2; w*H/M[bar] = (1-gamma)*P[v]*q/Phi;
eq3; p[d] = sigma*P[v]/((sigma-1)*Phi;
eq4; Y^(-alpha[c])/P = A*H^alpha[h]/w;
eq5; q = tau*y[x]+y[d];
eq6; y[d] = M[bar]^(lambda-1)*Y*(p[d]/P)^(-sigma);
eq7; y[star] = M[star]^(lambda-1)*Y*(tau*p[star]/P)^(-sigma);
eq8; PY = tau*M[star]*p[star]*y[star]+M[bar]*p[d]*y[d];
eq9; y[x] = F[star]*(tau*p[star])^(-sigma[x]);

Now leaving aside that there is a syntax error in eq3 (unbalanced parentheses), I can run a simple check on how many undetermined quantities there are in these equations using the simple piece of code

indets({seq(eq || j, j = 1 .. 9)}, name);

which returns the list of variables

{A, H, P, PY, Phi, Y, gamma, lambda, q, sigma, tau, w, F[star], M[bar], M[star], P[v], alpha[c], alpha[h], p[d], p[star], r[star], sigma[x], y[d], y[star], y[x]}

If I execute

numelems(indets({seq(eq || j, j = 1 .. 9)}, name));

it returns

25

In other words your nine equations contain 25 undetermined variables.

Perhaps if you could write 10 equations in 10 variables (or 9 equations in 9 variables) then someone here might get interested. But with nine equations in 25 variables -get real, try harder!!!!!

I count at least 7 syntactic errors in the two differential equations you supplied.

Now I can guess what you meant - but I don't see why I should have to: so I suggest you upload a Maple worksheet (using the big green up-arrow, right hand end of the second toolbar), with

• your equations defined in a syntactically correct way
• your boundariey equations defined in a syntactically correct way
• since you say "I haven't been able to solve this using differential transforms method" - include the code which you are using for this operation

Uploading an illegible picture is going to get you nowhere

Upload a maple worksheet using the big green up-arrow at the right-hand end of the second row in the above toolbar

@phil76600 

Try running the two cases in a loop and then overlay the results, as in

restart;
k:= 10: m:= 1: g:= 10: mu:= [.2, 1000]: U:=1:
Xr := U*t-x(t):
for j from 1 by 1 to 2 do
   ode1 := m*diff(x(t), t, t) = k*Xr-piecewise(mu[j]*m*g<k*Xr,mu[j]*m*g,0):
   res[j]:=dsolve({ode1,x(0)=0,D(x)(0)=0},numeric):
od:
p1:=plots:-odeplot(res[1],[t,x(t)],0..15, color=black):
p2:=plots:-odeplot(res[1],[t,diff(x(t),t)],0..15, color=blue):
p3:=plots:-odeplot(res[2],[t,x(t)],0..15, color=red):
p4:=plots:-odeplot(res[2],[t,diff(x(t),t)],0..15, color=green):
plots:-display(p1,p3);
plots:-display(p2,p4);

For diagnostic purposes, I modified your code slightly to

restart;
with(plots):
with(DEtools):
ode1 := diff(x(t), t) = v(t):
ode2 := diff(v(t), t) = -(.8*9.8)*v(t)/abs(v(t))-cos(t)^2:
IC1 := x(0) = .5, v(0) = .25:
IC2 := x(0) = 2.5, v(0) = 3:
sol1:= dsolve( [ode1, ode2, IC1],
               [x(t), v(t)],
               numeric,
               maxstep=0.02,
               output= Array([seq(0.001*j, j=0..1000)])
             );

Examination of the output array, indicates that v(t) heads to zero fairly quickly and thus the term

v(t)/abs(v(t))

becomes ~0/0 which is undefined and the numerical procedure dies.

You might be able to come up with a numerical method, which "steps across" this singularity (for example inserting method=gear, in the dsolve() command seems to do this), but I wouldn't believe the results to the right of the singularity!!

@Peter Lang 

Chill pill swallowed

But -

1. If I can't see the problem, and
2. I can't even see an attempt at a solution, then
3. Realistically how do you expect anyone here to do anything???

Don't get me wrong - people on this site are generally brilliant at coming up with solutions - but solutions to poblems they are not allowed to see is asking too much!!!

Are you sure that there is no way that you can post your specific problem without violating someone's copyright?

There are two fundamental problems with this post

1. The OP refers to an academic paper which (at least for non-academics with me - presumably without some subscription or other) cannot be obtained without payment of $25 - do you really think I am going to pay this in order to solve your problem??!!!
2. At no point in the process have you uploaded any code for debug purposes

So you expect someone like me to debug code I can't see, in order to solve a problem I cannot examine - get real!

I have no idea what Markiyan is looking at, but for history here he generally seems to be a smart guy, I suggest that you stick with what he has suggested - and bear in mind that the way you have posed your question (see 1,2 above), no-one else will be able to help

You have to help us to help you!

The OP code (NB this is a cut-and-paste!!)

restart; S := 8;
sigma := 8/sqrt(2*Pi);
iprec := 151;
evalf(log[2](-(sum(log(round(2^iprec*exp(-j^2/(2*sigma^2)))/2^iprec*exp(-j^2/(2*sigma^2))))*round(2^iprec*exp(-j^2/(2*sigma^2)))/2^iprec, j = 0 .. 7))));

does not compute what the OP claims that it does, for the simple reason that the final statement has unbalanced parentheses, and produces the welll-known error message

Error, `)` unexpected

Quick, dirty check with StringTools shows that it has 13 opening parentheses and 14 closers. Deleting one of the very final parenthesis (ie next to the semicolon terminating the execution group) does not work because that results in the erro message

Error, invalid input: sum uses a 2nd argument, k, which is missing

So the sum() is being prematurely terminated.

The "minimal" change to the OP code which avoids syntax errors is

evalf( log[2](-(sum(log(round(2^iprec*exp(-j^2/(2*sigma^2)))/2^iprec*exp(-j^2/(2*sigma^2)))*round(2^iprec*exp(-j^2/(2*sigma^2)))/2^iprec, j=0..7))));

Although this produces the answer 1.789785664 whihc is nowhere near what the OP expects.

See the attached for my thought process

evalf.mw

What am I missing????

@Rouben Rostamian  

As presented, there is no relationship between a[] and A[] - the only sensible conclusion I can draw is that these are two independent variables. In which case my remark stands

If they are not independent, then OP should specify the dependency

Leaving aside for the moment the issue of boundry conditions (which one may think of as "start" conditions) the equation  as expressed cannot be solved at the step j+1, even although all values up to step j are known, for the simple reason that it contains two quatities to evaluated at the step j+1 - highlighted in the following

EQs:=A[j]-theta*tau*(A[j-1]-2*A[j]+A[j+1])=a[j]+sqrt(a[j])*b[j]*h^2/tau+(1-theta)*tau*(a[j-1]-2*a[j]+a[j+1]) ;

so A[J+1] depends on a[j+1] and vice versa. Since neither is known from previous calculation, nether can be calculated  without additional information.

@Carl Love 

Then use my second suggestion - an arrayplot with two pointplots comprising

1. magnitude versus frequency,
2. phase versus frequency

It would be relatively trivial to convert magnitudes to absolute or dBs and similarly phase in radians or degrees.

In Maple 2015 the help page ?DifferentialGeometry/Tensor/Curvature gives a couple of procedures for verifying the Bianchi identities in the examples section

Two possibilities

1. Use the BodePlot command from the DynamicSystems package, although this is just an implementation of.....
2. an arrayplot

However in neither case can the y-axis be "combined" as you want: I thought it might be possible to "rig" this by playing with table cell borders, but have so far failed :-(