@mmiller15 Yes, it's possible, and I'm working on it.

Since v[a]^c*u[b]^d = Vu(a,b,c)*u[b]^(d-1) = v[a]^(c-1)*vU(a,b,d) for all c,d >= 1, why not combine
Vu and vU into a single procedure, VU, defined as
VU:= (a,b,c,d)-> v[a]^(c-1)*vU(a,b,d)
or
VU:= (a,b,c,d)-> Vu(a,b,c)*u[b]^(d-1) ? I think that those two must be equal if your system is consistent. Thus, you only need 3 procedures, not 6. Am I missing something?

@mmiller15 Do you want to always apply all 6 transformations at once? Or do you want to be able to specify which of them to apply?

Your use of map in this case is superfluous and quite confusing to the reader. The command

map(f, (q-> ...), e)

is always equivalent to simply

f((q-> ...), e).

This is because a procedure or arrow expression such as q-> ... is not something that can be "mapped over". (In Maple-speak, such an expression is called atomic.)

@ecterrab Yes, I see it now: The `@@` expression is in prefix form. My reading of it was hampered because the backquotes that usually signal a prefix-form operator do not appear in the prettyprinted form of the expression.

@ecterrab Your solution contains a subexpression of the form

(t^n)@@(U-> ...).

I am of course familiar with F@@n where F is a procedure and n is an integer. What does it mean when F is algebraic and n is a procedure?

This'll be easy to do with a single evalindets command. I'll show you how to do it, but I need more information first.

1. What are the allowed values of c? Do they include 0? negatives?

2. Are subscripted variables formed as v[a] or v__a? If you don't know, then look at them with lprint to figure it out.

3. You mentioned non-commutativity. What do you do to distinguish v[a]*u[b] from u[b]*v[a], which Maple considers identical expressions?

4. Should v[a]^c*u[b]^d be treated as (v[a]^c*u[b])*u[b]^(d-1) = Vu(a,b,c)*u[b]^(d-1)?

@vv Sorry, I did not intend any offense. I simply thought that you were claiming that it was necessary to perform these computations at huge values of Digits in order to obtain a result accurate to some small number of digits.

It has always been a serious deficiency of fsolve that one can't set the number of "guard digits" as one can with RootFinding:-Analytic, RootFinding:-NextZero, and `evalf/int`. Thus fsolve guesses at a number of guard digits to use. It insists that its returned result be accurate to Digits. The end result is that there are problems for which the values of Digits for which it converges are essentially random.

Another command with the same problem is `evalf/sum`.

@vv I may have overlooked it, but I fail to see the part of this thread where anyone other than you actually wants a result accurate to 5000 digits. Rather, it seems to me that some have claimed that it's necessary to use a ridiculously large value of Digits (like 5000) to compute a result accurate to some reasonable number of digits, like 20.

@mehdibaghaee Actually, Tom's first set of commands will also produce the results that you want. At first reading, I hadn't realized that that first set also started with the Array command, which is the crucial difference from your code.

@vv Using Newton's method with Digits:= d is sufficient to accurately solve erf(z) = 1 - 10^(-d).

@Preben Alsholm Instead of using the "magic number" 1e-22*I, I'd rather do this:

restart:
u:= ((-5*ln(x)^4-20*ln(x)^2-8)/120 + MeijerG([[0$2], [1$3]], [[0$5], []], x^Pi)/Pi^4)/(x-1)^2;
ode:= diff(y(x),x) = Re(u);  #*** Notice the Re. ***
res:= dsolve(
   {ode, y(.4) = 0}, numeric, 
   output= Array([.6]), relerr= .5*10.^(1-Digits),
   method= dverk78  #*** Notice the relerr and method. ***
)[2][1][1,2];

Result:  -0.555168769092963e-2

Default method rkf45 gets fewer correct digits.

@mehdibaghaee If you use Tom's second set of commands, then Wn[0,0,1] will return 3.

@Markiyan Hirnyk Vote up. This is a very useful method to keep in mind. The accuracy that you achieved is amazing considering your very large epsilon. Using default epsilon, it uses about 3 times the effort (set infolevel[`evalf/int`]:= 5 to see that), but it only makes a difference to the least-significant digit of the result.

How did you come to choose such a large epsilon?

@Rouben Rostamian  Thanks, that was a very clear explanation. Vote up.

@Rouben Rostamian  I don't see the relevance of finding the values of x that simultaneously make both the first and second derivative 0.