Major performance problem encountered with PyMAPDL

[HazemEldahshan]

Hello,

I am experiencing a significant performance issue with PyMAPDL and would like to start this discussion to better understand the origin of the problem.

I am using the following code to perform a series of calculations:

with mapdl.non_interactive:
for t, timeStep in enumerate(times):
mapdl.input_strings(outres_cmd)
mapdl.time(timeStep)
mapdl.nsubst(1, 1, 1)
mapdl.solve()

In this setup, I deliberately do not export any results so that I can measure the pure solve time, without including I/O overhead. For that reason, I use the following OUTRES commands:

outres_cmd = r"""
OUTRES,ERASE
OUTRES,ALL,NONE
"""

Despite this, I still observe a large discrepancy between the computation times in PyMAPDL and in native MAPDL, by a factor of about 3–4. When I analyze the timing, I obtain:

Elapsed time for the solve: 398.459 s
CP time: 206 s
This is with essentially no I/O operations involved.

I also want to emphasize that I am using a user-defined material model in both PyMAPDL and MAPDL, so the overhead associated with the user material should, in principle, be similar in both cases.

Could you please help me understand the possible causes of this performance difference?

Regards,
Hazem

[germa89]

Hi @HazemEldahshan

Normally PyMAPDL takes a bit more time because of the delays in sending/receiving the commands over the gRPC channel.

Having said that, I see no particular reason for this difference in runtime in the code you mention. It will help if you can provide a script with actual code we can test on our side and assess the possible issues. Feel free to attach the code in this discussion.

[HazemEldahshan]

In fact I am using external library for the material model so it would be hard to share this part with you. However, I can share the pyMAPDL code only but not sure if this will be sufficient.

[germa89]

As much as you can share.

[HazemEldahshan]

Ok here is part of the code that causes the performance issue. I am using an external material library to do to material calculations wich interacts with the solver via upfs. All dof are restrained so basically only material model is solved.
.

1. Here I use tables that define displacement on whole mesh for all time steps, no active dof in the model still exists
   mapdl.input_strings("d, all, ux, %DisplacementTableX%")
   mapdl.input_strings("d, all, uy, %DisplacementTableY%")
   mapdl.input_strings("d, all, uz, %DisplacementTableZ%")

2. Here I defined solution options
   mapdl.autots("OFF")
   mapdl.cnvtol("U", -1)
   mapdl.cnvtol("F", -1)
   mapdl.run("KUSE,1")
   mapdl.run("ERESX,NO")
   mapdl.input_strings(outres_cmd)

3. Here I solve
   with mapdl.non_interactive:
   for t, timeStep in enumerate(times):
   mapdl.time(timeStep)
   mapdl.nsubst(1, 1, 1)
   mapdl.solve()

I hope this can help.

Hazem

[HazemEldahshan]

Hello,

I was able to reproduce the problem on a simple model. Please find attached the input file generated from Mechanical in addition to a data base file of the same model I use in PyMAPDL to solve and compare the results. The following code is the one I used to solve the model in PyMAPDL

mapdl_path = os.path.join(os.environ.get("AWP_ROOT251"), r"ansys", "bin", "winx64", "ANSYS252.exe")

try:

DBFolderPath = r"D:\PyMAPDL_Perf"
run_dir = os.path.join(DBFolderPath, "Results")
os.makedirs(run_dir, exist_ok=True)

src_db = os.path.join(DBFolderPath, 'file.db')
shutil.copy(src_db, os.path.join(run_dir, 'file.db'))

mapdl = launch_mapdl(
    exec_file=mapdl_path,
    license_type="meba",
    run_location=run_dir,
    override=True,
    nproc=32,
    additional_switches="-dis dmp"
)
mapdl.verify("OFF")
mapdl.slashsolu()
mapdl.resume('file.db')
start = time.time()

with mapdl.non_interactive:
    mapdl.solve()

end = time.time()
print(f"time: {end - start:.3f} seconds")
mapdl.finish()

finally:
mapdl.exit(force=True)

Here are the solution time differences between Mechanical and PyMAPDL. We can observe that the elapsed PyMAPDL time is almost 2 times the elapsed time taken by Mechanical APDL

PyMAPDL:

Mechanical:

** I was not able to upload all the files, could you please give me your mail so that I can share with yout the project files?

Best regards,
Hazem

[germa89]

The performance difference was caused by the overhead of generating output files for each command (/OUT,anstmp) and transferring those files back to PyMAPDL.

Although the command itself is short, MAPDL produces a significant amount of console output when solving models that require multiple iterations. This output is written to the anstmp file, which can become fairly large. Transferring this file back to PyMAPDL adds enough overhead to noticeably increase the execution time.

To avoid this cost, the /SOLVE output can be suppressed:

mapdl.solve(mute=True)

This approach is much faster because only the command itself is sent, while the potentially large solver output is ignored.

However, there is an important tradeoff: when mute=True is used, PyMAPDL has no visibility into the solver output. It cannot detect warnings, errors, or even verify whether the solve operation completed successfully. For this reason, this option should only be used when you are confident that suppressing the output is acceptable for your workflow.

Possible improvements:

• Allow muting non_interactive contexts (currently only local instances are read from non_interactive does not allow to retrieve last response on remote instances #4838)
• Lazy output retrieval. Similar to feat: lazily download VGET array results via LazyArray #4781, we can retrieve the server response when we need it, specially for long running commands like /SOLVE and /INPUT.