@dharr It seems to me that if efficiency is the concern then the OP could inform us whether he really needs all the results up front, or whether his goal might involve iterating across them.

The .mla approach would be the sophistacated way, which avoids actually recreating the call_external produced by define_external.

An easier approach would be to simply put your working define_external code inside a plaintext file and then use the read command on that in any new session, to call your procedure by name. (That's similar to what you were trying before, except that you were trying to use read with a .mw worksheet file.)

Sometimes people use the filename extenstion .mpl for such plaintext files. That's just a convention.

@mmcdara Yes, Prandtl number was my guess.

I think that the OP ought also to double check all the rest of his two formulas thoroughly, given the mistakes, before too much time is spent fiddling with the first parameter set.

@dharr In Maple 2023 it seems to suffice to assume that w>0 in order to get a explicit result from inttrans[fourier] here.

But without any assumptions the fourier call returns unevaluated. Perhaps the OP originally had used assume, etc.

Collecting the result w.r.t. hypergeom tidies it up quite a bit.

If w<1 is also taken, or if all variables are taken as real (evalc), then further simplifications are possible.

Fourier_ac.mw

@WD0HHU Only the OP can tell you what he intends for Pr.

But that's a good question!

if I assign a numeric value for Pr then only 5 BCs are wanted, so I can get rid of the one I introduced. (This might all be a consequence of how it isolates and/or converts to 1st order bigger system, internally...)

It raises a related issue. It seems that there are also additional syntax mistakes in the OP's 2D Math inputs.

For example, eq1 and eq2 have the function calls,

   phi[2](1-phi[1]+phi[1]*rho[s1]/rho[fl])
   phi[2](1-phi[1]+phi[1]*rho[s1]*beta[s1]/(rho[fl]*beta[fl]))
   phi[1](k[fl]-k[s1]), phi[2](k[fl]-k[s2]),
   phi[2](1-phi[1]+phi[1]*rho[s1]*C[p][s1]/(rho[fl]*C[p][fl]))

And those may well have been intended as products with phi[1] and phi[2] as multiplicands, rathers that as functions to phi[1] and phi[2].

If I "fix" the phi[1],phi[2] issue so that their function calls are multiplications then the dsolve call for parameter values a1 does not immediately converge. I haven't looked more closely at that.

Download HIPT_acc.mw

@mmcdara Your way of creating the U proc is also problematic. One could instead use unapply.

I agree that the OP's worksheet seems based on some poorly understood approach. The methodology itself looks shaky.

@awass It's not a hidden character.

It's the combination of the proc definition code being split across two separate Execution Groups that are both set to "presentation" view.

I discovered this by opening the .mw file in an external text editor. I have some familiarity with the XML structure used for .mw files.

I don't know how you managed to get them into that configuration. I notice also that that mode suppresses the visibility of the red chevon prompt. It might have gotten into a muddle wrt 2D vs 1D or some such. Also, in that mode the usual F4 to join the two Groups doesn't seem to function for me.

The advice to discard it (or perhaps copy line by line, not altogether) might be the thing to do here.

@MichaelVio Please put very close followup queries on this same underlying problem here (in a Reply/Comment) instead of spawning a wholly separate new Question thread.

Or, if the problem is related but different in essence, you could use the Branch choice (at the bottom of this Question's body). That automatically puts cross-reference links into both the new and the old Question.

It's not helpful if the material is split, since nobody can easily see what came before or after (or even know that it's there...).

Duplicate Question threads get flagged as such, and may be deleted.

ps. In one revision of your sheets I've seen the call,
      solve({E1=3.259*ec,nu=432})
but note that was done after a restart (which wipes any earlier definition of E1). In any followup, you should really explain in full detail what E1 is supposed to be, and which equations would establish A, etc.

@nm Apart from the Maple Help pages I cited earlier, there is more:

In the Install.html file, in the section of starting Maple, subsection for the Command-line Interface (CLI), it points one to the readme.txt file in the Maple installation directory.

That readme.txt file has instructions (for a Linux install) about executing "maple" if the PATH contains it, or otherwise referencing it by its fully qualified location. It states,

"Starting:
    In a shell, type the command "/usr/local/maple2024/bin/maple".
    Substitute the appropriate directory name if you chose to install
    Maple 2024 to a location other than /usr/local/maple2024."

Also, Maple's installation and launching documents are clearly split by OS (Windows, Mac/OS X, Linux). Nowhere in the Linux sections does it suggest that you as normal user would launch using `cmaple`. Yes, several Maple things are different, between those OSes. That's why the document is so heavily split up by OS -- installation, license manager, launching, activation, network installation, etc; those sections are all split up by OS.

So, using the `maple` script is documented in the Help system. And it's also documented in the installation docs.

And your arguments about what `cmaple` on Linux should do if you fail to pass it the arguments that the `maple` script passes are not accurate. The world is more varied than just your small sphere of usage.

@nm cmaple is a compiled executable, and the `maple` and `xmaple` shell scripts call it (with set-up arguments).

The `maple` script has a Help page,  ?maple

Calling the `xmaple` script is like calling `maple -x`.

There is a description for "Command-line Version" on the Help page,
   ?versions

It says, "To access the Command-line version in Mac or Linux, use the maple command.  In Windows, use the cmaple command."

?interfaces pops up that ?versions as 2nd item in the Help Browser (it's an alias).

note: On Linux the bin/maple script is an intended front-end for invoking the cmaple executable. Ie. `maple` sets certain key variables, and then calls `cmaple ` with arguments. (Normally, one wouldn't call it directly on that platform.)

(I had not noticed that the OP was attempting to call `cmaple` directly. Sorry, my eyes saw what I was expecting. Vote up for phil2!)

On Windows, it's different.

@C_R Yes, the Classic GUI was shipped alongside the Java GUI for some releases.

@C_R Let's not call the old (Maple 2024 and earlier) Java GUI as "classic".

The term "Classic" has meant the non-Java pre-Maple8 GUI for a long time, including in Maplesoft's documentation. It'd be confusing to re-use the term.

Please forgive me for editing the word in your response.

The problematic part is actually split across two separate Execution Groups. The "end proc" is in the second one.

That fact is obscured because both have XML property view="presentation" (ie, the red chevons don't show, and F4 doesn't join them).

The simplest is to not try and Copy&Paste that.

I don't know exactly how you got it into that state.

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.