Roadmap, integration with Workbench, best way to access data ...

[natter1]

This is not an issue but a question. In our group (university) we decided to change the education for students from using APDL to workbench some time ago, because it looked like APDL was "deprecated" by ANSYS. Most of our previous work was done by APDL script, and it has some advantages. We do a lot of parameter studies, esp. for the modell geometry, which are not so easily done in workbench (at least with my limited skill set).

Now it looks to me like ANSYS is focusing on a scripting solution again. And we have some discussions in our group, weather to move completly to workbench whenever possible, or if the easier python interface (compared to pure APDL) would be an argument to use both workbench and python scripting. Its hard to decide, esp. as we do not know where the focus of ANSYS might be in the next years. What is the roadmap? To better combine workbench with python-scripting? I saw the DPF packages, which seem to allow handling workbench results (?). What about the steps in between, like e.g. switching between script and workbench for geometry creation vs. simulation and post processing. What about using PyMAPDL inside workbench (like the APDL commands which can be added before the solver right now) - ideally without the limitations of IronPython? Maybe APDL will become "invisible" to the user, and scripting would be done purely in python? I know its not easy to talk about future company goals, but I would still appreciate any insights you could provide. The education of our students has a huge impact on how they could use the tools in the upcoming years. Once they are set on a track its unlikly they will change it easily, if it all. It would be cool if they could learn both GUI and scripting, but right now, the combination of script and workbench seems not like the way to do it ^^

[natter1]

And on a side note - when using PyMAPDL to access results, the docs suggest to use DPF packages for post processing. What if I do not save results to disc? Isn't it better to use mapdl.results directly? Or is it the same?

[akaszynski]

First off, sorry for the delayed reply. I've been speaking with several people within Ansys to get a feeling for the direction so I could write this correctly without misrepresenting the company's direction.

Ansys will be working to improve scripting both inside and outside of Workbench and its other products. It's part of the strategy to better enable method developers as we're finding it's becoming the case that more and more users wish to automate our products within the Ansys ecosystem or in a different environment such as in a generic Python interpreter. Given the dominance and popularity of the Python ecosystem and the variety of tools publically available, I can say for certain that Ansys wants to enable users to be able to use it's products in tandem with other toolsets.

APDL was "deprecated" by ANSYS

APDL isn't going anywhere. In fact, whenever you call Mechanical Workbench, it's generating an input file (look for "ds.dat") that's fed into MAPDL. However, what's changed over the past several years is where the geometry, meshing, and post-processing is occuring. Geometry generation can take place within SpaceClaim or Design Modeler, and meshing is done using a variety of new and powerful meshers within Workbench. I can attest that these tools are far superior to the ones in MAPDL, but the biggest limitation to them is that they're difficult to script (especially externally) and as a result there are still users who choose to generate geometry and mesh within MAPDL. Hence your next statement:

Most of our previous work was done by APDL script, and it has some advantages. We do a lot of parameter studies, esp. for the modell geometry, which are not so easily done in workbench (at least with my limited skill set).

You're not the only one. Being able to do simple or even complex parametric studies all within a self-contained python script or module is extremely powerful. That's not to say that everything can be done within a python script, but as some open source geometry packages have shown (PythonOCC), it's possible to do generate reasonably complex geometries entirely within a CPython script. Tie this in with MAPDL, and you can have a fully parametric workflow that leverages ML tools such as tensorflow and plotting via pyvista or matplotlib.

And we have some discussions in our group, weather to move completly to workbench whenever possible, or if the easier python interface (compared to pure APDL) would be an argument to use both workbench and python scripting

There will always be tasks where it's better to use one or the other. Workbench is great tool to rapidly prototype, mesh, set boundary conditions, and solve. It's where a ton of development has gone and they've done a great job implementing features that make it easy to run analyses. However, it's limited by its IronPython scripting and you're unable call multiple products at either a granular or high level or use packages such as numpy, scipy, tensorflow, etc. Where pymapdl comes in is it adds the ability to do this, but right now it's focused on MAPDL. I can't guarantee that other products may or may not have this level of APIs or scripting in the future, but it's my hope that they will.

What is the roadmap?

That's a multi-billion dollar question, and until Ansys releases a public document, I'm unable to explicitly state what it is. However, I can say that Python, APIs, and better scripting will be in the future of Ansys, both within Workbench and outside of it.

It would be cool if they could learn both GUI and scripting, but right now, the combination of script and workbench seems not like the way to do it ^^

That will come in time, and feedback by users like you will help drive this development. I can say that Ansys is already moving in the direction of better supporting automation via scripting and APIs while continuing to develop the desktop GUI experience.

[jgd10]

It seems like this question has been answered and I will close the issue for now.

[akaszynski]

@jgd10, I'd like this to be added to the Q&A.

[jgd10]

With this added to the Q&A, I'm now closing this issue. Please make a new issue with the elements that still need to be added, if more need to be added!