@CK1992 I left out the change in alpha from 1 to zero.
So now a "solution" is produced.
The input to pdsolve when different from the names of the dependent variables (as in this case) should probably include the independent vaiables as in: g(x,eta)*sqrt(x). 
Besides that I didn't have much success. I tried replacing exp by its first taylor polynomial, thus using exp(x) = 1 + x.
Only limited success. 

@CK1992 I tried with these conditions you just gave:
 

subBC1 := -phi(x, 0)*exp(g(x, 0)*sqrt(x)/(1+varepsilon*g(x, 0)*sqrt(x)));

subBC2 := alpha*phi(x, 0)*sqrt(x)*exp(g(x, 0)*sqrt(x)/(1+varepsilon*g(x, 0)*sqrt(x)))

BCtest := {g(0, eta) = 0, g(x, 20) = 0, phi(0, eta) = 1, phi(x, 20) = 1, (D[2](g))(x, 0) = subBC1, (D[2](phi))(x, 0) = subBC2}

From
 

pds := pdsolve(PDE1, BCtest, numeric, spacestep = .25);

I get the same error received before: too complex!
No wonder though, because your "new" conditions are exactly the same as the old!
Did you copy the wrong ones?

I have reason to believe that that problem is gone soon.

@Parham2016 Since dsolve uses solve for the job, you might as well be using solve.
One note: Remove the tilde after indets.

indets~(eval({E1, E2},B=10)); #returns {{C1,Nu}}
whereas

indets(eval({E1, E2},B=10)); # returns {C1, Nu}

solve wants the latter form. Apparently the double curlies don't bother dsolve.

Why is there only one solution for Nu, C1 for given B?
If so why must C1 be an increasing function of B?
How can you expect to get dsolve to do anything sensible on {E1,E2} ? They aren't differential equations.
##NOTE: I see that you actually do get a result from dsolve.
It never occurred to me to try something like this:
 

restart;
dsolve({x^2+2,y+2},{x,y});
dsolve({y+2},{y});

