@agh314 The primary errors are the result of memory not being shared. Any variables that you've defined or structures that you've created (other than those in list) prior to calling Grid:-Map that might be needed by Query need to be sent to the remote processes by using Grid:-Set. I don't know DifferentialGeometry, so I don't know what a "defined frame" is, but I suppose that you do. Perhaps alg1 is a defined frame. So do

Grid:-Set(alg1) 

before Grid:-Map.

The error "invalid input: op expects 1 or 2 arguments, but received 0" is simply the result of there being no output to return due to the primary errors.

When you used Threads for this, are you sure that the results were correct? And did they truly run in parallel rather than locking each other out? What was the total CPU utilization (which you can check with Windows Task Manager or similar tools on other OSs)?

Since list is very small, you should use Grid:-Map[tasksize= 1](x-> ...)

If you do a numeric integration of an integrand that contains a symbolic variable (h in this case) other than the variable of integration, then what form of result are you hoping to get? I do not mean this as a rhetorical question; I literally want to know.

You should reduce the value of M to 3 or 5, reduce Digits to 15, and run the code with the output-suppressing colons replaced by semicolons so that you can get some appreciation of the enormity of the expressions involved. And they'll be much larger still when M=50.

@Muhammad Usman Some response to my Answer would be appreciated.

@noecb2002 Thanks for the plaintext ODE. Using it, I have no trouble solving your IVP with standard dsolve options and no adjustment needed for the trunc (after I provided initial conditions that I made up). But I suspect that you may be trying to use one of the more complicated methods, perhaps lsode[backfull]. In order to have any chance of duplicating your error message, I need plaintext of your initial conditions AB and options dsolve_options. So please post the plaintext output of lprint([AB]) and lprint(eval([dsolve_options])).

@chrisc I didn't deny that it was a bug; I said that it should be corrected. But given that x::complex is Maple's default assumption anyway, it's worth being more careful with expressions such as abs(1,x) that don't even make sense (at least to me) when x is nonreal.

Please post the expression Lagerkraft in plaintext form so that we can copy and paste it. The command lprint(Lagerkraft) will present it in plaintext form.

I suspect that the problem is the trunc. If that's the case, you may be able to fix the problem by giving the command

`diff/trunc`:= 0;

before the dsolve. (Note that diff(trunc(x), x) = 0 is true almost everywhere as they say in Real Analysis (meaning that the set of x for which it is not true is infinitesimally small (technically, measure zero)), so just making it 0 should be good enough for a numeric dsolve solution (which is, after all, a form of integration, so what happens on a set of measure zero doesn't change the result).)

To achieve the results from your linked video, change the projection from the plane to the sphere to

P__pl_to_sph:= (r, theta)-> (theta, 2*arctan(2/r))

And change the sphere's color function to

Color__sph:= (psi, phi)-> COLOR(HSV, (1+sin(phi)*cos(psi))/2, 1, 1)

or

Color__sph:= (psi, phi)-> COLOR(HUE, (1+sin(phi)*cos(psi))/2)

Everything else can remain the same. Let me know if this is the plot that you want:

I needed to use Maple 2020 instead of Maple 2021 to post the plot.
 

@Earl Thank you. I've added a few details to the Answer above, and I did a lot of clarifying of the typography, so please reread it carefully (and probably several times).

I just watched the video on Mobius transforms that you linked. I can see that the projection that I used is different from that used in the video. And, of course, the coloring function is different. Both of these details can be changed simply by changing the projection function and the coloring function in the code. No change is needed to the expository text or the algebraic/functional framework that it lays out.

The projection from the sphere to the plane that I used gives the point on the plane where it is intersected by a line tangent to the sphere at the preimage point. To get the projection from the plane to the sphere, I simply inverted that function algebraically (which is trivial in the coordinate systems that I used). However, in the video, the projection from the plane to the sphere is where the line connecting the plane's preimage point to [0, 0, 1] intersects the sphere. This line goes through the sphere rather than being tangent to it.

I'm doing that algebra now.

I have two questions about your system:

• Why do you say it's nonlinear?
• Do you think that it's possible to solve it without specifying f, alpha, omega, and x__||(1..4)||0?

You mentioned "matrix" twice---in the title and in the body of your Question. Yet I see no matrix, only a vector. What do you consider the matrix?

@tomleslie So why don't you move it to the other thread?

According to the help page ?ifactor, there are 5 algorithms that can be used for difficult numbers (after the easy methods have been exhausted). These are

mpqs     - Multiple Polynomial Quadratic Sieve method
morrbril - Morrison and Brillhart's continued fraction method
squfof    - Shanks' undocumented square-free factorization
pollard   - Pollard's rho method
lenstra   - Lenstra's elliptic curve method

Or perhaps there's an undocumented multi-core method. There are 30 procedures whose names begin `ifactor/...` in the Maple 2021 library.
 

@mmcdara The replacement for convert(..., listlist) is convert(..., list, nested). It works for rtables of any number of dimensions.

Here is a correction to the bug of the blue exclamation points:

`print/%factorial`:= n-> 
    subs(
        "!"= ("!", mathcolor= "#909090"),
        InertForm:-Typeset(%factorial(n))
    )
:

I incorporated this into the code in my Reply that generates the matrix in the Question. I don't know whether this'll work with InertForm:-Display because I did it all via more primitive methods, i.e., `print/...` procedures and Typesetting markups.

@acer I did notice that quirk: the blue exclamation points that should be gray. I chose not to mention it because it's a superficial bug (i.e., doesn't really change how the computation is done), so mentioning it would seem to me to be a cluttering and ephermal detail in an Answer that's already quite complicated and intended not to be ephemeral.

I just added another coded example to my Reply to my Answer which you may not have read.