I recently got access to a 12-core Intel MacPro with 64 GB main memory. This motivated me to try parallel programming again, even though in prior years I have never been successfull. The project I am trying to do is particle tracking through a circular accelerator, an embarassingly parallel problem in the sense that you can track n particles in parallel through your machine for many turns and then gather up the results for analysis. The function describing the tracking is a 6-component polynomial function acting on 6-vectors and yielding a 6-Vector as a result. Each accelerator component (magnet, drift section, rf, ...) is described by such a function. I am simplifying this a bit here, but in the problem at hand this is what I am doing. The point is that each particle gets treated independently from the others, hence parallelization should be trivial.

Using an existing package (Lattice, which I published with Maple) as framework I set this up such that the tracking proc for n turns of one particle in the accelerator is a member of a module. This module is in the body of a proc and gets returned when the proc is called, essentially instantiating the tracking object and assigning it to a Vector with as many elements as I have particles to track. The tracking function returns a 6-Vector with the coordinates after all turns are complete. 
A separate proc does the instantiation of all tracking objects, gives each one its particle number (from a Beam object it is being given) and sends it off using Threads:-Create. It then waits until every task is done (using Threads:-Wait) and assembles the result in another Beam object which it returns. Please refer to the enclosed Maple worksheet for how it is done.

This actually all appears to work. MacOS is 15.7.2 (Sequoia); Maple is 2023.2. The results are identical both parallel and serial.

The "interesting" result however, is that usage of the available CPU cores saturates at about 4. In the graph shown below, the green line shows the CPU usage of the mserver process, and it saturates between 400 & 500%, actually going down to 360% as more particles get added. 100% is one core, so I am never getting more than about 4 cores to work for me. Correspondingly, the no. of seconds per particle goes up from about 3 s (particle 1 to 4) up to about 15 s/particle, settling at about 10 s/particle as 12 particles are approached. Below is a graph against no. of particles (n) of running time (red), CPU time (dark blue), CPU usage (yellow) and # or mkernel threads (green). 

Bottom line: I am only getting 4 cores out of the 12. Process limits of MacOS (ulimit -a) do not indicate any limit that would cause this (and I have had build jobs that would merrily use all 12 cores).

Is there a limit in Maple that prevents using all available cores? Am I doing something inefficient that could cause this?? This is the first time I actually got parallel operations in Maple to work, so I am happy about that, but my happiness is tempered by not getting it to work at the level I was aiming for. I did google around a bit and found some prior conversations on MP (mostly involving @acer and @Carl Love) about parallel threads which indicated that (a) environment variable OMP_NUM_THREADS should be set and (b) that numcpus can only be set at the very beginning of a Maple session (which I interpret as "right after firing up Maple"). Did both (and verified the settings were in) but no change in behaviour of this code; I only get four cpu cores to work.

Thanks,

Mac Dude

Parallel_tracking_attempt.mw

Edit: Added graph, fixed up graph.

I do not think I've ever seen this before.

I have Maple set up to use one engine per one worksheet.

Today, when I tried to open new worksheet (after Maple had an internal error running some code in another worksheet), I was not able to execute anything in the new worksheet. I get this message

Looking at task manager, I see the front end running at high CPU

Stange thing, there was nothing else running at the time.

Had to kill all of Maple.

Just wondering if any one saw this message before and what could cause it?

I'll try to see if I can reproduce it again by running same code which caused that initial Maple error in the first worksheet. But as I said, this is the first I see such a problem in Maple.

I was connected to the network at the time, if this makes any difference.

I want the Minkowski metric in spherical coordinates, so I do the following:

Which is not correct, it should return:

-d_(t)^2 + d_(r)^2 + r^2*d_(theta)^2 + r^2*sin(theta)^2*d_(phi)^2

Any ideas why it is giving the wrong answer? I usually just define my metric manually, but I was curious why this is occuring. I also noticed something else strange: after running the worksheet, if I go back to the setup line and execute, it will return the correct expression! But if I execute restart and then Setup again, wrong answer. 

Any thoughts would be appreciated, thanks! 

What is the opinion here on the following. If given   A which is linear in x, but not simplified. now type(A,x) gives false.  But type(simplify(A),x) gives true.

Does this mean it is the user responsibility to simplify the expression first before calling type on it? 

Why does not type command do this internally to see if it is linear before deciding? What is the reason for this design choice?

Download why_simplify_is_needed_feb_9_2026.mw

Hi,

I’m trying to transpose an existing animation that connects the unit circle to the graphs of cos⁡(θ)\ and sin⁡(θ)\ into a complex-numbers visualization, so that students can clearly see the link between

z=eiθ=cos⁡θ+isin⁡θ,arg⁡(z)=θ,∣z∣=1

and the corresponding real/imaginary components.

Goal: a dynamic view where a point z(θ) moves on the unit circle in the complex plane while (simultaneously)

• the projections show ℜ(z)=cos⁡θ\  and ℑ(z)=sin⁡θ,

•  the graphs of cos⁡θ and sin⁡θ are traced against θ\,

• and/or the angle θ\ and argument are displayed in a clean, didactic way.

