Over the past 10+ years, ANSYS has steadily migrated more and more functionality into the DesignSpace, wait Workbench… no I mean Workbench Simulation or rather now ANSYS Mechanical product line. If you’ve used ANSYS in the last 5 years you’ve probably come to know this interface as Workbench, and you’ve probably delineated it in your mind as standing in opposition to the old interface, “Classic” or Mechanical APDL. Perhaps these qualities of each interface come to mind for you as they do for me
Mechanical APDL is:
- Old looking and visually clunky.
- Quirky, but powerful.
- The only thing “real” analyst use.
- Scriptable, Scriptable and More Scriptable.
ANSYS Mechanical is:
- Cool, slick looking user interface
- Super easy to use when your analysis is supported out-of-the-box.
- Great meshing and geometry support.
- Not scriptable.
Fortunately for us the margin in capabilities between Mechanical APDL and ANSYS Mechanical is narrowing at each release and so more and more “real” analyst are turning to ANSYS Mechanical for their simulation needs. However, one glaring difference between the two products that has remained virtually unchanged since the beginning is in the area of scripting. Mechanical APDL is scriptable at its core. In fact, that is the only way I personally interact with the program, which I’m sure is true for many of you as well. ANSYS Mechanical on the other hand appears as though it is just an impenetrable black box. It does what it does and that is that. Fortunately, that is only partially true. The reality is there is a whole underworld that exists in ANSYS Mechanical that is scriptable, it is just very cleverly and discretely hidden. (i.e. It isn’t documented) ANSYS, Inc. plans to keep it that way the best I can tell. However, I’ve spent the last few months of my life painstakingly pulling back the layers and peeking inside. So, I hope to show you some interesting tidbits I’ve found along the way.
Anatomy of DesignSpace
Why am I going back to calling ANSYS Mechanical DesignSpace? Well, as you might imagine, developers aren’t quite as flexible as the marketing types, so a lot of the code that is ANSYS Mechanical still carries the moniker DesignSpace, or DS. You can imagine the mutiny that would occur, if every time a suit got the bright idea to change a product name, all the developers were required to rewrite their code to reflect the new name. It ain’t happening.
So, what does DS look like on the inside? Well, the best I can tell it is architected this way:
The outer shell (aka the impenetrable black box) is the GUI. Obviously, this is how the user typically interacts with the program. However, the GUI itself is not a statically compiled piece of executable code. It is more like an interpreter that builds itself every time you launch ANSYS Mechanical. (You may be asking yourself, “Self, is this why it takes so bloody long to load…” Self replies “Perhaps… BTW, I need more coffee.”) So, the next logical question is “How does it know what to build?” I’m glad you asked, because this turns out to be one of the keys to unlocking the black box. The structure of the ANSYS Mechanical GUI is described in a handful of XML files. This is important for a couple of reasons:
- XML is just text, so you don’t have to put on your binary glasses to read it.
- XML has structure. Brains really like structure.
It may seem like I’m getting nowhere fast with this, but hang with me. Where we are at now is that the structure of the GUI is described by an XML file. So what that means is that the text associated with all of the menus and buttons in the GUI; whether a GUI entity is a toolbar, or a toolbar button or a menu item; all of that is described textually inside these XML files. However, a GUI that doesn’t interact with the user is just a G. How does the UI come into play?
Stay tuned for the next installment to see this in action.