@torabi Plotting y as a function of A assumes that you have a precise definition of what y is.
You stated earlier that y meant " the amplitude of the y component of the system's attractor".
What does that mean when the attractor is rather complicated and not just a point?

@torabi No I haven't looked much at it.
What I have done is to look at the dependence on A for fixed alpha = 0.89.

Using the version of fdsolve given in the worksheet FracDiff.mw and using the example in the paper, I did the following.
 

## Assuming fdsolve defined as in FracDiff.mw
F:=omega*x-y^2;
G:=mu*(z-y);
H:=A*y-B*z+x*y;
paramsA:={omega=-2.667,mu=10,A=AA,B=1}; # A and AA unassigned
params2:=unapply(paramsA, AA); 
## Using alpha=0.89:
##
solfu2:=proc(AA) option remember,system; local FGH;
    if not AA::numeric then return 'procname(_passed)' end if;
    FGH:=unapply~(eval([F,G,H],params2(AA)),t,x,y,z);
    fdsolve(FGH,0.89,0..20,[.1,.1,.1],2000)
end proc;
##
sol:=solfu2(27.3); #Test
plot(sol[..,[1,3]],labels=[t,y],size=[1200,default]);
plot(sol[..,[1,3]],y=10..20,labels=[t,y],size=[1200,default]);
plots:-animate(plots:-spacecurve,[solfu2(A)[..,2..4] ],A=[15,20,25,27.3]);
## The next will be fast because solfu2 has option remember:
plots:-animate(plot,[solfu2(A)[..,[1,3]] ,t=10..20],A=[15,20,25,27.3],size=[1200,default]);

solfu2(A) just computes the solution for a given value of A.
The plots found are just the orbits of graphs of the solutions.
When t starts at a late value (e.g. as here 10) then perhaps enough time has passed for the orbit to be close to a possible attractor.

@Seb1123 Stating the obvious (even without having to consult the help):  simplify will do its best to simplify.
Simplification of an equation just means simplifying each side.
In fact you don't need simplify to do that job for your equation. Just write it down and press ENTER:
F*R=(1/2*M*R^2)*(a/R);  
The output is F*R = (1/2)*M*R*a.
So you expected simplify to read your mind. To read that you wanted to solve the equation for F?

@Federiko My question was basically meant as 'rhetorical'.

