We'll probably need more details if there's to be any hope at all of helping you. Note that your version of Maple is about 20 years old. What you describe seems like a problem with the GUI (Graphical User Interface). That GUI software is not used anymore. And even if (and it's a big "if") it were theoretically possible to fix some bug in it, I don't know if it would be legally possible for Maplesoft to do it. Nor would it make any business sense (in my opinion) for them to devote more than, say, 1 worker-hour to fixing some bug in that ancient system. 

So hopefully your problem can be solved without modifying the "Classic" GUI. To help, please clarify the following:

1. Are you saying that whenever you try to save a worksheet, your entire Maple session crashes (completely disappearing from your screen)?

2. Is the worksheet actually saved when this happens? Or do you lose your worksheet and your session?

3. Are you trying to save some code while it is running?

4. Was there ever a time using your current computer, current operating system, and current Maple version when you did not have this saving problem?

5. Was there ever a time using a different computer, different operating system, or different Maple version when you did not have this saving problem?

@Christian Wolinski "Good", but not worth a Thumbs Up?

In case you're not familiar with pointto and assemble, I thought that I should also show an example of explicitly creating a pointer to an object that can be pointed to at the user level (rather than one where the command causes an error):

kernelopts(dagtag = INTPOS); #positive integer INTERNAL type
                               2

A:= assemble(2, 23); #This returns a memory address (session dependent!).
                   A := 36893488147419103275

n:= pointto(A);
                            n := 23

The inverse of assemble is disassemble; the inverse of pointto is addressof. The 62 fundamental data types are known in Maplese as dagtags. The first argument to assemble is thus an integer[1..62]. The procedure d-> kernelopts('dagtag'= d) is its own inverse.

I just deleted a Post by you which was a follow-up question to the above. Please put your follow-up here instead of in a new thread.

Okay, I felt like looking at the 8th-order method. Where is it?

@ You wrote:

• For some reason when I run it, the same error Error, (in plots/odeplot) input is not a valid dsolve/numeric solution) still pops up. All I have changed is the mass values. I ahve attached the code below.

I can't duplicate that problem. I loaded the worksheet that you posted, with the changed mass values, and clicked on the !!! icon on the toolbar to Execute Entire Worksheet. Within 2 seconds, the entire worksheet executed, and the new plots were produced:

• Also for some reason, why is the code for the plot in text mdoe rather than math mode?

What makes you say that it is in text mode? When I use the worksheet, the code for the plot doesn't seem to be in any format different from any of the other code. And the mode indicator on the toolbar says "Math".

Edit: Actually, whether it says "Text" or "Math" on the toolbar seems inconsistent. Sometimes it does say "Text". I guess this is a bug. But, regardless of what it says, the code executes exactly the same for me.

I'm using Maple 2022.1 on Windows 10.

@ If you remove the colon from the end of the dsolve command, then what is its output?

Did you try paying for it?

I see that you just asked a followup Question, about an error in a plot command. But the worksheet shows the same error as this Question is about. There's no sense in continuing until the first error is corrected, and so I am about to delete that new Question.

The error in the plot command is caused by a missing right parenthesis at the end of the first odeplot command.

@vv Where is the square root? The A that I see is a polynomial. Perhaps it has been changed from the original posting.

@vs140580 It's more than a "small" tweak, but it seems doable. It'll require some thought and may take me a few days.

@MaPal93 You asked:

• Given your experience, is it reasonable that the execution is stuck at the evala@:-Norm step for such a long time?

No, that's completely unreasonable. Using the system of 6 equations that you provided, the commands

P:= indets(Eq, name) minus V;
EqN:= ((numer@evala@:-Norm@numer)~@eval)(Eq, P=~ 1):

take 2 seconds total on my computer. (And in another 2 seconds or less I was able to verify that all 6 were indeed converted to degree-14 polynomials.) It's only the SolveTools:-PolynomialSystem command that should take any significant amount of time.

My first choice was triade because it's the more-modern algorithm, and I've met the man who wrote it. But I told you to use groebner because it seems to use parallel processing whereas triade does not. Given your massive computer, the parallel algorithm should finish in less "real" time even if it's theoretically much less efficient.

You should kill the triade computation, restart and re-execute the worksheet, and use engine=groebner. I have no idea how long it will take or how much memory. I wouldn't be surprised if it took several days. I would expect the memory usage to reach a plateau, as you observed. It's just luck that that plateau was under 1TB. But parallel processing will likely use more memory.

You can use the command kernelopts(numcpus) anytime, before or after the rest; you could even do it in a separate Maple session. It's just to check whether Maple will have access to all your processors for parallelism.

The few extra processors that you see working are probably just doing "garbage collection" (the recycling of memory that's no longer needed).

@ijuptilk Try replacing rand(0. .. 1.) with rand()/1e12

@acer engine= triade was my first choice, but I didn't see any evidence of parallelization happening via Windows Task Manager. Do you know if that's different under Linux?

@MaPal93 I just posted some ideas for easy parallelization in a Reply to my Answer below. I don't have a massive computer with which to fully test those ideas, but you do.

I agree with acer that your modified system is not different enough to warrant a new Question thread. And I agree totally with his statement that splitting the threads would make it "unnecessarily difficult for the readership if a derivative followup query is separated from its parent, since that obscures connections amongst the information and details given by the original poster as well as the responders."

@MaPal93 This might work given that massive computer that you have. My plan:

1. Once again, we let Eq be the equations (actually expressions implicitly equated to 0), and let V be the variables being solved for (I'll call them decision variables from now on).
2. Once again, we set all other variables (I'll call them parameters) to 1. This'll make the system much easier to solve, and I want to do this proof-of-concept before substantially more effort is expended on solving with the parameters.
3. New idea:  Since the expressions are algebraic functions, they can be converted to polynomials, which are much easier to solve, and Maple can do the conversion in 2 seconds. This usually introduces extra solutions, but all the original ones are preserved. The extras can be filtered out by checking if they satisfy the original system.
4. The details of converting to polynomial form are

• extract the numerators, discard the denominators (command numer)
• command evala@:-Norm does the heavy algebra
• extract numerators again, because there were denominators under square roots that weren't touched by the first extraction.

5. Use the Groebner-basis method to solve the polynomial system. In Maple 2022 (and perhaps some earlier versions) this uses parallel processing. I got near 100% CPU utilization on my 4x2 hyperthreaded computer.

The degree of all the polynomials is 14, much lower than I was expecting.

Here are the commands:

P:= indets(Eq, name) minus V; #extract parameters
EqN:= ((numer@evala@:-Norm@numer)~@eval)(Eq, P=~ 1):
SolE:= CodeTools:-Usage(
    [SolveTools:-PolynomialSystem](
        EqN, V, engine= groebner, backsubstitute= false, preservelabels
    )
):
(length, length~, nops)(SolE);

Let that run either until it's finished, your memory is nearly full, or you can't take it anymore. Use operating system tools (such as Windows Task Manager) to keep an eye on processor utilization. It should start out strong. If not, kill it, and give the command 

kernelopts(numcpus);

and report the result here.