@Carl Love I found the green up arrow. My code to call Maple from Fortran is attached (at least the web page claimed it was uploaded).

@vsnyder I have my program working using NAG Fortran build 7045. When using Intel ifort 2021.2.0, it gets a bus error 15 levels deep into EvalMapleStatement. Here's the backtrace in gdb from the bus error to the point of invocation in my program:

#0  0x00007fffffffbf92 in ?? ()
#1  0x0000000000580320 in var ()
#2  0x00007ffff0b8c010 in ?? ()
#3  0x00007ffff7156ee0 in ?? () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#4  0x00007fffee21f922 in ?? ()
#5  0x00007ffff0b8c010 in ?? ()
#6  0x00007ffff667ee64 in ?? () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#7  0x00007ffff66102d7 in ?? () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#8  0x00007ffff6b1eb96 in ?? () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#9  0x00007ffff6b19a09 in ?? () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#10 0x00007ffff6b14a5a in ?? () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#11 0x00007ffff6a476b7 in ?? () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#12 0x00007ffff6a468e4 in evalstat () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#13 0x00007ffff6b1dd9d in ?? () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#14 0x00007ffff662a346 in MapleEvaluate () from /opt/maple20/bin.X86_64_LINUX/libmaple.so
#15 0x00007ffff6a037b9 in ?? () from /opt/maple20/bin.X86_64_LINUX/libmaple.so

Are there shared libraries for OpenMaple that were compiled with at least line numbers turned on in the backtrace so that the developers would have some hope to find the problem (or tell me what I did wrong)?

@mmcdara

It seems a bit weird to answer a question with "I don't know what problem you're trying to solve, but you should be solving a different problem."

I am developing mathematical software in Fortran, to be used in Fortran or C or Ada or ... programs (Fortran has excellent interoperability features). I use Maple to calculate reference results to compare to the calculated results, both to test the algorithm and the software.

My latest project is a new method to compute the exponential function of a triangular matrix.

I evaluate the function of the given matrix in my Fortran program using IEEE double precision arithmetic, again in Maple using 60 digits (and a different method so I'm testing both the algorithm and the software), then compare the results.

In a test of 1000 matrices having random elements, generating the matrices required 5.44 milliseconds, computing the exponential functions of them using my software required 10.5 milliseconds, and computing the reference values in Maple required 12 seconds (not 12 milliseconds).

I had been doing this by my program writing a Maple program on a file, invoking Maple to run the program using Execute_System_Command, then reading a file written by the Maple program. Instead of 12 seconds, that required three minutes and 26 seconds. So invoking Maple using OpenMaple facilities provided a speedup of a factor of about 18.

Computing the reference result in Maple was much easier than developing (or acquiring) an independent algorithm, and writing code to use an extended precision package such as the one by Brent or Bailey to implement the algorithm.

One problem was that the underlying types of function results and parameters are not described in the OpenMaple documentation. This is not a problem if you're writing a program in C, and use the macros in maplec.h. For example, the type MKernelVector is not described. It's a "handle." Now that might be an int, or a long, or a pointer. The distinction is important in writing the Fortran interface. I eventually found the declaration. It's a typedef for a pointer to a struct.

Another problem (that isn't mentioned in the Maple Advanced Programming Guide) is that sending statements to EvalMapleStatement isn't quite the same as typing them into the Maple textual interrace. In the Maple textual interface, you can lay out a "proc" definition on several lines, as you would in C or Fortran or Haskell. To submit it to EvalMapleStatement, it needs to be combined into one long stream of text, from "proc" to "end proc".

Ultimately, the software I'm developing will be incorporated into a 300,000 line Fortran program that has been under development since 1992. This program is used to analyze data from an earth-orbiting instrument that produces 500 million measurements of microwave power in 1000 channels  every day. The program occupies the service of a cluster of 384 Intel Xeon processors for (on average) fifteen hours per day, to produce five million measurements of temperature and twenty minor chemical constituents of the atmosphere, such as ozone, on 3500 profiles, at 72 levels from eight to 80 kilometers. There is no funding to convert it to Maple. The National Weather Service says four of the products improve their "skill" by one hour (I have no idea what that means).

Throughout my career, I have tried to use the most appropriate precision power tool for each job. I have more than a hammer, a file, and a vise in my toolkit. It's wonderful to have a fancy lathe or milling machine, but that doesn't help much if the correct tool is a railroad locomotive. If the developers of Maple thought it was pointless to incorporate Maple into other programs, the OpenMaple API would not exist.

@vsnyder 

By sending a proc to Maple as all one "line" I have this working.

I incorporated it into a program that tests a new method to compute the exponential function of a triangular matrix, to compute a reference value in Maple using 60 digits.

I had been writing a script for Maple on a file, then invoking Maple using Execute_Command_Line, then reading the file produced by Maple.

For 1000 4x4 matrices, that test took 3:32.469. Using OpenMaple, the same test takes 12.829 seconds. That's a speed-up of a factor of about 16.

@Carl Love 

Here's a transcript.  I can send code if you want, but there's no "attach" button.

845: ./Test_Using_Maple

> p := \
at offset 5, `;` unexpected
> proc ( x ) \
at offset 12, unexpected end of statement
> sin ( x ) \
sin(x)
> end;
at offset 1, reserved word `end` unexpected
> p(x)
p(x)
> q := proc(x) sin ( x ) end;
q := proc (x) sin(x) end proc
> q(1.0);
.8414709848

I have this working. I found the typedef for MKernelVector. It's a C pointer to a struct. Usually, a "handle" is an integer.

I have defined interfaces for StartMaple, EvalMapleExpression, MapleRaiseError, RestartMaple, and StopMaple.

I ran a simple test that uses StartMaple, EvalMapleExpression, and StartMaple.

I found that if I want to define a proc, it has to be sent to Maple as one line in EvalMapleExpression. I tried to break it into several lines with backslash at the end, but that resulted in "unexpected end of statement."

Did I do something wrong? Is there another way?

@Carl Love Using the long forms instead of using with(LinearAlgebra) and the short forms saved one second out of 3 minutes and 30 seconds.

I would be interested to start maple and send its scripts through EvalMapleExpression to see whether that makes a difference in run time. But I'm not yet able to do that for reasons explained in the original question "How do I call Maple from Fortran?".

@mmcdara I've been using Fortran's "Execute_Command_Line" intrinsic subroutine to run Maple. My program writes a Maple script, which writes a file of its results, which my program reads. Starting Maple, and loading the necessary libraries such as with(LinearAlgebra) is a significant fraction of the total run time.

I want to use the OpenMaple facilities to "converse" with Maple, not launch a new Maple session for every step of my program. The problem is that the type MKernelVector is not described in the programming guides. I have tried declaring it to be a C pointer, or a C long, but when EvalMapleStatement is invoked, it gets a segmentation fault.

I am able to call Maple by way of a C wrapper that invokes StartMaple and saves the MKernelVector handle. When it invokes EvalMapleStatement, there is no segmentation fault. I assume the difference is that the kernel handle is represented properly. A wrapper is just more code to maintain.