To better illustrate my objective, here is the link to the target animation I would like to transpose: 

Illustration

Thank you in advance for your insights and feedback.

Animation_Question.mw

I have created three random variables:  r, theta and phi.  That went as I expected.  I then did some math with these random variable.  I calculated the following:  sin(phi), sin(theta), cos(phi) and cos(theta).

When I viewed the PDFs of these above four, I get what I expected with the exception of sin(theta).  I got an error message telling me that I provided three arguments when Maple expected only two arguments.  I am confused as to why this happened.

I wonder if I broke any rules when I named these variables, but I don't know...any suggestions? My work is attached.

Download Basics.mw

Could someone suggest a way to help dsolve be able to obtain this solution to this complicated first order ode? In V 2025.2 it is not able to solve it as is

Download ode_solution_feb_6_2026.mw

Instead of

if not(type(expr,atomic))...

I would like to use something like that for better readabilty

if type(expr,composite)...

where "composite" is a placeholder for beeing not atomic.

Does anyone have any exoerience playing with this topic?

I have the functions dx(t), dt(t), and dz(t).  They are all the same function.  I constructed the dz(t) function as a piecewise function, then copied it to dx(t) and dy(t).  The area under the function curves sum to one as I would expect.

How can I convert these functions into a PDF form so that I can perform mathematical operations on the PDFs, such as add the PDFs to create another PDF?

SphereFinal.mw

Noticed something strange.  When I type

restart;
F:=x-> (x^4+3*x^3-3*x^2-2*x-24)/(x^4-4*x^3-13*x^2+62*x-56);
u:=x->piecewise(x=-4,limit(F(x),x=-4),true,F(x));
u(-4);

Gives Error, (in F) numeric exception: division by zero which means it did not hit the first condition x=-4

But when I write this

restart;
F:=x-> (x^4+3*x^3-3*x^2-2*x-24)/(x^4-4*x^3-13*x^2+62*x-56);
A:=limit(F(x),x=-4);
u:=x->piecewise(x=-4,A,true,F(x));
u(-4)

Now it gives expected result 15/47

To avoid defining many variables, like A above, I'd like to just write the  limit inside.

Is there a way to make Maple accept the limit inside piecewise as written above? i.e. have it evaluate to 15/47?

Help says "The piecewise function evaluates its arguments on an as-needed basis."

Not sure what this means.

I tried adding eval, as in 

u:=x->piecewise(x=-4,eval(limit(F(x),x=-4)),true,F(x));

But this did nothing

Maple 2025.2

Should not the following two commands produce same solution?

f:=x->(x^2+3*x-4)*cos(x^2+3*x-5);
PDEtools:-Solve({f(x)=0,0<x,x<2},x);
solve({f(x)=0,0<x,x<2},x);

This is what the result looks like

Why Solve gives one solution and solve gives 2? Is this expected or a bug?

btw, the solution from solve is also not complete. There are 5 roots not 2.

Student:-Calculus1:-Roots(f(x),x=0..2);

Many problems in mathematics are easy to define and conceptualize, but take a bit of deeper thinking to actually solve. Check out the Olympiad-style question (from this link) below:

Former Maplesoft co-op student Callum Laverance decided to make a document in Maple Learn to de-bunk this innocent-looking problem and used the powerful tools within Maple Learn to show step-by-step how to think of this problem. The first step, I recommend, would be to play around with possible values of a and b for inspiration. See how I did this below:

Based on the snippet above, we might guess that a = 0.5 and b = 1.9. The next step is to think of some equations that may be useful to help us actually solve for these values. Since the square has a side length of 4, we know its area must be 4² = 16. Therefore, the Yellow, Green and Red areas must add exactly to 16. That is,

With a bit of calculus and Maple Learn's context panel, we can integrate the function f(x) = ax² from x = -2 to x = 2 and set it equal to this value of 8/3. This allows us to solve for the value of a.

We see that a = 1/2. Since the area of the Red section must be three times that of the Yellow (which we determined above to be 8/3), we get Red = (8/3)*3 = 8.

The last step is to find the value of b. In the figure below, we know that the line y = 4 and the curve y = bx² intersect when bx² = 4 (i.e. when x = ± 2/sqrt(b)).

Since we know the area of the red section is 8 square units, that must be the difference between the entire area underneath the horiztonal line at y = 4 and the curve y = bx² on the interval [-2/sqrt(b), 2/sqrt(b)]. We can then write the area of the Red section as an integral in terms of b, then solve for the value of b, since we know the Red area is equal to 8.

Voila! Setting a = 1/2 and b = 16/9 ≈ 1.8 guarantees that the ratio of Yellow to Green to Red area within the square is 1:2:3, respectively. Note this is quite close to our original guess of a = 0.5 and b = 1.9. With a bit of algebra and solving a couple of integrals, we were able to solve a mathematics Olympiad problem!

Just for my understanding:

I have read ?procedure and noticed that the term variable is used as a synonym for the term name.

Otherwise Maple uses the term variable more in a mathematical sense and the term name to refer to an expression.

Is this to make the help page easier to read or to use jargon familiar from other programming languages?

This use of vocabulary must be intentional. However I do not fully understand this subtle difference.