Does this work for you? (Check that it makes good sense. It's late in the day...)

Download how_to_verify_parametric_solution_to_ode_ac.mw

You have defined the substitution equation T1 as,

   T1 := u(x, t) = U(-t*v + x)*exp(k(t*w + x)*I)

where you are missing a multiplication symbol between the k and the opening bracket. That gives you a function call k(t*w + x) , ie. a call to unknown function k. When you then substitute into the derivative wrt t the chain rule applies, and you get D(k)(...) terms.

You may have intended, instead,

   T1 := u(x, t) = U(-t*v + x)*exp(k*(t*w + x)*I)

Download tr_ac.mw

Is this something like you what you're after, without the fractions? (Below are two ways, for this example)

Download B-R_ac.mw

> restart;
> kernelopts(version);
   Maple 2025.0, X86 64 LINUX, Mar 24 2025, Build ID 1909157

> A := -x*(x - 4*exp(x/2) + 2):
> B := x*sqrt((-8*x - 16)*exp(x/2) + x^2 + 4*x + 16*exp(x) + 4):

> simplify(simplify(A-B, {exp(x)=exp(x/2)^2})) assuming x::real;

                    0

Another way to forcibly attack the issue,

Download nm_simp_exA.mw

Naturally, many such temporary replacements may be constructed in an ad hoc manner. How well the system might be taught to do it automagically, I don't know.

Download inert_gt_latex.mw

You posited, "It seems Maple like to make everything  based on "<" internally and that is why it reverses it?". Yes.

You can easily form a similar rule to sustitute in the reciprocals. And you could also use both within the single subs call, to avoid having to distinguish which is present (or even if both are present).

Download subs_ac.mw

One fault seems to be that the derivativedivides method fails for integrand_2, while it succeeds (and produces that simpler result) for integrand_1.

A second fault is that int returns the result with ln and I=sqrt(-1) (which can obtain from the risch method) for integrand_2 instead of returning the better result from the orering method. The orering method's result is longer, but doesn't contain I or ln, and can be simplified directly to the short result using merely the normal command.

Download int_weakness_02.mw

There are at least two parts to this Question.

1) Your evalf (at default Digits=10 working precision) does not produce 10 accurate
digits of an apprximation of the second exact root obtained by solve. Substituting
the poor root approximation happens to also produce zero in the denominator.
But substituting a more accurate approximation happens not to.

2) Your plotting problem is the same as in one of your earlier Questions from today. (This site has faulty inlined display of the worksheet below, but my actual worksheet contains the adaptive=true and smartview=false options.)
 

Download plotq_ac.mw

The small imaginary components of your result can be seen to be an artefect of solving a cubic in terms of radicals, and then computing as a floating-point approximation (in which case the small imaginary artefacts don't vanish due to floating-point concerns -- roundoff error, loss or precision, etc).

You can read about the notion that the purely real roots of some cubics may not be expressible in terms of radicals without the "I" (ie. sqrt(-1)) being present. But a reformulation in terms of trig expressions can get a form in which "I" does not appear, and for which floating-point evaluation produces no such small imarginary artefacts.

Download concentrations_ac.mw

I marked your Question to be Product=Maple 2022, since that's the version in which your attachment was last saved. It'd be more helpful if you could mark the Product version yourself, for future Questions.

In Maple 2022 your examples are running into issues with the (then new) adaptive=geometric default, and/or the default smartview=true option. Some improvement might be had automatically in the newer Maple 2025.

Each of your examples can be forced to comply (in versions M2022 to M2025) by adjusting those options:

Download plotatzero_ac.mw

You asked how to set the Output display to "Maple Output". But that's not the right value for the setting.

From the menubar, you can set it as,

    Tools -> Options -> Display -> Output display -> 2-D Math

where the drop-menu item would be "2-D Math" instead of "Maple Notation".

Then close the popup dialogue with the "Apply Globally" button.

ps. I too have seen this setting get undone, in rare cases. I sometimes wonder whether it can go awry because there is also a programmatic interface(prettyprint) access to it.

Does your code function as you expect if instead you have that as,

   Object('A':-foo_type)

In Maple 2024, under Tools->Options from the menubar, you could do the following:

1) Choose the tab "Interface", and inside that toggle the drop-menu for,
      Default format for new worksheets
to Worksheet (ie. not Document).

2) Choose the "Display" tab, and inside that toggle the drop-menu for,
      Input display
to Maple Notation (ie. not 2-D Math)

Then close the pop-up Options window by clicking on the button "Apply Globally". That should then make this the default, ie. even if you fully close and relaunch the Maple GUI.

The effect of these, together, is that your inputs will be in red plaintext, ie. Maple Notation mode -- with the red chevron -- in Execution Groups (just like Maple 8 and earlier). It won't be black, marked up 2-D Input math mode in Document Blocks.

This is the prescribed way to get such changes. You don't need any special Style Set or such, to get the red color for plaintext Maple Notation input code.

You could also look at the Help page for topic documentsvsworksheets

Hopefully I haven't guessed wrongly about what you're trying to accomplish.

I can think of a few ways to accomplish this.

The first way involves using a different sort call on each of the inner sums (coefficients of the lambda__ij(t) terms). This happens to work for these examples, although in a more general case it could run into difficulties or need even more special handling. This is what I did in the attachment below; it's not completely general code, though it does contain some generic stuff rather than being all ad hoc op stuff.

I could have made considerably shorter code to get this, at the expense of being more ad hoc (eg. leveraging the fact that the problematic sums are the coefficients of the lambda__ij(t) and thus acted on more easily via collect, or using the simple common structure of those sums, etc, etc). I deliberately avoided such here. I find chipping away at the more general problem far more interesting and worthwhile.

NB. Due how sort acts on the uniquified structure stored in kernel memory, invoking the code can actually change part of the original odes, in-place. (Assigning all results to a new variable may not always be strictly necessary, though I do it here.)

Download Format_odes_acc.mw

A second way involves using a single kind of sort call (which is more resistant to some weaknesses of the first way) and produces a uniform ordering with the inner sums (coefficients of lambda__ij(t) terms). The uniformity advantage is balanced by some extra leading minus signs in from of said coefficients. I haven't bothered to attach that right now.

It's a little tricky to code some of this because type(...,polynom) can catch too much in its net. And there are some wonderfully Maple-ish quirks of automatic simplification of coefficients when using collect, and fancy handling. Also fun because sign doesn't accept an order=plex(...) option akin to how sort does.

ps. I changes your original to assign a list to name odes, rather than a bare expression sequence (which I find to be error-prone for some people).