@Scot Gould 

I started out just trying to mention that using odeplot is generally better that plotting extracted procedures/functions via the plot command. I'm pretty sure that that generally true, even if in practice it's just means that it's faster.

And then I digressed about the output choices, sorry! I'm sure there's no issue with our disagreeing about how hard or error prone manual use of the default output=procedurelist might be. Comparing those two output choices is a sidebar here.

I wonder whether it might be nicer if odeplot could use pi-ticks automagically on a relevant axis, say if either component of the "view" (eg. [x,y(x)] or [y(x),x)]) were simply the independent variable and the supplied range involved multiples of Pi.

@Scot Gould The dsolve,numeric command does not return a "solution module". That's not correct nomenclature, sorry. (It is pdsolve,numeric which does that.)

By default (output=procedurelist) it returns a procedure which when called with a numeric value then returns a list of the results.

Using output=listprocedure it returns a list of procedures which when each called with a numeric value return the corresponding result.

Extracting final values from either approach can be done using eval, with strong similarities. Eg, for a single value of the independent variable,

de := {diff(y(t),t,t)=cos(t),y(0)=1,D(y)(0)=0}:

solsPL := dsolve(de, numeric, output=listprocedure):

eval(y(t), solsPL)(2.4);
                        2.73739313285275

solLP := dsolve(de, numeric): # default output=listprocedure

eval(y(t), solLP(2.4));
                        2.73739313285275

One difference is that with output=listprocedure the extraction (eval) can be done just once (per dependent function), up front, and then utilized for multiple values of the independent variable. For some people that's an advantage, since in contrast the output=procedurelist return needs extraction (eval) for each value of the independent variable.

As for procedures which one could pass to the plot command and get the pi-tickmarks on the first axis due just to the choice of supplied range, well, that too can be done for either output form. It's only slightly more effort to build such a "function" from the dsolve return in the output=procedurelist case. But stand-alone procedures can be had from both approaches.

YPL := eval(y(t),solsPL):
YPL(2.4);
plot(YPL, 0..4*Pi);

YLP := s->eval(y(t),solsLP(s)):
YLP(2.4);
plot(YLP, 0..4*Pi);

I'm not sure that I understand why the latter of those might be taken as significantly harder to remember than the first. It's a little more effort.

Note that with either of these output choices the odeplot command will more generally produce a better plot, and more quickly, that will another plotting command such as plot. For the OP's simple example there may be no easily discernable difference.

So I would say that in general it is better to specify the pi-ticks in odeplot then it is to utilize the plot command and get any pi-ticks just be virtue of the particular supplied range.

There are some alternatives which deal specifically with each axis separately.

For the horizontal (first) axis,

  xtickmarks = piticks

or,

   axis[1] = [tickmarks = piticks]

See also the Help page for tickmarks.

I got the impression that this talk was by a member of a team that is working on enhancements to that package's functionality, and that the video is showing current results of that. In other words, it seemed to me like a report on current progress, which might have attained since the last major Maple release.

This supposition seems (to me) to be borne out by the speech and text appearing between 33:00 and 37:00 in the video.

ps. The presenter works with ORRCA, and there are tie-ins between that group and development of Maple's RegularChains, etc. This is one of a few research groups which contribute to Maple. It's quite common for such conference talks to show current development.

@Eunsang 

1) You write of problems when you make the step timestep too large. You also write of wanting, "higer [sic] spacestep". Are you sure that you don't mean smaller?

1) What is the specific desired spacestep that you want?

2) Do you know what timestep you want to use? Or do you just want the smallest timestep for which the computation is quick enough, when using your target spacestep? How fast is fast enough?

3) Are you seeing aspects in the plot that seem qualitatively wrong to you, due to, say, overly coarse step sizes?

4) You wrote, "I tried to find the optimal plotting points by adjusting the timestep while maintaining the desired spacestep...". What does "optimal plotting points" mean, exactly?

5) Do you have concerns about the scaling in your system, or suspect numeric difficulties due to inadequate working precision?

