@Axel Vogt Creative approach! (gfun is now a standard package within Maple.)

@C_R I branched it off to here

@C_R Interesting. Yes, the index=real[4] RootOf does not behave like a typical RootOf in some respects. Normally evalf on a RootOf would give a numerical value but here it returns unevaluated.  This would normally be a way to work toward an exact solution, since convert(RootOf(...,numeric value),radical) could then be used.

@sursumCorda A combination of implicitplot (plot_real_curves is sometimes too slow) and algcurves:-singularities can track down the roots. 

Download algcurves.mw

For the second one, there are only singularities, and I'll let you break them down into all the subcases.

algcurves2.mw

@C_R  Interesting about index = real[4]. I've not seen that before in many years using Maple, and the stuff on the forum isn't clear about it being a bug or not. Perhaps it is a bug in the documentation. There do seem to be just six solutions, from plotting the curve with algcurves.

Download algcurves.mw

@Christian Wolinski I sumitted an SCR.

Use the green up-arrow to upload the worksheet.

@tomleslie @mmcdara Well, @nm asked for "a more elegent way to remove any entry in piecewise which has undefined in it". I didn't really answer that for the general case, but did for the case in question with a Heaviside function. As always, Maple considers the general case and one needs to be careful in special cases. I'm sure @nm will consider that. However, in the context of laplace transforms outputting the unit step function is fine because integrals are involved. In fact taking the Laplace transform of the different outputs gives the same answer:

Download Heaviside.mw

For the general case, Maple straddles the two extremes of treating Heaviside as a function or a distribution, and so for other applications I agree the unit step function might not be appropriate.

@Rouben Rostamian  In Maple 2022, ?coords takes me to a very helpful page "Coordinate Systems Supported in Maple" which makes this clear. (This page wasn't so easy to find in the online help.):

"(**): There are two widely used conventions for how to represent spherical coordinates: one is used more in physics and the other more in mathematics. The only difference is a swap of the second and third coordinate: the vector represented by 
                           "u, v, w"

 in one convention is represented by 
                           "u, w, v"

 in the other. The plotting library, the changecoords command, and the VectorCalculus package allow you to use the coordinate system names spherical_math and spherical_physics to refer to these coordinate systems unambiguously. You can also use the name spherical; its behavior is as follows:
– If neither of the Physics and VectorCalculus packages has been loaded (using the with command), then the plotting library and the changecoords command will interpret spherical as spherical_math.
– If either of the packages Physics or VectorCalculus has been loaded, then the plotting library and the changecoords command will interpret spherical as spherical_physics.
The VectorCalculus package will always interpret spherical as spherical_physics.
 

@Ahmed111 Well, Maple is often a bit inscrutable about the way it does things. Here's my guess. The first time, Maple always found the lambdas together, e.g., (lambda__1-conjugate(lambda__2)) and so kept them together. But the second time, you have things like phi2 or conjugate(psi2), which now have polynomials in lambda__2 or its conjugate. Now I might look at phi2 and conjugate(psi2) and try to combine them (they are very similar after all, but not conjugates), which might give a shorter expression if split into real and imaginary parts.

If you don't want Maple to combine them, just call them something like lambda__1 and clambda__1 until the end of the calculation and then substitute back.

But at some point, you have to decide what is acceptably simple, and Maple might not agree (or at least without contortions).

@arashghgood You needed list1[i][2] instead of just list1[i], and numeric rather than numerical.

ode.mw

@arashghgood I'm confused about what you want. You talked about residues - do you want to do a contour integration? if so of what function - Q, deq? - which contour? upper half plane? That can probably be done.

How exactly was the plot in c made? I think by numerical solution of the same differential equation? if you want to exactly replicate that then it would be helpful to know the method, stepsize, hardware precision, exact initial conditions.

Perhaps a step back to tell us where is problem came from and what you want out of it would be helpful.

@arashghgood You can try stiff methods other than the default resenbrock one, e.g. lsode. You could put Digits higher for more accuracy, but it will get very slow. In combination with the transformation method to add a small imaginary part you may get closer to what you want. I don't really understand what you are expecting - near a sigularity inaccuracy seems inevitable.

@arashghgood Stiff method seems to work here, without transformation. (just plotting real and imm parts of Q)

Download ODE.mw

Edit: at least for the second case. For the first, it varies depending on the exact values of the ic.

@arashghgood  The dchange can be done more simply by 

ode2:=PDEtools:-dchange({K=x+a},ode,[x],params=[a]):

and still using Q. Result is the same. Hard to understand any discrepancy.