About the direction of PyMAPDL

[germa89]

Hi all,

Recently I have receive an email from a colleague saying he would like to contribute to PyMAPDL by creating some high-level functions for cohesive elements. I'm super happy someone wants to contribute to PyMAPDL in anyway, and this one I think it is going to be highly appreciated by the users.

However, this raises some questions regarding the place for those high-level functions.

Until now, PyMAPDL has been seen as a Python wrapper for MAPDL. This explain why there is one-to-one correlation with MAPDL, and there are not high-level functions outside the ones that replicates MAPDL features (plotting for example).

But I wonder if this is the right approach.

Hence I would like to poll people's opinion (this poll is noncommittal) on this matter.

The links to each option page are:

• Option 1 - High-level functions in PyMAPDL - About the direction of PyMAPDL: Option 1 - Only PyMAPDL #1206
• Option 2 - PyMAPDL + PyMechanical - About the direction of PyMAPDL: Option 2 - PyMAPDL + PyMechanical #1207
• Option 3 - PyMAPDL + Other library - About the direction of PyMAPDL: Option 3 - PyMAPDL + Other library #1208
• Option 4 - PyMAPDL + Submodule - About the direction of PyMAPDL: Option 4 - PyMAPDL + Submodule #1209

--
Pinging @pyansys/pyansys-core @pyansys/pymapdl-developers for visibility

[germa89]

In my opinion, PyMAPDL should be as close as possible to MAPDL for the following reasons:

• It makes the transition easy for people coming from MAPDL (which are a lot!)
• MAPDL is quite stable in terms of features, PyMAPDL will inheritate this, making building libraries on top of it quite reliable. PyMAPDL will become the MAPDL API for high-level abstraction libraries.
• You isolate low-level functions from high-level functions, this will help to reduce size and dependencies when someone wants to build directly on top of PyMAPDL.

I see there are some cons:

• You have to maintain two libraries

Hence in my opinion the approach PyMAPDL (low-level) + PyMechanical? (high-level) is the most sensible to me.

However, it seems that Mechanical is going to take a while to take that place. Furthermore, I'm not 100% sure PyMechanical will go in that direction. The delay in having a high-level abstraction library can cost us collaboration opportunities (like the one mentioned above). Hence I think we should have something to have those high-level contributions while we wait on a consensus on the PyMechanical directions and PyMAPDL implications of it.

I would go for having a pymapdl-extras submodule, which can be made a package if we see it grows in size. However I guess making a package could be also fine?

[FredAns]

Hi @germa89 !

That's an interesting topic. Here we have this goal to code some advanced tools based on the existing PyMAPDL API.
My feeling is that we should distinguish the existing PyMapdl API, which is as you say close to the existing MAPDL API. and higher-level advanced developments for very specific use cases.
My guess is that we should have a toolboxes section for advanced developments so we keep the existing set of python code as generic and minimal as possible.
Perhaps this is a discussion we should share with the dev community project, as it goes in this direction ( aggregation of contributions for specific needs).

[germa89]

We should probably bring this up in our next pymapdl-dev meeting.

[germa89]

So I guess you opinion is closer to Option 3 - PyMAPDL + Other library - #1208

[rmanno91]

Hi @germa89 is the pymapdl-dev meeting just addressed to developer or anyone interested can attend?

[germa89]

Hi @rmanno91 these are intended mainly for Ansys developers, but anyone can join :)

[dnwillia-work]

Is the proposal to make the 'high level' API written in terms of the APDL commands? If so then I think it would make sense to include that directly within the library as it is.

However, if APDL were to expose an alternate 'high level' API using gRPC again it might be better to break that out to a new module.

So, it's hard to answer your survey unless the plan / proposal is a bit more clear.

BTW I think it's fair to say that APDL commands are not an API, they are a scripting interface for APDL, so it would be good news to have an actual API on APDL...

[germa89]

I think we cannot build a high level API with APDL. That would mean you need a MAPDL implementation, which we rather not.

The idea will be having something like:

mapdl.analysis.modal(n_modes=10)

instead of:

mapdl.slashsolu()
mapdl.antype("MODAL", n_modes)

mpdl.blabla...

So the high-level API won't be APDL syntax based, but it will be using PyMAPDL under the hood, and it will use PyMAPDL gRPC API.

GitHub pools dont allow much info in the responses. But I will look for a work around.

[germa89]

@dnwillia-work I have re-worked the poll, so there is more space for discussion in each option page.

[dnwillia-work]

Right, ok, so if what you mean is having a set of alternative commands that encapsulate calls to other commands, then I think that should live in PyMAPDL. Though @chris-hawkins-usa makes a good point about being able to invalidate the wrappers (see below).

