Is there a subdirectory "afm" (with about 13 files in it) under your Maple 2025 installation?

Eg, on my Maple 2024.2,
    /usr/local/maple/maple2024/afm

Does it work in your Maple 2024?

Btw, from the Commandline Interface (CLI) one might do it as,
    plotsetup(cps, plotoutput="full_file_name.ps");
to get both the filename extension as well as a colored red curve. Also, the plot driver is slightly different wrt orientation default (portrait vs landscape) as well as curve thickness. That calling sequence seems to act the same in the GUI, regardless of whether "cps" is the plot-device or whether the filename extension is explicit in the supplied name.

Please either add closely related queries on this as addtitional details here (in a Comment, say), or use the Branch button at the bottom of this Question to form a new Question thread with cross-reference links that get added automatically.

Also, if possible, you could attach an example that produced the system of equations (that use, or for which you want to use) the SemiAlgebraic solver.

When using the Mapleprimes editor's green up-arrow to upload a file, the 2nd step can be "Insert Link", even if the alternative choice of inserting the whole document (inlined display) fails.

A workbook file (extension .maple) can be first zipped up (.zip) in the OS, since the uploader doesn't recognize the former.

Otherwise, you could explain precisely how uploading and attaching your Maple file is failing.

@Saalehorizontale Unfortunately (for me), that's not actually and explicitly what you wrote in your Question.

@Carl Love Thanks, I missed that.

I hazily recall seeing the real[i] selector mentioned somewhere, but now I can't find it.

@Carl Love It seems to me that it'd also be useful if the OP were to include the conditions 1 < y, y < 2 in his solve call (as well as those assigned to area)

@mmcdara A single call to the eliminate command provides this condition directly.

@C_R Your worksheet shows a result of NULL from the last statement, the call to solve.

@Scot Gould 

I edited my Reply above, to show an actual wrapping/replacement proc for this. Please let me know whether it works ok.

Have your examples of 1) and 2) been reported?

It's slightly confusing to me that you've chosen only this Question thread to mention earlier problems that you say are not rare. If they are not rare and causing problems for several people then why not post/report on them earlier?

(please report problems/hangs/etc.)

@Scot Gould There is no super-convenient way to set a new/different default for an arbitrary Maple command's options, while also retaining ability to call it by its original name.

But, you could wrap it, eg. (possibly for an init file),

unprotect(Explore);
__kopts := kernelopts(':-opaquemodules' = false);
__Explore := eval(Explore:-ModuleApply);
Explore:-ModuleApply := (ee::uneval) -> __Explore(ee, 'adaptview' = false, _passed[2 .. ()]);
protect(Explore);
kernelopts(':-opaquemodules' = __kopts);

The above is slightly more complicated that a usual "wrap", because Explore is an appliable module and also Explore:-ModuleApply's first parameter has special evaluation rules.

Personally, I wouldn't disable functionality by default just to avoid an (apparently) rare issue. I'd just change my usage on the rare occsasion that needed it, and submit a report.

You could remove options remember and system from targeted procedures. That would disable the usual remembering of regular function calls to that procedure.

And for each procedure you'd only have to do it once per session, up front. That up-front act could then cover all your subsequent simplify calls.

For example,

strip_memo.mw

To be most effective you'd want to do this also to the procs internal to simplify. So you could map the act over a list of the relevant proc names. (There isn't a convenient automatic way that'd be analogous to forget's subfunctions option.) There are more `simplify/`... classical-extension procs, btw, including,
`simplify/recurse`
`simplify/normal`
`simplify/normal/check`
`simplify/normal/test`
`simplify/factor`
`simplify/do`

Anyway, the point of this is that you can disable remembering by simplify and its internals (if accomplished via usual procedure calls), which was your followup question. But I still think that my original suggestions to either wrap :-simplify or use a module export (so as to be able to forget, each time, without wide code changes by you) are safer in general.

ps. You've made the claim before that your above-described kind of crash is due to memoization. It might be. But it might be due to something else.

@Carl Love My first suggestion was to write (as you have just done) an export, and then make it part of his existing module(s), so that his other module members could pick it up. I don't know for a fact that all his code is in modules, but there have been indications that at least parts of it are so organized.

I can't recall all my tests, but at one point (using forget on :-simplify as you've done in your first implementation) I saw the forget action actually re-instating(!) the original to name :-simplify. Like a reread from archive. I was surprised. That's why I wrote a more complicated variant that took the extra step of replacing itself(!) from template after calling forget. Now I don't have the problematic example, sigh.

@dharr Is there a nice insightful way to show that the inner sum (m<>n) equals 3/(4*n^2), without that exact same splitting approach?

Download inner_s.mw

@nm Now (in followup, but also the original Quesion contents have been edited) you have asked for a way to disable use of remember tables. That sounds like a bad idea in general:
1) It'd degrade efficiency.
2) Doing so (were it possible) might even break functionality. There are other ways in which remember tables can be used to control programmatic flow; it's not always just about efficiency. A procedure might even use a technique of deliberately writing to a remember table as as way of preventing further attempts (if something does wrong, etc). I don't know whether that is ever done "under" simplify. Risking it seems like a bad idea in general.

nb. The "permanent" in the option forgetpermanent option of forget is about a flavour or Cache entry. It's not related to permanance in a disabling sense.

Any facility to disable remember table use shouldn't sensibly be an option to forget. That'd poorly conflate purposes.

I understand that you have a great deal of code which makes simplify calls, and so are looking for a tidy do-once-up-front approach.

My first suggestion would be to make a package export named simplify, so that fellow code in a package could pick that up binding. If your code is organized nice "enough" in modules then that could allow you to restrict your code edits almost entirely to a new export. The export could just be a wrapper which clears the remember tables under global :-simplify, and then calls it. You could even make the forget action happen acording to whether some environment variable were set -- in case all this is only a debugging technique for you.

Slightly dodgier is to clobber global name :-simplify with such a wrapping procedure (which calls the original).

Btw, I'm not sure whether your use of printlevel was just for exposition in your question, or actually an essential part of your intended process.

For example, clearing only under `simplify/do` (which might be all that's needed):

how_to_clear_simplify_cache_V2_march_24_2025_ac1.mw

A more complicated variant on that, which forgets under :-simplify itself (and guards against re-reads, and maintains your printlevel stuff without showing verbose forget details):

how_to_clear_simplify_cache_V2_march_24_2025_ac2.mw

[edit] My two worksheets take the unprotect/clobber/protect route, which I see that Carl has also now utilized gracefully.

@WD0HHU 

mmcdara's Answer's worksheet explained it in a comment, "...for versions >= 2018 use InsertContent(Worksheet( T ))".

A_few_ideas_ac.mw