6) Your constant values contain floats like 0.33 and 3.14.  Are those coarse approximations of 1/3 and Pi? Do your have more accurate values for any of the floats and, if so, any reason not to use them?

@Blanc 

Download s_k_2023.mw

@Gabriel Barcellos And yet you seem to be asking how you might make something occupy a common physical distance on different screens regardless of their respective resolution settings.

Your request contains a contradiction.

@Gabriel Barcellos Do you believe that you can control the resolution of other people's computer screens?

@Ronan The Vector(n) is also a call to the Vector constructor, as well as a type.

If you want to use it as a type, in an argument to the type command, then you need to keep it as that (literal) unevaluated function call and prevent it from evaluating and becoming an rtable data structure.

Try it instead as either
   ''Vector''(n)$1    # 2 nested pairs of single right-ticks, not quotation marks
or,
   'Vector'(n)
so that type receives the unevaluated function call in the argument.

Ronan_tp_ex.mw

@C_R When you first wrote your Question (and I replied) I overlooked the mention at its end about dsolve,numeric. Sorry.

If I'd realized that then I would not have suggested your 3rd approach offhand. I'd almost always prefer using odeplot rather than the extracted procedures -- if time/memory efficiency were especially needed, or if animations were the result. It's not just how odeplot efficiently uses/re-uses dsolve's the constructed piecewise interpolants; it's also basic stuff like not bouncing around to poll independent (time) values (that 1D plotting can do) without any the right constrained purposes, or crudely forcing regular spacing even when it doesn't help (ie. ignoring curvature) when using spacecurve + extracted dsolve procs, etc.

@C_R 

In your attachment the two animated portions don't interleave rightly, in the sense that both were created for t=0..10, and presumably are wanted by you as sync'd when combined. That's because they don't have the same number of frames; only one has 150 frames. The one with fewer frames is crammed into the front portion of the other. Are you aware of this?  Is that your question/problem?

Also, is there a reason not to use the background option of animate?

Is it a problem that the overall construction is too large in memory or structure size? Or for any of the three portions? If so then can you bear to have a slightly less smooth curve, as t gets large? If you don't need to export then could you animate via Explore instead, so that only one frame is constructed at a time and memory usage is reduced?

I'm not sure what exactly is your question now.

If this is a very large animation then I suggest that you try:
1) remove all output from the worksheet
2) export the animation to .gif, and attach that after the worksheet

Or, just do 1).

We might have to re-run it, but at least we can make progress on helping with additional aspects.

@salim-barzani You wrote, "you did a great job but why forget a code for finding the parameter automaticaly at the matrices, i didn't know where i should rename and say find thus parameter if you do that it will be so good and if you do odetest like this stuff just you can do it will be ultra hight level code".

I didn't "forget" anything. I may have not done all you hoped for, but I didn't forget.

Your phrases, "...finding the parameter automaticaly at the matrices" in unintelligible to me. How you want to use all this with odetest is unclear. I didn't do those additional things you see to want because your mere hints about their nature are insufficient for me to understand the precise goals.

It's not just that the explanation is insufficient. It's almost nonexistent.

If you properly and adequately explain what more you want to do with this then I might try it. Fragments of your own code which don't accomplish your task are not an adequate explanation.

Which two of names present in expression M are going to be used as the plotting variables in plot3d?

Note that (in addition to mistakenly trying to use B[1],B[2] as the procedure's parameters) your substitution list doesn't all match the actual names present in expression M. The number of them is not right. The pairings are not right.

We can't fix it properly without knowing/guessing which two are the dependent variables for the plot3d.

Do you want the spinning cube to get its snapshots with the same frame-rate as the traced objects (time-dependent spacecurves).

Without a specific example I'd be tempted to go for the third option.
[edit: when initally I wrote this I'd completely missed the detail that the OP was intending the spacecurves to arise from dsolve/numeric results. Sorry. With that knowledge I'd prefer the 2nd approach offhand, using odeplot for the portion involving such curves.]

Do you think that the time to construct the animation will be a concern?