@acer 

For some reason I thought the frames for the second animation call were set to 150. I was probably a bit overworked and annoyed by the upload problem.

I constructed the example upon your reply for discussion. Here is a corrected version (which is the second way I described above)

multiple_animations_02.mw

The example and the system of odes is simple but already shows what I expected: plotting a space curve with odeplot is much faster that using plottools. However, I am a bit surprised how fast it goes and I would for this example not write a procedure. The dependence of the cpu time on the number of frames and the integration time is instersting to observe. Its not excluded that the the third way will take more computation time than the second way if space curves are involved.

For complex and/or numerically demanding cases with long integration times one could think of reformulating at each time step IVP with dsol(timestamp).This does not work straight away with

(first time I am seeing dsolve solutions this way).

My question has somehow been answered: Try the second way and estimate computation effort and then decide to optimize with the thrid way. For that it would be good to be able to reformulate the IVP. This is the remaining question I have at the moment.

@acer

I wanted to attach an example with 3 plots to be displayed together (without letting the cube spinning for a moment). But I am getting this here

I had to delete the last plot structure and it worked.

And yes, I thought odeplot is in this sense optimized that the integration is done once or at certain points in time odeplot stores intermediate results and uses them as new initial conditions.

multiple_animations.mw

Uploading the code with the green arrow makes investigations easier.

Without knowing the pde and the initial/boundary conditions its difficult to tell. However, the error message gives already a hint that the timestep for sol2 is too large.

If you want to keep this time step you could try to play with with numeric methods and options. See ?pdsolve,numeric

@matmxhu 

It looks to me that the combination of commands have reveald a deficiency of a recently improved implementation. Here is the ouptut from Maple 2022, which shows that compactdisplay was not working at all on partial derivatives

I the past Edgardo Cheb-Terrab provided often swift fixes for the Physics package. This might change in the future. Better now to make MapleSoft formally aware of it: https://www.mapleprimes.com/scr/new

I hope the physics project will continue.

My best whishes for his future!

@dharr I could expand a bit on your idea. Works well for a single path

Remove

currentdir(); #some path
FileTools:-SplitPath(%);
remove(has,%,"Users");
FileTools:-JoinPath(%)

Replace

currentdir(); #some path
FileTools:-SplitPath(%);
subs("Users"="Utilisateurs",%);
FileTools:-JoinPath(%)

@MaPal93 

Partial derivative of a summation: why it is not just 2*`X__i`?
I am not sure I understand what you mean. Suppose n=3. Then A=X_1^2+X_2^2+X_3^2. For any i from 1 to 3 the derivative is always 2X_i, that is, for i=1 is 2X_1, for i=2 is 2X_2, for i=3 is 2X_3. Why their sum?

Answer: You are correct.

A := sum(X[i]^2, i = 1 .. 3);
seq(diff(A, X[i]) = 0, i = 1 .. 3);
                            2       2       2
                   A := X[1]  + X[2]  + X[3] 

               2 X[1] = 0, 2 X[2] = 0, 2 X[3] = 0

But you did not differentiate w.r.t. X__1, X__2, X__3. You differentiated with respect to X[i] over which Maple summs up.

Partial derivative of a double summation: how to define the nested structure of a double summation where j<>i?
I cannot see how B_wrong is calculated, and Sum it's just an inert form so not that useful. In any case, B_wrong is surely not correct since I never really included the j<>i constraint on the index (the summation over j has to skip j=i). How do I do this?

Answer: I misunderstood what you where after because in your worksheet

B__correct - B__wrong;
                               0

System of n equations: how to define and solve for it?
I wanna solve this generically. That is, if I have n+1 equations where n of them are functions of X_i (and X_j) and the last one of X_r, the output solution is X_i=... and X_r=...  

Answer: I do not think that this is possbile in generic way without letting solve know the number of equations and their structure. My trivial example worked. But this is an exception. There might be other examples which are equivalent to computing the inverse of a nxn matrix which could work. Before speculating too much I prefer to hear wheather Ronan's way suits you. Looks very promissing to me.

@nm Works well. Thank you!

@nm 

I was hoping for Maple setting since I cannot change the username on a managed PC (not my personal).

I have also seen placeholders like "username" but his was perhaps a manual edit.

I tried converting an outupt to a string which removed all the backslashes in the file path. Maybe there is a dedicated command that I overlooked.

@ecterrab

I had a further look at my last observation.

I compared VariationalCalculus:-EulerLagrange with Physics:-LagrangeEquations with the first example of

?dsolve,numeric,DAE. Results:

   VariationalCalculus:-EulerLagrange returns: - A - B = 0

   Physics:-LagrangeEquations returns: A + B = 0

For consistency (e.g. code migration from EulerLagrange to LagrangeEquations) and to make LagrangeEquations for formulations with external forces following d'Alemberts Principle compatible to LagrangeEquations, I was wondering if an option (or something else) for the LagrangeEquations command could resolve the -1 issue.

For engineering applications it is important to calculate forces and displacements using principals involving work and/or energy with the correct sign.

IMO, Maple Physics output should be, as much as possible, consistent when it comes to Fermats principle, principal of least action, principal of virtual work, d'Alemberts principle, the Lagrangian and Hamiltons principle.

For the time beeing, I will stick to manual derivatives or VariationalCalculus:-EulerLagrange with the caveat of removing K from the output (which is more complicated that multiplying the output from Physics:-LagrangeEquations by -1).

If it is already to late to change the design back to - A - B = 0, an option with a default on pretty print (A+B=0) would protect existing worksheets with A+B=0 output from beeing changed. A description of the option in the help page would make the new command Physics:-LagrangeEquations compatible to the use for d'Alemberts principle.

@acer 

Nice play on words. Allways good to have a ray of joy on a gray day. I will remember.

@acer 

your insights are always welcome. I do not understand one detail. Why is executing

time[real](assign('P',plot(fr, 0..10, popts)));

a second time about two times faster?

@WA573 

I have no time to have a closer look. You must check all the derivaties one by one.

For debugging purposes I would remove the alias statement and adapt subsequent statements.

Try for example

diff(S(x, t), x)

and see whether the output is what you want.

@Carl Love 

I did not know this

I think the server needs a restart and/or Mapleprimes has a bug. See here: more than than 10 deleted comments. This does not look like a use error.