@Paras31 It's confusing if your worksheet assign any numeric value to that name.

Your equations appear to contain the name,

   `#mover(mi("δ",fontstyle = "normal"),mo("ˆ"))`

(which pretty-prints like delta with a circumflex accent above it).

But that doesn't seem to be assigned any numeric value. Have I missed that assignment? If not, then what is its value?

@AHSAN You can add any column you want.

What's your explicit definition of the "residual" here? Use that.

@jrive I am going to submit a (likely duplicate) bug report on the following weakness, which characterizes an underlying weakness in simplify.

Download simp_weakness.mw

@jrive If F (the denominator, say) is obtained as the common multiplicative term that one wants to distribute through the sum (numerator), then I've showed that either of the following attain your target,

   map(`/`, Zin*F, F)
or,
   expand(Zin, F, op(Zin*F))

I picked off F as the whole term in the denominator. And of course that involved no up front check that it were indeed a "common" (multiplicative) factor that could be usefully cancelled via distribution through the numerator sum.

ps. The reason that I originally went with collect is that it sometimes happens that a judicious collect call gets a more compact result than does simplify(...,size). I have a hard-working compactifier oracle that looks for such, by trying different variable choices and followup coefficient-action (3nd arg).

The form of your target expression (and my interest in finding a shorter/shortest form) made me think trying collect first. In contrast, the form of your input expression leads more to using a distributed multiplication or a controlled expansion -- but one has to "see" that it'd work.

A variation using a controlled expand.

The subterms not to expand are determined according to sign of power (ie, in denominator or numerator).

The use of op here does not contain an ad hoc positional determiner. It simply gets all summands of the numerator.

Download expand_ex.mw

More general use would also involve checking the form, ie. a type-check as to whether the numerator were indeed a sum, etc.

@C_R In my earlier Reply I already had a more programmatic variation of,

   F := 1/op(2,Zin):
   map(`/`,Zin*F,F);

That might be shortened further to,

  F:= op(2,Zin):
  map(`*`,Zin/F,F);

where the main difference was that earlier I programmatically extracted F the (unexpanded) denominator whereas your approach merely picks both it and the remaining numerator off as an operands whose ordinals are determined by eye.

Using such manual determination of the denominator is not of general use. Also, there could be a numeric coefficient, or multiple factors in the denominator, etc, in which case the op determiners (1st argument) would need to be different.

See also my followup Reply about using a controlled/restricted expand instead of a mapped multiplication.

@janhardo I put it back in as the original float, to avoid confusion.

With our hands on the denominator (unexpanded, and also the "common" term), then we could handle this particular example like so.

Download collect_ex6.mw

I ought to point out that this does not systematically check for the particular form that allows this to work. Without such a systematic process I label this as ad hoc.

Since the cited target result is not the simplest form possible then defining such a systematic process ought to be preceded by a clear definition of the candidate form. (I think I see one.)

On the other hand, the choice of variables that were used earlier is also an ad hoc aspect.

@nm 

Yes, Mma's simplification is ok. But the following is even simpler.

I can get that with a minor variant. (I didn't before; it was not the OP's target.)

ps. quibble: I notice that you changed the 0.01 to 100, in your Mma example.

@jrive I'm sorry that my effort is so looked-down upon.

Personally, I find the following to be slightly complicated but not advanced.

or,

I made an effort to not have those irritating float artefacts.

I also made an effort to explain the extra steps I took to work around issues (eg. collecting wrt I, the float contagion, etc).

On the bright side at least it isn't one of those very poor and ad hoc solutions involving op and by-hand/eye picking of operand numbers/positions. That's a nearly useless approach!

You tagged this with simplify. But if you're attempting some notion of simplification then why does your target form not have the L1 (or L2) factored out of some subexpressions, eg,
   omega*L1 - omega01^2*L1/omega
instead of,
    L1*(omega - omega01^2/omega)
?

I'm just curious. The target can be attained using collect as the main tool. But I want to be sure that I am using the right target.

Also, it looks as if the Rac term was just some typo.

@C_R The particular error message shown by the OP is not the primary issue. The outer integration won't succeed as intended without proper syntax, which it lacked by having an fdiff call as first argument and a bare range as second argument. In M2024.1 one might get back, say, an unevaluated int call, say, but such a result is not meaningful or useful.

Numeric integration is wanted in this case, as part of this described exercise. And one can enable that here by one of these 1) using the numeric option to lowercase int, 2) making the upper bounds passed to int be numeric floats, or 3) invoking evalf(Int(...)) instead. So that's one aspect.

Another aspect is to also repair the syntax for the arguments passed, and fixing that is required if a float result is wanted. That can be achieved for all three of the above approaches, by using an operator for the first argument so that the x value used in each fdiff call is an actual numeric value, as I mentioned in my Answer. That happens to succeed (slowly), even with stock options, for this given example and time-value t=0.

Ie, using,
   x->fdiff(sol(x, t), [t = 0]), a .. b
as first arguments for all three,

Download pde_num_e2.mw

@mmcdara Thanks, that's the kind of thing I'd surmised. But the numeric requirements are imprecise.

My concern is that such a process is not a test of only the numeric pde solver. Its results rely upon not only behavior of the three different & separate numeric solvers I mentioned but also upon their interplay.

Failure to attain some (as yet unstated) degree of numeric accuracy cannot therefore be a proper gauge of numeric performance of any of sole component part of that process. Eg. failure might say nothing about the numeric pde solver alone.

I supposed that accuracy of the integration step would need be coarser than that of the diffentiation step, that in turn being coarser than that of the pde scheme. But the particulars of that might need be problem specific. And attaining an upfront, explicit, accuracy goal might need per-problem tuning at any/all of those levels.

@GFY By the way, it is also possible to do it with fsolve (as a modification/correction of the earlier attempt). Here, I augment with undefined, for the absent root values.

You can also scale any you choose, eg. by 3.

I use option remember to avoid calling fsolve multiple times for the same input (ie. same omega__v, or r, value).

You could make this more sophisticated.

Download fuxian_ac2.mw