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?

@Jesús Guillera Please put any close followup queries on this here, rather than on a wholly separate new Question thread.

Duplicate threads get flagged as such, and may be deleted by a moderator.

@C_R Some results may be stored in commands below the level of the procedure(s) returned by dsolve, and that can even include evalf (which has its own special kind of remember table).

And there may also be procedures with option remember,system which means that there's a remember table but its results are more transient and can get cleared by a garbage-collection (which can be triggered by memory use amounts).

I put in that 2nd call that you've noticed, because the timing detail you've mentioned is interesting. It's not as much of a gain as one gets by slapping option remember on the very procedure(s) returned by dsolve.

It's been a while since I poked around those procs returned by dsolve, in a comprehensive study. I don't recall full details offhand, sorry.

ps. Side-topic: be super careful/wary of putting option-remember on the returned procs if you intend on using them with dsolve/numeric's parameters option. You'd need to use forget, when changing parameter values on the fly. (As someone here once joked: if you remember to remember then don't forget to forget.)

@Andiguys As that error message indicates, it cannot store the etemp result in M because it is actually and equation of the form,
   delta = some_float
instead of being just a floating-point number.

You probably have seen before that you can get the float value out of such an equation with,
   eval(delta, etemp)

So the problematic line could be changed to,
   M[rr, 1 .. 3] := <Cv | Ce | eval(delta, etemp)>;

Question_plot_cv_ac3.mw

A few comments, if I may:

1) This methodology requires making assignments for each of the "functions" that are needed from the system. For some examples that makes the set-up following dsolve just a bit more work.
2) The original initial conditions need some special handling if you want to see/re-use them after assigning to the names of the functions. Sometimes people use different names, eg. X,Y,etc instead of x,y,etc to avoid this clobbering, but in that case additional eval/subs substitution steps are needed if the desired dependent formulas use the original names.
3) Prof. Gould has re-entered the OP's example original dependent formula in r assigned directly as an operator. But the OP originally gave it as an expression. If one programmatically obtains it as output (from elsewhere) as an expression then the operator form must be constructed (eg. unapply) as another step.
4) The computation times are be different. For this approach the computation time may rise more with the number of instances of dependent calls like x(t),y(t),etc appearing in the desired dependent formulas, depending on the example. This may or may not matter to you, depending on the formula and the DEs in question. (Such a timing penalty can be mitigated by adding option remember to the separate operators, after the extraction. But it's additional steps and requires more skill.)

MaplePrimes_-_Extract_dsolve_output_ac.mw

Not all these points will matter for every example. But it's not always hands-down better to use the listprocedure output. It's not hard to come up with examples that make either way look better. That's why there are options. :) Sometimes "best" means the way that makes more sense to you.

ps. I often use listprocedure. I shy off from assigning to the names of the functions in my DEs. (I prefer to be able to re-execute without any additional hassle.)

Please stop posting wholly separate new Question threads on this topic.

Instead, please add the followup queries in Comment/Replies here, or Branch from here.

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

nb. The Branch button exists at the bottom of your Question(s). Please use it. Using it will create cross-reference links from this Question to your new Followup Question threads -- and that allows anyone reading it to see that it relates to previous details and responses. It's not helpful to otherwise have the details completely separated.

[edit] This has been mentioned to you a few times before, including. July 27.

@C_R If you would really like to utilize an expression form calling sequence (without the need for uneval quotes each time you reference it) such as,
   plot( fr(t), t=0..1)
rather than an operator form calling sequence like,
   plot( fr, 0..1)
then you could instead construct fr in one of these ways:

   R := unapply('eval(r,dsol1(t))',t,numeric):

   R := proc(t)
       if not t::numeric then return 'procname'(t); end if;
       eval(r,dsol1(t));
   end proc:

The effect there is that both of those return fr(t) as the unevaluated function call itself when argument t is not of type numeric (eg. here, a symbol).

I suppose you already know that the numeric solving of this system faces some quirks & difficulties. Perhaps you are trying to investigate the numeric DE solver itself. If not, then without details it's hard to know whether you'd run into situations in which you might 1) want to specify stepsize or another option to dsolve, 2) augment the system if looking for integrals|derivatives versus post-calculation via evalf@D or evalf@Int, etc, 3) other...

@bathudaide Feel free to provide a URL for the author's code site.

(You asked before, "Can I upload it for discussion?", where "it" really does seem to mean "source code" from the previous sentence. So, no, you can't upload a copy of his source code here without permission. But you can provide a link to it.)

@bathudaide You asked, "I have found the source code for SDPTools.  Can I upload it for discussion?"

Only with the explicit permission of its author (or copyright holder).

I find the business of having deleted replies stick around distracting and unhelpful.

I also notice that they remain even if the response was deleted as spam (using the special item for that). So some Posts that attract multiple spammers get quite cluttered.

I think that those changes might also have coincided with the regression/bug in which responses without votes are ordered wrong by date. Such used to be ordered downwards with oldest higher, and now they are (poorly) ordered in the opposite direction.

@bathudaide Yes, that's what I mean about those two files.

And I get an equivalent error message, on Linux.

I added some update notes to my Comment above.

I notice that for Linux the name of the shared-binary in that site's FGb download is named "libfgbuni.so". And that webpage is 9 years old. And modern Maple for Linux itself already has its own "libfgbuni.so" shared-binary (from the same research people, IIANM).

So it's possible that for MS-Windows you might be already have a functioning .dll that exports the FGb external functions, in your installed Maple, and be able to simply unpack the Linux FGb download and install just its Maple Library portions. (It's so old that it's bundled as the pair FGblib.ind and FGblib.lib) And then augment libname as it instructs, by prepending it with the location you put those Maple Library files.

You'll know if it's gotten off the ground because this example would work:
   with(FGb):
   fgb_gbasis([x^2+y,y^2+x],0,[x],[y]);

[update] I now suspect that the above might not work at all, sorry!

It's not clear that all the functions' calling sequences have stayed the same between that old FGb package of 2015 on their site and the current sharEd-binary in modern Maple. When I try to utilize the .ind|.lib files from their site with even the Linux libfgbuni.so shared-binary then with(FGb) throws an error (path issues, perhaps in its ModuleLoad).

Also, the calling sequences of the exports in Maple 2024's Library's bundled fgbrs package seem different from what that old 2015 FGb package has. Eg.

restart;
FGb := fgbrs:
with(FGb):
fgb_gbasis([x^2+y,y^2+x],0,[x],[y]);
Error, invalid input: fgbrs:-fgb_gbasis expects its 2nd argument, vars1, to be of type list(name), but received 0
restart;
fgbrs:-fgb_gbasis([x^2+y,y^2+x],0,[x],[y]);
Error, invalid input: fgbrs:-fgb_gbasis expects its 2nd argument, vars1, to be of type list(name), but received 0

I'm out of ideas, sorry.

49 - 25 + 9 = 33

@Scot Gould I don't know whether the underlying problem would just get fixed, without a new Options/interface setting.

If you want both modes (now and then) then it might be easier to utilize an alternate OS user account for just the PDF export, rather than keep shunting versions of that preferences file.

@Andiguys You asked, "Can we change x-axis label to Ce from x and y label  to Cv?"

Yes, you could simply add the option,

   labels = ["Ce", "Cv"]

to the call to the procedure.

Question_plot_cv_ac2.mw