s:=solve( (1/((1/R2+1/(1.5*10^6))*(1/(1/R2+1/(1.5*10^6))+2.45*10^3-R2)))=Vo, R2);

s[1] and s[2] are  two branches i.e. R2:=s[1] and R2:=s[2]

P.S. Next time to be more clear write depndency in next way:

for given V0=V0(R2) find R2=R2(V0)

That's why (but not maybe only) coryphaeuses prefer classic interface. But it's not my case, i have different GUI components from DocumentTools package on my sheet, so there is no way to simply change interface.

------update

Sorry, there is also CLI option i.e. command line interface. OK, it could be case

ReassumeVars:=proc(pallconditions)
  local li, lvar, lcondition;
  global DummyVar;
  #
  for lcondition in pallconditions do
    lvar:=eval(op(1, lcondition[1]));
    for li in anames('user') do
      if not type(eval(li), procedure) and has(eval(li), eval(lvar)) then
        assign(li, subs(eval(lvar)=DummyVar, eval(li)));
      end if;
    end do;
    assume(lcondition[]);
    lvar:=eval(op(1, lcondition[1])); # lvar before not valid anymore!
    for li in anames('user') do
      if not type(eval(li), procedure) and has(eval(li), DummyVar) then
        assign(li, subs(DummyVar=lvar, eval(li)));
      end if;
    end do;
  end do;
end proc:

- is it OK? Can you suggest smth else?

Procedure above fails.

Want after next operators:

assume(a>0);

b:=a;

ReassumeVars([[a<6]]);

b again have VALID value of a and condition on a will be :
 is assumed to be: RealRange(-infinity,Open(6))

Clare So 70 :

Didn't check your case but i'm doubt that i can run smth from command line when  kernel is down. I actually found better way. Just save worksheet itself and on the reopening (with new mserver process) just assign name to output - there is a such option on the right click on output. Much faster.

string-to-names is workaround.:

assign(convert("a",name),convert("a",name))

universal one-line solution:

p:=`codegen/packlocals`(p,[op(2, eval(p))], LocalArray):

Everything works so far!

Still noone? I still don't know answer

Ah, found. I didn't see manipulator because my table had only one column

After understatnding that fsolve/sysnewton called and checking it

i see such peace of code:

      for it2 to 10 do
        lsub2:=seq(lvars[k]=x[k] - C[k],k=1..n);
        if Bproc then
          valsub2:=op(map(x->rhs(x),[lsub2]))
        end if;
        if not `fsolve/checkrange`(lsub2) then
          if 5<=it2 then
            for k to n do
              if not `fsolve/checkrange`(lvars[k]=x[k] - C[k]) then
                C[k]:=0
              end if
            end do;
            if C=[`$`(0,n)] then
              it2:=11;
              break
            end if;
            C:=C*factorial(it2);
            it2:=0;
            next
          else
            C:=C/(it2+1);
            next
          end if
        end if;
        if Bproc then
          B2:=traperror(evalf(leqns(valsub2),Digits+n));
          if not type(B2,'list'('complex'('numeric'))) then
            error "procedures don't evaluate to numeric types."
          end if
        else
          B2:=traperror(evalf(subs(lsub2,leqns),Digits+n))
        end if;
        if B2=lasterror or isreal and hastype(B2,nonreal) then
          C:=C/(it2+1);
          next
        end if;
        aB2:=add(abs(Re(z))+abs(Im(z)),z=B2);
        userinfo(2,fsolve,`new norm:`,aB2);
        if aB2<aB then
          break
        end if;
        C:=C/(it2+1)
      end do;
      if 10<it2 then
        break
      end if;

----------

So, 10 subiterations done with hope that norm simply will reduce (aB2<aB)! And if not (it2>10) then just go to new initial guess. That's why on practice some functions don't work. Because you have just two limit points instead of one with relatevely big norm of them difference due round off. It's not shame to have such errors, in my case i saw such situation under debugger only. But it rather shame not to repair them since 1996 in code that so "most wanted".

@Alejandro Jakubi 

Unfortunately we cannot judge wheather code commented well or not. I mean eval itself trancates all comments :(

Besides not rewritting such most wanted parts is terrible itself. Why such decision made? Thinking about "backward compatibility"? It's wrong case. Best case for "backward compatibility" is just for clients to not upgrade them maple release. As unix kernel do. Unix popular and works only because

1) everything is updated starting from kernel

2) admins are not run to upgrade them system if new kernel released.

Didn't found nothing better than to write my own (Robert Israel's one unfortunately doesn't work too)

FSolveAll:=proc(eqns::{equation,algebraic}, eqvar::(name = realcons .. realcons),
  InitConditsCnt::integer, DoError::boolean)
  local lAllPrevSols, lAvoided, lCurrSol, li, lisseq, linitval,
        lfrom::realcons, lto::realcons, lvar::name, lonesol;
  lisseq:=proc(pargs) return nargs; end proc;
  lAllPrevSols:={};
  lAvoided:={};
  lfrom:=op(1,op(2,eqvar));
  lto:=op(2,op(2,eqvar));
  lvar:=op(1,eqvar);
  for li from 1 to InitConditsCnt do
    linitval:=lfrom+(lto-lfrom)*(li-1)/(InitConditsCnt-1);
    lCurrSol:=fsolve(eqns, lvar=linitval, avoid=lAvoided);
    if (lisseq(lCurrSol)>1) or type(lCurrSol, float)  then # one or many roots => convert to set
      lCurrSol:={lCurrSol};
      for lonesol in lCurrSol do
        if type(lonesol, float) and evalb(lonesol>=lfrom)  and evalb(lonesol<=lto) then
          lAllPrevSols:=lAllPrevSols union simplify({lonesol});
        end if;
      end do;
      lAvoided:=lAvoided union map(lz->lvar=lz, lCurrSol);
    elif (lCurrSol=NULL) then ; # nothing to do
    elif type(lCurrSol, function) then
      if DoError then
         error("Cannot FSolveAll");
      end if; # otherwise nothing to do
    end if;
  end do;
  return lAllPrevSols;
end proc:

In spite of union, simplify and avoid operators/options presence, roots are not unique. To get unigue set additional cryterion based on "eps" should be applied. Works for one variable in my case works great.

Run gc()! Already checked on EvalMapleProc from c. It works.

P.S. Problem not in neither evalhf nor in _d01akc itself. NAG itself is very good. Problem in native eval environment. And you must eun evalf because Int itself  not accesible from evalhf environment.

after calculation of end value of 'H' one can obtain a list to forget:

map2 (op,0,indets(H, function))

ldegree :)))) One more stone. 
Instead of it now i prefer my own 'j' calculation. 

It was wrong because coefficients, that calculated, wasn't simplified, 
so wrong value returned. 
And from multiseries to polynom. intermediate 'series' call doesn't help. O-term remains. 
It's not so easy :(
Diff(...,y)+eval(...,y=0) could be case!