If a locally Lebesgue integrable function f defined on [0, infinity[  satisfying for some M >0, some real a, and some t0 >= 0 the inequality
abs(f(t)) <= M*exp(a*t) for a.e. t >=t0  ( "f is exponentially bounded")

then the Laplace transform F(s) exists for all s satisfying Re(s) > a. Furthermore F is analytic in that region. In particular continuous, thus cannot have singularities.
If your F has infinitely many singularities (s[n]) and s[n] -> infinity, then your F cannot be the Laplace transform of an exponentially bounded locally Lebesgue integrable function.

@Federiko In earlier versions of Maple you must replace the type specfunc(sin) with specfunc(anything,sin).
So the code is this (and that will also work in more recent versions):
 

restart;
F:=1/(s^2*(1+(1-1/(2+2*s))/s)*(1+tan((1/2)*Pi/sqrt((1-1/(2+2*s))/s))/sqrt((1-1/(2+2*s))/s)));
F2:=normal(convert(F,sincos));
A:=op([1,1],indets(F2,specfunc(anything,sin)))/Pi; ## Change made here
limit(A,s=infinity);
sp1,sp2:=solve(A=p,s);
evalf(seq(sp1,p=1..10));
dF2:=denom(F2);
seq(fsolve(dF2=0, s=eval(sp1,p=n)..eval(sp1,p=n+1)),n=0..9);

The 'anything' in specfunc(anything,sin) means that the argument to sin must be of type 'anything'. As the name 'anything' indicates this means basically anything. See ?type,anything

@ The code works as written in Maple 2018.1. I just checked the downloaded version from MaplePrimes using the icon !!!
I copied the code and tried it in Maple 18.02.
You are right. In that version parameters appearing in the initial conditions apparently must be "alone", i.e. the parameter H cannot appear as in Jir( H- He ) = ...
## To see a simple example of that, try
 

ode:=diff(x(t),t)=x(t);
res:=dsolve({ode,x(t0-2)=1},numeric,parameters=[t0]); # Error in Maple 18
###
ode:=diff(x(t),t)=x(t);
res:=dsolve({ode,x(t0)=1},numeric,parameters=[t0]); # t0 appearing alone: OK also in Maple 18
res(parameters=[0]);
res(1);

Both versions work in Maple 2018.1:
The solution for Maple 18 is simple. Replace the parameter H by the parameter HmHe (meaning H minus He).
In the initial conditions HmHe shall replace H-He. When you set the parameter HmHe using some value for H, HH say, then you do
resNew( parameters=[HH-He]);
I have uploaded a version with these changes. I have kept the old lines for comparison, but they are commented out.

MaplePrimes18-08-21_odesys_inits18.mw

I changed your code just slightly and didn't use optimize.
The change was that sol was made a function of H defined in advance.
Your version with nn:=20000 executed in 65.5s and mine in 43.7s.
If I add optimize to my version it takes the same as yours.
## The following note is edited: Since the loop breaks at i = 742 you are optimizing dsolve not 20000 times, but only 742 times. That appears to take 20s.
If you remove optimize from your version it takes the same time as mine.
So better ideas are needed.

Now the code anyway:
 

## Before the loop and for clarity unassigning H first (it was a function of t) put this:
##
sys_ode:=diff(sv(x),x)=rho0*g/Lambda(x),diff(sh(x),x)=beta12(x)/beta22(x)*rho0*g/Lambda(x),diff(Lambda(x),x)=rho0*g/beta22(x),diff(u(x),x)=-Mp*g/beta22(x),diff(Jir(x),x)/Jir(x)=-Gp(x)*diff(Lambda(x),x)/Lambda(x);
ics:=sv(H-He)=sve,sh(H-He)=she,Lambda(H-He)=Le,u(0)=0,Jir(H-He)=Jire;
## Now the function of H:
res:=HH->dsolve(eval({sys_ode,ics},H=HH),numeric,[sv(x),sh(x),Lambda(x),u(x),Jir(x)],output=listprocedure);
## Now the loop
nn:=20000:
t0:=time():
dt:=(Ts-Te)/nn:
t:=Te:
HH:=He: #Note HH
for i from 1 to nn+1 by 1 do
 sol:=res(HH);
 CC2(i,1):=t/(10^6*365*24*60*60):
 CC2(i,2):=HH: # HH
 sh0:=rhs(sol(0)[3]):
 sv0:=rhs(sol(0)[2]):
 TR2(i,1):=-1/3*sh0-2/3*sv0:
 TR2(i,2):=sqrt(3)/3*(sh0-sv0):
 Jir0:=rhs(sol(0)[6]):
 phix0:=1-(1-phi0)/Jir0:
 EN2(i,1):=pc0*(ln(phix0)/ln(phi0))^m:
 up:=rhs(sol(HH-He)[5]): #HH
 uh:=ue+up:
 fvp:=evalf(A*sh0+B*sv0-(pv0*(ln(phix0)/ln(phi0))^n)):
 if fvp>=0 then
  break
 else
  dH:=dt*(Mp/rho0+uh):
  HH:=HH+dH: ## HH
  t:=t+dt:
 end if:
end do:
time()-t0;

Maple cannot solve integral equations (or integro-differential equations) numerically. So you are on your own.

First of all you cannot use { }  (or [] ) instead of parentheses ().
Secondly, Maple can solve delay odes, but not delay pdes. In your second equation you have w evaluated at (t - tau, x), where tau = 0.3.

@ecterrab Yes Edgardo, I participated in the discussion in MaplePrimes about matrix input a couple of years ago and thought it would be a good idea. I still think it is. I was primarily thinking of its use in the classroom, where e.g. a system of first order odes with constant coefficients theoretically are handled best as a vector equation x'(t) = A.x(t) + b(t) and handled like that in textbooks.
So thank you much for that feature and for your detailed reply.
 

@awass In the documentation for dsolve,numeric,ivp you find under Parameters:

"odesys   set or list; ordinary differential equation(s) and initial conditions".
Here odesys refers to the first argument (see Calling Sequence).

Thus there is nothing to make you believe that dsolve/numeric/ivp will except vector equations as input.
It is no different for dsolve/numeric/bvp.

As far as the symbolic use of dsolve is concerned it appears that the situation is the same. But vector equation input is in fact accepted. That it is not as yet documented could be because it may change in future versions or it could be an oversight.
You can use a command with confidence if you follow its documentation. If a feature isn't documented then don't count on it working in the next release.

And by the way, I think the term "inconsistency" isn't quite what we are talking about.
I would rather use a term like "uniformity".
There is nothing inconsistent about dsolve/numeric not accepting vector equation input while dsolve in its symbolic use does. But there is a lack of uniformity. And so what?

@awass Yes, vector input works symbolically. But output is not on vector form. Should it be?
Then what about the numerical situation? Surely it wouldn't take much effort to allow for vector input. But to mess with changing existing form of output here probably wouldn't be worth the trouble.

@tomleslie Since several people have participated in developing the many parts of Maple's dsolve and over many years, you can expect that kind of input "inconsistency".  Those people probably have different ideas of what is important and what is not or of what is worth doing or not. So for "consistency" you will need a dictatorship foreign to an academic environment, which hopefully Maplesoft provides for its developers.
Now having said all that, I can point out some other "inconsistencies" in this general area.
How about the input difference for pdsolve/numeric and the exact pdsolve?
Or how about these dsolve examples:
 

ivp:={diff(x(t),t)=x(t),x(0)=1}; 
dsolve(ivp); # No variable needed, but allowed
dsolve(ivp,numeric); # No variable needed, but allowed
dsolve(ivp,series); # Error
dsolve(ivp,x(t),series); # Variable needed
dsolve(ivp,method=laplace); # Error
dsolve(ivp,x(t),method=laplace); # Variable needed

@raskr Yes, I taught at DTU. Also I agree with you about the need for changing displayprecision to significant digits instead of decimal places.
I have typesetting = standard as default so when I tried Maple 2017.3 I found out that even that version then uses decimal places. I made a comment to the answer by Tom Leslie about that.

@tomleslie When displayprecision=4 and typesetting=standard we get 4 decimal places in Maple 2017.3, but with typesetting=extended and displayprecision=4 we get 4 significant digits.