@acer , I solved problems with physics. I followed the advice you gave me as close as I could. Could you take a look at what I've written and point out things that are written inefficiently?

Code: new_version.mw

@acer , following your advice I started rewriting my procedures into one. I found problem in physics (animation showed that there is a problem). So i need to solve a system of DE's that was not there in the last version (that's where my question in another thread arised). I created a procedure that returns all values that are needed for DEs (i think that is the most effective way, maybe i'm mistaken) but I can't get it work. Here's the file: new_version.mw

After two similar systems of DE's would solved, the resultant procedures would be used to create an animation..

@acer ,

Before your corrections:

CodeTools:-Usage(animate_rotation(1000, 50));
memory used=315.64GiB, alloc change=0 bytes, cpu time=77.36m, real time=75.53m, gc time=5.51m

After:

CodeTools:-Usage(animate_rotation(1000, 50));
memory used=0.88GiB, alloc change=288.00MiB, cpu time=48.28s, real time=48.64s, gc time=875.00ms

Well, the difference is more than significant=) I would like it to be maybe around 10 times faster than your version. So I'll try to wrap it in a single procedure. Thanks for your guidance!

@acer , thanks for the improvements made. I'll try to rewrite program in more efficient way in several days and post it up here.

@tomleslie , sorry, but I haven't seen it yet., I didn't choose to ignore it. I wrote you an e-mail and watched topic for a couple of days, but you didn't answer. So I decided that my letter was somehow too pushy, and you wouldn't respond to it. 

I will look up your file and try to take into account and think over all changes that you made. 

I think that you're being too rough and coarse writing messages like this. 

@acer , I understand that it's not a very good practice to post most of the code each time. Next time I'll remind myself to post code only concerning asked problem. In one of the last threads it has been pointed by one of the forum participants that my code is inefficient, but no concrete tips were given even though I reached to that person. I really want to code better and more efficient, but, you know, it's hard without guidance...

Ok, I deleted redundant entries in inertia tensor, it is a redundancy, i admit. 'fdiff' part is commented out though, it's not used anymore.. 

What do you mean by "some of the frame data being recompiled each time"?

I would gladly hear out suggestions and guidance on increasing efficiency, it's hard to work out such things all by yourself.

@Preben Alsholm , I decided to choose the first advice of yours. It seemed simpler to understand)

@Preben Alsholm, thank you for modification.

I thought that arrow operator is a special form of procedure, so it wouldn't be a big mistake to call this function a procedure. (At least Maplesoft says so: https://www.maplesoft.com/support/help/Maple/view.aspx?path=operators/functional)

I want to add method to this construction, because it's very slow that way. 

comp_1:=t->evalf(Int(x->r1_lab_deriv(x)[1],0..t,epsilon=1e-6)):
comp_2:=t->evalf(Int(x->r1_lab_deriv(x)[2],0..t,epsilon=1e-6)):
comp_3:=t->evalf(Int(x->r1_lab_deriv(x)[3],0..t,epsilon=1e-6)):
r1_lab:=t-> <comp_1(t),comp_2(t),comp_3(t)>:
st:=time[real]():r1_lab(5):time[real]()-st;
# epsilon=1e-3 -- 1.388s
# epsilon=1e-4 -- 1.570s
# epsilon=1e-5 -- 2.193s
# epsilon=1e-6 -- wouldn't converge

 Integrand should be oscillating so I wanted to add method=_d01akc from NAG Library. But I got an error:

Error, (in evalf/int) cannot handle unevaluated name `t` in evalhf

@acer thank you! It's the first time that I encounter embedded components. It seems that they are quite useful, I should learn more about them)

@acer , that looks amazing! Can the same be made if animations are made through proc-construction?

Adding my file:ClassicalTrajectoriesH2X_harm.mw (two animation in the end of the file)

P.S. For now there is no 3d-animation, it's only 2d-model. But I'm planning on adding it so was asking for future.

@tomleslie, yes, thank you! The problem was exactly in the double use of the 'k'-variable!

I would appreciate a lot if you point out other "untidy/ineffiient stuff".

@Carl Love Thank you!

@Carl Love , sorry for the sizes of files, but the problems happen when I produce a big amount of plots (I wrote this thing for this purpose). 

Here's a link to dropbox public access folder: https://www.dropbox.com/sh/1k0noaf0fgtnvr3/AAAA_VIbdk9npuX36ba-uCiDa?dl=0 (it seems that local uploader can't handle the file this big)

First file (..._1) contains plots generated by cycle from J=18 to J=35. Take a look at J=18.

Second file (..._2) contains this particular plot (generated by cycle from J=18 to J=18).

Picture differs from the corresponding picture in the first file. 

Sorry, right now I don't understand why the divergence even occurs.

@Carl Love Thanks a lot! Hope that this trick will help me to avoid stupid mistakes like this ...

@Carl Love Thanks a lot again! But how did you notice such a thing? Some of the errors that Maple invokes are mind-blowing... An extra space, seriously??