You're quite right. My mind was elsewhere and I posted to hastily, sorry. I've edited my Answer to express it more correctly.

What I gave was code for the surface of revolution of a Reuleaux triangle which, while a surface of "constant width", is not the same as the Reuleaux Tetrahedron about which you inquired. Of course the Reuleaux Tetrahedron is not itself a surface of constant width, while its modification the Meissner tetrahedra does have that property.

The Reuleaux Tetrahedron might be constructed by generating the portion (any of the four) larger spheres with center at the vertex of the body. The key thing, naturally, is to restrict the sphere to just the portion that forms the opposing side of the desired body. Once the key portion is made then it would just need to be duplicated four times, oriented appropriately. The modification to get the Meissner tetrahedra is also possible, to be sure.

I'm sorry but I am quite busy right now and cannot look at this soon. I am sure that there are several other members of the community who can do it, however.

The MathApp that I mentioned has a useful feature: it rotates the body and displays it with a view that demonstrates that the width is constant, because the body's edges always touch but do not extend outside an enclosing square. That MathApp can be easily edited to also use any other body of constant width, which is simply a 3D plot assinged to a variable in its code. So it could be adjusted to alternatively display the Meissner tetrahedra.

I did mention that the App does not run in Maple 15. This can probably be remedied, and perhaps posted here too as a worksheet.

Are you in a hurry? What's your working timeframe? I'll check back when I get a chance.

Did the problems start with a recent upgrade? If so then try reinstalling (possibly with a fresh download of the Installer).

acer

@Yiannis Galidakis If you are willing to give up the axes being displayed, then you can do it with subsop to set the the first two operands of each frame's GRID to be the same.

EulerAnimation2_noaxes.mw

Another way to get what you want, with axes showing (and each true and correct) is to use a PlotComponent instead of using plots:-display on the list of plots. Basically, you could have a button that sends each frame to the component. In other words, you would not set the value of the PlotComponent to be the whole animation, and you would not use the various properties for traditional animations that the PlotComponent offers. Instead you mimic whatever aspect of playing an animation you want, with commands. Here is a version with just simple code to play all frames. (That code could alternatively go behind a Button Component, although you'd have to make sure that the cursor focus is elsewhere before you clicked it, else in Maple 13 there would be a lot of flash artefacts I suspect).

EulerAnimation2_Component.mw

I ran the above two worksheets in Maple 13. In Maple 18 you could alternatively use the Explore command to do something similar with components, by exploring the already computed list of plots. The idea there is just that it gives you a nice Play/Pause/Loop button effect without having to code up all the Embedded Components yourself.

@Yiannis Galidakis I did not split into real and imaginary components in order to speed up an evalhf version. I split up into real and imaginary components for the Compiled version (which I ran under Maple 18). This is about the second attachment in my answer. Specifically I split into real and imaginary components because of (64bit?) MS-Windows specific issues with the Compiler package: one related to crashing in abs of a complex[8] float and another where compiled code wouldn't run in parallel under the Threads:-Task package (though I have not yet gone as far as making a multithreaded version of code for your example). None of that relates to evalhf, and none of that relates to Maple 13.

FYI these techniques can be used for your problem, if you are interested in high quality 2D images produced quickly. I couldn't quite tell from your original post whether you actually wanted the depth of a 3D plot or whether you used plot3d just because it hammers the Standard GUI less hard than does the corresponding densityplot. I included in my attachments the call to do it in 2D with plots:-densityplot, by the way.

The first attachment in my answer was just a run with Carl's suggestion to wrap in a proc which called evalhf, and including the lightmodel=none option to plot3d so that the same colors can be obtained in M18 vs M13 (as well as roughly the same timing).

What values for ics did you use? (So we might expermient better.)

acer

@Carl Love Interesting. In the very first line shown in the assignment to Load, the input has an upright P and the output has an italic P. How can that happen, I wonder.

@Carl Love That would affect 2D Output (which could then get hit with `value`). But the typeset display in the 2D Input would still appear as gray.

I'm not really sure how much the 2D Math aspect for input matters to the OP, who referenced typeset symbols only in a followup comment.

Also, if one tries copy & paste from such output (with the scheme just as you propose) then what gets pasted is active sum. Not sure how relevant that is to the OP either.

@PunkRediska I don't see how that addresses my third and second questions. But perhaps the additional details might help someone else answer better, so thank you.

Your objective `f` doesn't seem to be deterministic? Is it supposed to be?

What's the intended domain of `f`, over which you hope to find the minimum?

Why do you think that `f` has a property which a global optimizer might utilize, which would do much better than simply peppering the domain and explicitly finding the minimum of all functional eveluations?

BTW, I found an objective value as low as 0.12 (which is better than the value of 1.3 reported at the time I write this by Markiyan as coming from the GlobalOptima command),  but I don't see how useful it is to know that, with the answers to my other queries. I wouldn't be surprised if an even better value might attain, though that too depends on your responses to my other queries.

I had difficulty understanding the code which is messy.

acer

Does your .mw have anything in its Startup Code region, or any document blocks or Code Edit regions set to autoexecute? If so then try changing you GUI preference to not execute such code without confirmation.

acer

@tomleslie two underscores was new for maple 18. In maple 14 getting an underscore which is not an indexed name requires using an atomic identifier ( constructed either using the context menu, or by assembling undocumented typeMK).

@Carl Love I thought that I tried gridlines=false to get around the artefacts in the Mapleprimes display, but got an error message which I haven't tracked down yet.

There is another item of interest lurking in the implicit 3D region. Given air density rho, the angle alpha which allows the minimal successful initial velocity v0 may be less that Pi/4. I suppose that this is because the ball can spend less time airborne and thus suffer less overall effect of the drag (given a rho>0.0).

In the attachment I resorted to crudely ripping that out of a sequence of 2D implicitplots, which may not be very accurate but I suspect gives the general result somewhat ok.

bball3D_extra.mw

And with the angle as third parameter the 3D region for a right-center home run can be visualized. That is the region "inside" the green surface that is implicitly defined by the ODEs.

Using the compile=true option for dsolve(...,numeric) allows the green 3D implicit region below (defined by a 30x30x15 mesh of 13500 data points) to be computed in about 14 seconds on my Intel i7.

As either the initial velocity v0 increases, or as the air density rho decreases, the range of incidence angles which will attain a home run gets wider.

bballfull3D.mw

I guess I should also mention:

The region "inside" the blue curve represents all the angle and initial velocity combinations that will attain a right center field home run for Denver's air density.

The region "inside" the red curve represents all the angle and initial velocity combinations that will attain a right center field home run for sea level's air density.

@Alejandro Jakubi I had them separate because I was originally experimenting with other transformation in between. But thanks for the tip.