Looking at your poll I would actually think both options 1 and 2 can be implemented and that it makes sense to keep PyMechanical as a separate package from PyMAPDL.

[dnwillia-work]

@germa89 That said, I'll pick 'option 2' in the poll but qualify that with I think option 1 is totally fine too, and that if PyMechanical does not happen for some reason or does not meet the need then you need to go option 3. Sorry, it's still not an easy answer.

[koubaa]

@germa89 I'm planning to eventually have a "mechanical kernel" library that is more lightweight than Ansys Mechanical but reuses much of its code, and it will include some of what you describe. For now - I vote for option 3.

@dnwillia-work it sounds like you were already thinking along the lines that I am, because eventually I can compile the mechanical kernel into mapdl.

BTW - I think we should seriously consider a session free version of pymapdl, where python manipulates an mapdl data-model without requiring a session of mapdl.

[dnwillia-work]

@koubaa Yeah, I think so. Assuming PyMechanical is modular and delivers what you need (eg: the engineering data model) then makes sense you would want to integrate it as you say.

Regarding your last point about a 'session free' thing, I would have thought that is PyMechanical, at least for the pre-processing, and DPF for post processing.

[koubaa]

@germa89 dpf can not build an mapdl data model. Think of it like a cdb file - something you can build without an mapdl session. In the same way, I'm imagining a python library that builds up the mapdl data model (FEA nodes, elements, material models, boundary conditions) and then only runs mapdl at the point of solve.

@dnwillia-work Actually I am opposed to integrating pymechanical in that way. mechanical-kernel is not going to be based on pymechanical - it is something much smaller than mechanical, it doesn't include any meshing or post. Its just a mechanical->mapdl data model conversion library.

[dnwillia-work]

@koubaa OK, so you are talking about something different, my mistake.

How about a different perspective on this poll from a potential consumer of these things. What should I use to drive APDL from PyFluent then (eg: for FSI)?

1. PyAPDL directly and write my own abstractions on APDL commands
2. PyMechanical
3. PyMechanical-Kernel

As someone on the outside why should I choose one of these over the other. Hard to answer this with a poll.

[koubaa]

@dnwillia-work

Mechanical contains a lot of IP on how to properly convert a CAD-based data model to MAPDL/FE. If that's the sort of thing you're looking to do, I suggest not (1), since you risk making wrong assumptions that could lead to incorrect results (i.e. class 3).

Between 2/3, it depends on whether you're willing to actually run mechanical or not. the kernel is more lightweight, way fewer dependencies, etc.

[dnwillia-work]

I guess I would need to understand what the 'kernel' does that Mechanical does not because the IP that is in Mechanical has a lot of value right.

For instance, in principle I also don't see why the data model needs to be strongly tied to CAD, it should be strongly tied to a topology that is independent from CAD or imported/generated mesh. Does the 'kernel' support that? If so, I would be tempted to go that direction. i.e. I want to be able to create an APDL setup without bringing in CAD or mesh at all.

Maybe someone can fill me in on the plans for the kernel, I know nothing about it.

[chris-hawkins-usa]

Great topic...one question I would ask is are these higher level functions, with all state stored in MAPDL still, or would there be additional state (more OO-like). I think its fine to incorporate higher level functions, but I would be cautions of incorporating too many 'declarative abstractions' - because you can just drop down to the MAPDL command layer and invalidate those abstractions with 1 command and so I think they could be very leaky abstractions. I would imagine PyMechanical would expose abstractions like that., and could probably integrate nicely with PyMapl as 1 option. Depending on how PyMechanical shapes up that is :)

[germa89]

@chris-hawkins-usa exactly. It is going to depend a lot on what PyMechanical wants to be. Check @koubaa comments for more insight on this!

[germa89]

Regarding leaky abstractions, you are right. It should be possible to implement some logic to mitigate that (checking MAPDL versions, etc) but that risk is going to be there as long as there is abstractions which I believe they are needed for many users. But it's a very good point you made.

[FredAns]

Hi Everyone,
just to bring some materials into the discussions, what we have in mind are some high level features we have planed to add to the PyMapdl eco-system, which are made of encapsulation of existing PyMapdl code ( actually some drafts are already existing as MAPDL macros).

My first needs are more related to customized analyses like:

• a toolbox to expose Krylov algorithms in MAPDL, which could be used to solve some specific analyses like transient or harmonic analyses ( development is planned for 23R1 release, some resources have been committed).
• ability to solve Thermal Modal analyses: this is not possible today in MAPDL, but it can be done at a Macro level ( sequence of MAPDL commands).
• a toolbox to help using the Full File in Mapdl ( so a kind of Full File Toolbox)..
• ..

