@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.

@Carl Love Actually there is no complaint from dsolve/numeric when method=dverk78 and the ode is just

ode:= diff(y(x),x) = u; # No Re

The result is -0.555168769092963e-2+8.10096715234306*10^(-41)*I , which has the same real part as you get with Re(u) instead of u.
Methods ck45 and rosenbrock behave as rkf45.
No complaints from lsode or gear. No complaint from classical[rk4] (here without error tolerances of course).
### It appears that method=rkf45 doesn't complain when it can "see" from the start that the problem is complex (imaginary).
Examples:
 

restart;
ode:= diff(y(x),x) = 1+3*I; # A very visible I.
res:=dsolve({ode,y(0)=0},numeric,method=rkf45); #No problem
res(1); # Fine
##
g:=proc(x) if not x::numeric then 'procname(_passed)' else 1+3*I end if end proc;
odeg:=diff(y(x),x)=g(x); # I is not revealed at start
resg:=dsolve({odeg,y(0)=0},numeric,known=[g],method=rkf45); # Error
##
## In the following modified version I is visible from the start but is irrelevant if x<=10.
odeg2:=diff(y(x),x) = g(x) + piecewise(x>10,I,0); 
resg2:=dsolve({odeg2,y(0)=0},numeric,known=[g],method=rkf45); # OK
resg2(1); # OK
resg2(11); # OK

@Mariusz Iwaniuk I have no idea. If you are being sarcastic, peace be with you. I shall correct .2 to .1.
Thank you.

@MapleMathMatt You may be right. Mine is unchecked, so everything is allowed.

@dharr Since I do have a file at that place and readline works for me, let me give my output from
 

FileTools[Status]("F:/test.txt");

It is
[true, true, false, false, 1533641290, 68]

The two first show that I have read and write permission for that file according to the help for FileTools[Status].