Parts of your .txt file have 5 columns of float data per line, and parts have only 3 (or 1).

How do you want that imported?

Do you want such differing blocks to be imported into separate Matrices? Or into a single Matrix, with fill-in?

This seems like of one those situations for which a proper specification of the goal would be better.

@nm What do you think of the following, using your sol_1:

odetest(simplify(sol_1),[ode,IC]) assuming t>Pi/2, t<Pi;

  [0, 0, 1/2*Pi]

Issues can also arise if you take other (different) directional limits.

Why do you believe that choosing any arbitrary direction (to approach [0,0] in limit) is valid, even in this context of odes? Do you believe that your two odetest calls above demonstrate a sound and robust approach, ather than your getting lucky?

The answer to your multivariate limit example is undefined, and not the expression you obtained by taking the limits separately.

Consider your approach of taking limits wrt single variables separately. Which do you do first?

eval(limit(limit(sol, _C3=0), _C4=0), t=3*Pi/4);

  -1/16*Pi*2^(1/2)

eval(limit(limit(sol, _C4=0), _C3=0), t=3*Pi/4);

  3/16*Pi*2^(1/2)

Also, consider the limit as _C3 and _C4 approach zero along the line _C4=3*_C3 (ie. after doing a substitution). And now along _C4=7*_C3.  Evaluate as t=3*Pi/4. Those produce different results. See also here.

Now, you might have some other purpose in mind, that you didn't state in your original Question. And that might not even need a correct result for the multvariate limit computation. If that's the case then your Question would be better if it stated its purpose.