At the end, we can expect internal and external developers ( at the developer community sense) to contribute to the PyMapdl ecosystem by proposing new capabilities, based on the 1st level of functionalities the existing PyMapdl is offering.

But I think we need to separate what is the low level access to MAPDL commands, which includes all that have been developed until now, and all these contributions that could possibly represent a large amount of additional but optional code. That's why I would not put these contributions in the existing GIT repos.

[germa89]

I 100% agree on this.

[akaszynski]

Agree as well. This follows Separation of Concerns.

[natter1]

I would like to give my limited input from a users perspective. As I discussed with @akaszynski in the early days of PyMAPDL, ANSYS (not only mechanical) has too many different ways to do things. Personally I would prefer, if it would be possible to script everything with a similar api (python based) both inside workbench or completly external (like with PyMAPDL). Ideally the script functionality should have some similarities to the functionalities inside the GUIs. I know, thats a very long-term perspective but imho its important to consider it right from the beginning.

Therefore I would not choose option 1 or option 4. Not everything in ANSYS is based on APDL. A high-level api might use different low-level layers (right now that would be APDL and DPF). As a user I would like to only learn one (preferably high-level) API, so long term it should work without learning PyMAPDL or dpf-core (dpf-post is a similar high-level api idea(?); also the PyMAPDL plotter functionality could be moved to a higher level api, as it is not really part of APDL; same for the material database implementation which is still alpha(?)). PyMAPDL should be focused on APDL.

One major issue I see is, that a high-level API would be very limited in the beginning - similar to dpf-post, which is imho not useable right now. Therefore a macro-collection like intermediate step might be a good idea, also for user based contributions.

Another question about a PyMechanical - what functionallity should this handle? Geometry migh be more global than mechanical and therefore might be a seperate library? iMHO Post-processing should be based on DPF longterm, so everything in between for PyMechanical?

[akaszynski]

if it would be possible to script everything with a similar api (python based) both inside workbench or completly external (like with PyMAPDL).

Fully agree with this. Ideally we would have one "high level" api for running all of Ansys's solvers (even beyond mechanical), but at this point, just focusing on structural would be an excellent goal. A high level abstraction layer that sits over the existing Mechanical components but does not require "Mechanical" itself would be awesome. This, however, would be just the start. Ideally we'd have interfaces to:

• Mechanical data model, which would be pulled out of mechanical and be wrapped by "PyMechanical", this would be the high level abstraction layer over MAPDL/PyMAPDL that would effectively translate the engineering model into either individual PyMAPDL commands that could be run interactively, or in batch mode where everything could be run immediately as an "input deck".
• Design modeler. Even though it's fairly basic, it's a "history-based" modeler, which we currently lack with Discovery (SpaceClaim). Having that as a standalone library would allow us to at least have some degree of comparable features to NX and OpenNX.
• Post-processing (enabled via DPF-Core)
• Meshing
• Interfaces over the other PyAnsys libraries (PyFluent, PyLS-DYNA, etc.)

Being able to script end-to-end workflows entirely within Python, tying together multiple isolated "products" is emerging as an end goal of the PyAnsys project; one that will be limited on the time and investment into both "lower level" wrappers and higher level abstraction layers.

[dnwillia-work]

Regarding the first bullet point, to me that is what is meant by option 2, and it's why I voted for that option. I suppose though that others are thinking that all Mechanical functionality would be exposed via a PyMechanical library and so you might vote for option 3 because you think all of Mechanical is 'too much' or something. I'm not sure.

For me, it's hard to choose between options 2 or 3 because it's not clear what is meant by PyMechanical or 'other library'. If 'other library' means I don't have access to any of the capabilities of Mechanical at all then that option is less interesting I think. Mechanical has useful functionality in it that customers want.

[germa89]

PyMAPDL should be focused on APDL.

I STRONGLY agree with this. PyMAPDL should be the low-level API where you can build high-level API.

I agree with @natter1 that having a common API across all the ansys products will be the best, but as @akaszynski mention, this is very complicated because the very different physics, products, approaches within Ansys products. I would start with structural then, and ideally a fluent API. The rest of the products should try to adapt to one of them.

[chris-hawkins-usa]

Since it's Friday... I wonder if it's worth discussing the idea of an 'ansys data types' module., along with supporting protobuf definitions ? This would be a product independent definition of things that are commonly needed and exchanged. API.Service developers could use as part of their service implementations, that would carry over to other languages too. Wouldn't this become very valuable over time, esp if the community could enrich it, and have people reuse it as part of their own service APIs? Of course, we would need to domain experts to get involved , with strict guidelines and really manage it carefully with a well thought out review process, etc. That wouldn't directly solve the problem that @akaszynski mentioned, but would give some kind of a path to standardization that could be adopted incrementally ?