@salim-barzani 

graph_in_simple_shape_acccG.mw

@salim-barzani Please don't spawn yet another Question thread on variation of the Explore use I just showed above.

Instead, you could just put your followup in a Reply here.

@Paras31 Regarding your followup query 1) immediately above, I would first observe that even for,
   plots:-odeplot(sols, [t, U[67](t)], t = 0 .. 10, color = "green")
I get a more convincing and plausible plot if I called dsolve with stepsize=0.5e-5 rather than 0.5e-4.

So I am suspicious that the results even out as far as t=100 might be inaccurate. (I find it difficult to investigate, because it's time consuming. I worry about numeric error effects, limitations of the forced method, and who knows possibly even stroboscopic mirages.)

The smaller forced stepsize has another effect; it pushes out further the time at which that "cannot compute further..." error message might be a problem. But it also makes the computation slower.

On my Maple 2024.1 on Linux I can recover some timing performance here by also passing the compile=true option to dsolve.

So, for fun, you might adjust along these lines: v1_1_1_ac1b.mw

An animation from that, which looks plausible: (This is 200 frames. at 400 frames it's even more convincing. So this seems to be reasonably accurate out at least to t=10.)

ps. There's an old joke about computing. "Speed, robustness, flexibility. Pick two." Here I worry that your situation might be, "Speed, accuracy, ability to compute. Pick one-and-a-half."

Having said that, you haven't actually stated outright 1) whether you think your results were already all accurate (I doubt it), 2) whether you're actually striving for accuracy out for large t, or not, and 3) whether you're forcing rkf45 so that it might be more sensibly compared to solvers in other software, and so on. You haven't provided much in the way of explicit requirements. (For all I know, you might be studying the "apparently chaotic" effects of accrued error here.)

@Paras31 For your query 2) it looks like your two calls to plot U[67] are not the same. The second attempt is not a repeat of the first. It uses a different range.

The first has a range that in 2D Input looks like,
   0...58
which as 2D Input parses to 0 .. 0.58
But your second has,
   0..58
which is the range from 0 to 58.

Please don't spawn yet another wholly separate Question thread on the code shown here.

If you have a followup query (such as on the performance of code given here), then you can ask about that here in a Reply.

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

AFAIK there is no limit (outside of memory and cpu resources).

I have spawned many concurrent commandline-interface (CLI) instances, without problem, on each of Windows, Linux, and OSX.

But, might there not be an optimal number, depending say on the number of cores/(hyper)threads?

@salim-barzani It's not clear what you mean by, "parameter search automatically".

If you want to play around with the effects of the parameter values on the plot, then you could try the Explore command.

graph_in_simple_shape_acc.mw

But I don't see how "parameter search" is meaningful without an explicit goal for which you're searching. What is your goal?

It is unclear what question you might be asking.

@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.