@C_R In Maple 2025 the substitution of the Intat within the RootOf might be handled slightly differently. (Below I do eval(subs(...)) but one could also do it with subs[eval] .

And the contents of the RootOf may become the simpler 2*cos(_Z)  rather than the equivalent 4*cos(1/2*_Z)^2-2 .

And then the result from allvalues might become simpler, with fewer _Zn parameters with integer assumptions.  The loop isn't really necessary, with the single _Zn parameter and the formula like Pi*(1/2+_Z1) , since I realize that you can directly imagine the concrete values, but I left it in.

nb. I did not change the sign in this author's Eq.1. I've just re-enabled the flow for your version.

Download Not_Only_Pi_ac2025.mw
or, for M2015 by prodding it for that cos simplification (again, without changing the initial sign),
Not_Only_Pi_ac2015.mw

@C_R Please could you give (here) that "integrating twice" bit, but in 1D plaintext Maple code and without any Equation labels?

@janhardo The axis of rotation is the line that passes through [1,1,1] and [2,2,2].

See the Help page for the rotate command, which explains the calling sequence rotate(Cube,phi,[c]) with the bullet-point and sentence,

   "If the calling sequence is of the form rotate(q, alpha, [pt_3d_1, pt_3d_2]),
    then pt_3d_1 and pt_3d_2 define the axis of rotation."

You wrote, "...and I must copy and convert each one individually into LaTeX".

The latex command in your Maple 2024 has several options related to directly writing (or appending!) to external files.

And you also have another choice: using the latex command to generate seperate strings of each expression's LaTeX code, and then sprintf'ing that to an external file.

And it's reasonably straightforward to map that latex command across a list of solutions. There is no need to "...copy and convert each one individually".

You've omitted important details of your desired output format. Is it one text file, or several? If it's multiple files, do you want to specify a common part of filenames (like a prefix)? Do you want the text file to include preamble LaTeX likes like \documentclass{}, \begin{document} etc. You should explain precisely the format you want.

Having Maple's own GUI do all the items in your bullet points doesn't sound like a good way to spend resources, since one can write Maple code to do all that in a 1-10 line procedure.

@elemental cinder Please check for mistakes in this attachment, including transcription errors. I think there are some improvements (ie. re-use of values from previous result without cut&paste, less floats where possible/reasonable, etc).

It's not clear how N(r) could attain a purely real value of 66.6 for some r>0.

I didn't check that the symbolic integration step is producing the right result(s) here. That step can take a while (1-2mins in my Maple 2025). I might get time to check its validity against a purely floating-point numeric integrator (for concrete numeric input).

This forum doesn't render all the 2D Input lines below. The essense of the later plots is that N(r) is non-real for r>1/4, and greater than 500 for 0<r<1/4 .

ps. I used Maple 2024.2, as I find 2D Input mode in M2025/2026 more awkward. Pls let me know if these same results don't attain in your Maple 2025.

Download MATHprobwithV_ac.mw

This is a correction for the earlier typo. I tried to give the two black-box procedure more pertinent names.

bbox_ex2b.mw

Note that you still haven't actually attached a worksheet file for you latest followup query. So we cannot tell what you mean about units, or what you ment by your references like  `V__!3` etc.

When you upload a .mw file here, using the green uparrow in its editor, you also have to attach it or (better, here) insert a link to it. Those are choices in the pop-up that appears when you upload via the arrow.

@elemental cinder Sorry, if I typo'd.

The ranges passed to help fsolve might need adjustment, on account of that. Or, try looking at the implicitplot to get hints on ranges.

And you should try fsolve rather than solve, since the expressions are not explicit. (ie. a purely numeric solving)

[making dinner for the family right now. I'll revisit in a few hours I hope.]

@Ronan I'm glad that you're able to make some progress.

Soneone changed one of my Replies into an Answer. I have changed it back, to keep the original sequence of posting in their original order (because they logically and textually follow each other.

@Ronan Did you try my suggestion, after adjusting for your typo?

How is the following not doing what your last Comment mentioned? (This is essentially the same as in my previous Reply, but now there is RT:- instead of TN:- )

2026-03-27_Q_Module_Generic_Variables_R1_acc2.mw

ps. You just wrote, in a followup Comment, "One other question the arises from this....", with an additional query. But the additional query doesn't seem (to me) so much something revealed in part of the reposnses; it seems more a related (but quite distinct) thing on writing code&modules. Could you not ask all your relevant queries when you first post your Question?

@Ronan My followup point is that you might well want to programatically query current settings (so as to use the results in some test or manipulation). Here's a shot at that.

Note the latter examples, illustrating that you can both set and query values. It's done now to query values after doing the setting, but you could change the order.

I'm not sure if you mean that you want the modules source code to contain TM (literally), and then to be able to utilize it as RationalTrigonometry. Here's something on that too. (If you actually were to keep your source code in plaintext files -- which some people always do for serious projects, and then read them in -- then you could use $define macros.

Download 2026-03-27_Q_Module_Generic_Variables_R1_acc.mw

@Ronan For your interest: without dummy parameters, multiple overloads, etc. I'd suggest that this is simpler in structure, and in use.

(nb. sometimes this site displays some Maple 2026.0 outputs as [?], though they can be fine in actual Maple.)

Download 2026-03-27_Q_Module_Generic_Variables_R1_ac.mw

ps. Another finesse that might be programatically useful is the functionality where Settings could also accept one or more of the relevant locals (just as a list of names, say, or as strings) and return their current values. Let me know if you'd be interested; it's just another adjument, I think.

pps. I'm not sure if it's your style, but some of the adjacent lines in the code could be rolled into so-called multiple-assignment. Eg,
   (a,b,c):=A,B,C;
rather than,
    a:=A;
    b:=B;
    c:=C;

@dharr That is interesting. It might be "fun" to discover or prove which patterns of values of the assumed parameters lead to actual solutions.

I see that the following form can be obtained in Maple 2026.0 if using environment variable _EnvAllSolutions rather than the allsolutions option of solve. (That's a bit weird, and I ought to check whether it happens for other kinds of equations...)

[edited: I used a different equation, now corrected]

Download s_ex2.mw