@mmcdara

First, please note that the first sentence of my Answer is specifically about the fact that this simpler approach is possible. As it stands, of course, the extra locals and assignments are wholly unnecessary.

Second, I supposed that he has some further purpose, as yet unstated by him. I supposed that perhaps his actual intention is to have his procedure manipulate its parameters (arguments) DVA,RV1A,RV2A and then assign the modified ones to locals DV,RV1,RV2 and utilize those in the plotting.

Third, his code already had lines that appeared to be possibly for such assignment.

So I went along with that aspect of what he already had.

[edit] At first I wondered whether he could instead use DEplot. I didn't notice that the symbolic solution makes the left end-point easier to deal with. I think I see better now why he'd made the custom procedure. (I don't know whether he'll also want to handle odes without an explicit symbolic solution...)

I've changed your Post into a Question.

Please put any followup queries on this here, instead of spawning wholly separate new Question threads on it.

Duplicate Question threads get flagged as such and may be deleted.

It seems that this dies when attempting to convert to parfrac.

@sand15

It seems that OuterProductMatrix may be measurably faster than KroneckerProduct in the case of symbolic entries. For float[8] Vectors it's much closer.

nb. Switching the other of the arguments seems better than transposing either result.

The `.` variant ends up calling OuterProductMatrix, with a tiny extra bit of overhead to get there (and less flexibility w.r.t. transposing).

@Carl Love It appears to work in Maple 2019.2.1 onwards.

@Carl Love Indeed.

In my Answer I had mentioned that  evala(simplify(expr))  would produce -2/7 back in Maple 2022.2.

As Austin mentions, in Maple 2024.0  simplify(expr)  no longer throws an error (or crash).

I have deleted a duplicate of this Question's thread.

@nm A short variant on your suggestion,

   sort(X,key=(u->parse(String(u)[2..])));

@sand15 The OP has asked a similar question, before. 

The OP's attempt to interpolate this meagre 11x20 grid of data may be ill-judged, with data values that vary so much. The attempt at cubic interpolation may be a poor idea here, introducing large (in magnitude) negative swings that don't characterize the actual data supplied.

@nm Ronan's line,
    use RealDomain in (maple_sol:=solve(eqx,[x]))[] end use;
appears to have misled you.

All that does is this,
    maple_sol:=RealDomain:-solve(eqx,[x])[]

The use...end use mechanism is not a universal way to change the bindings or values of things not present in the input. That's not what it's for or how it works. It's not going to change the value of "solve" or anything else that's already explicitly part of the body of a Library procedure (like PDEtools:-Solve or its internals).

Your "update" portion's example involving,
    use RealDomain in (PDEtools:-Solve(eqx,x)) end use;
does not exhibit a bug.

Download use_misuse.mw

@jalal 

S5StatBoxPlotBtestNew_ac.mw

A bug report has been logged.

This looks to me like it might be an oversight, and I don't think that I prefer it. I've submitted a message of inquiry.

Also, I'm not sure I like this related new variant (even though simplify will turn (x^2)^(1/2) into abs(x) under the real assumption, and has done for ages, and that's fine).

Download simp_2024_ex0.mw

@Ronan I terminated the statement (that contained the procedure call) with a full colon.

That suppresses printing of the return value, as output.

The flavors of visual side-effect (here, tabulated display) is however unaffected by the statement terminator of the proc call.