The first one works, the second doesn't in Maple 2017.3.
I find this inconsistent. I would like the error in both cases:
Skæg for sig og snot for sig! (I won't translate that).

It appears that you are missing a multiplication sign in the very last statement:
 

(`mod`((`mod`(A, n))*(`mod`(B, n)), n))((`mod`(A, n))*(`mod`(B, n)));

Presumably you wanted:
 

(`mod`((`mod`(A, n))*(`mod`(B, n)), n))*((`mod`(A, n))*(`mod`(B, n)));

Besides that I'm lost.

@adxters If that is what you want then it is much less convoluted:
 

for i to n do 
   if H[i] < 2.7 and A[i, f] < 12 and A[i, o] < 1.2 then 
      Q[i, foo] := evalf(610*(A[i, o]*sqrt(H[i])*h[k]*A[i, T])^(1/2)) 
   else 
      Q[i, foo] := evalf(7.8*A[i, t]+378*A[i, o]*sqrt(H[i])) 
   end if; 
   print(Q[i, foo]) 
end do;

Clearly you will need assumptions. Could you provide text instead of an image and information about r, M, and eta, i.e. are they real, or even positive. Is r>2*M or ... ?

@_Maxim_ Yes indeed. Have you submitted a bug report?

@Adam Ledger Sorry, if my formulation was offensive in any way.
I wouldn't reply as extensively as I have if I didn't find your question very interesting.
As I wrote earlier (see above):
" So the question is rather: why is it good (or even necessary) for _Z to be global in RootOf? "

If _Z had been local, then it would be local to the procedure RootOf (or some other procedure called by RootOf).
That would mean that different calls to RootOf would return different local variants of _Z.
To see that take my example above:
 

restart;
## The home made procedure.
## Remark: Notice that rootof has never been defined.
##
R:=proc(pol,x) local _Z; rootof(subs(x=_Z,pol)) end proc;
##
R(x^2-2,x);
z1:=op(indets(%,name)); # The first local _Z
R(x^2-2,x);
z2:=op(indets(%,name)); # The second local _Z
z1-z2; # NOT zero
## The addresses of the two local variants of _Z are different:
addressof(z1);
addressof(z2);

That fact may be a problem for RootOf.

@Adam Ledger If you do this:
 

subs(_Z=myZ,RootOf(_Z^2-2));
%;

you will see that you are back where you started.
Why mess with the design of RootOf?

@mmcdara A way out seems to be to forget about the file TESTproduce.mw and use this version of TEST_Examples.mw instead of the original. No use of unwith, but the reading and modification of the .mla file takes place here:
 

restart;
with(TEST);
TestProcedure();
####### Now change the mpl text file to version 2 and then do:
####### No restart (the point).
read "C:/Users/Bruger/maple/toolbox/TEST/TEST.mpl";
savelibname:="C:/Users/Bruger/maple/toolbox/TEST/lib";
savelib(TEST);
#######
TestProcedure();

@mmcdara I have uploaded 3 files.
TEST.mpl is a text file, which happens to be created by Export as Maple Input (.mpl).
TESTproduce.mw is a worksheet which reads TEST.mpl and produces content for TEST.mla.
TEST_Examples.mw is a worksheet with one restart only.
The assumtion is that the archive TEST.mla has been created in the place indicated.
###
At start I used TEST.mpl as written (Version 1).
In Testproduce.mw I check that it works.
In TEST_Examples.mw I start from the beginning and continue to the line " ####### Now change ... "
Then I change TEST.mpl to Version 2.
Go to Testproduce.mw and check that it works: now printing "Version 2".
Finally go to TEST_Examples.mw (without restarting: the point of the exercise).
Start with unwith(TEST); and continue.
You get Version 1, which didn't surprise me at all.

TESTproduce.mw
TEST_Examples.mw
MaplePrimes won't let you upload .mpl files, but TEST.mpl is just this and no more:

TEST:=module() option package; export TestProcedure;
  TestProcedure:=proc() print("Version 1"); 123456789 end proc
end module;

@Rouben Rostamian  _Z is used by RootOf in e.g. this explicit call to RootOf:
 

RootOf(x^2-2,x);

RootOf( _Z^2 - 2) is returned and _Z is the global _Z.
Compare this to the following

restart;
sol1:=solve(sin(x)=0,allsolutions);
sol2:=solve(sin(x)=0,allsolutions);
S:=indets({sol1,sol2},And(name,Not(constant)));
type~(S,`local`); #{true}
_Z1:=34; #No problem _Z1 is the global _Z1
S; # No change

So it is good that the help page for RootOf points out that the _Z appearing there is the global _Z.
After all _Z could have been local:
 

restart;
R:=proc(pol,x) local _Z; rootof(subs(x=_Z,pol)) end proc;
R(x^2-2,x);

So the question is rather: why is it good (or even necessary) for _Z to be global in RootOf?

@Rouben Rostamian  You wrote:
" The error message that you have shown does not complain about "global".  It complains about "protected".  It may be a global variable, but that's beside the point. "

To that I can only repeat that the name _Z in RootOf is indeed a global variable (and it is also protected). Why protect a local variable? Since the question raised by Adam Ledger was about _Z being global, I cannot see that it is besides the point (as you say).

You may also try
 

res:=solve(x^5+5*x^4+4*x^3+2*x^2+x+9);
indets(op(1,res[1]));
type(op(%),`global`); #Answer true

As is well-known dsolve uses _C1, _C2, ... for arbitrary constants. They are globals, but not protected.
 

sol:=dsolve(diff(y(x),x)=y(x));
S:=indets(sol,name) minus {x};
type(op(S),`global`); # true
type(op(S),protected); #false
_C1:=89;
dsolve(diff(y(x),x)=y(x)); #Now using _C2 because of the assignment made above!