One of the tough challenges in creating meshes for CFD simulations is the requirement to create a mesh that works with very different geometry. With Overset meshing you can create the ideal mesh for each piece of geometry in your model, and let them overlap where they touch and the program handles the calculations at those boundaries. All of this is handled simply in the ANSYS Workbench interface and then combined in ANSYS FLUENT.PADT-ANSYS-Fluent-Overset-Meshing-2017_07_05-1
With each release of ANSYS the customization toolkit continues to evolve and grow. Recently I developed what I would categorize as a decent sized ACT extension. My purpose in this post is to highlight a few of the techniques and best practices that I learned along the way.
Why I chose C#?
Most ACT extensions are written in Python. Python is a wonderfully useful language for quickly prototyping and building applications, frankly of all shapes and sizes. Its weaker type system, plethora of libraries, large ecosystem and native support directly within the ACT console make it a natural choice for most ACT work. So, why choose to move to C#?
The primary reasons I chose to use C# instead of python for my ACT work were the following:
- I prefer the slightly stronger type safety afforded by the more strongly typed language. Having a definitive compilation step forces me to show my code first to a compiler. Only if and when the compiler can generate an assembly for my source do I get to move to the next step of trying to run/debug. Bugs caught at compile time are the cheapest and generally easiest bugs to fix. And, by definition, they are the most likely to be fixed. (You’re stuck until you do…)
- The C# development experience is deeply integrated into the Visual Studio developer tool. This affords not only a great editor in which to write the code, but more importantly perhaps the world’s best debugger to figure out when and how things went wrong. While it is possible to both edit and debug python code in Visual Studio, the C# experience is vastly superior.
The Cost of Doing ACT Business in C#
Unfortunately, writing an ACT extension in C# does incur some development cost in terms setting up the development environment to support the work. When writing an extension solely in Python you really only need a decent text editor. Once you setup your ACT extension according to the documented directory structure protocol, you can just edit the python script files directly within that directory structure. If you recall, ACT requires an XML file to define the extension and then a directory with the same name that contains all of the assets defining the extension like scripts, images, etc… This “defines” the extension.
When it comes to laying out the requisite ACT extension directory structure on disk, C# complicates things a bit. As mentioned earlier, C# involves a compilation step that produces a DLL. This DLL must then somehow be loaded into Mechanical to be used within the extension. To complicate things a little further, Visual Studio uses a predefined project directory structure that places the build products (DLLs, etc…) within specific directories of the project depending on what type of build you are performing. Therefore the compiled DLL may end up in any number of different directories depending on how you decide to build the project. Finally, I have found that the debugging experience within Visual Studio is best served by leaving the DLL located precisely wherever Visual Studio created it.
Here is a summary list of the requirements/problems I encountered when building an ACT extension using C#
- I need to somehow load the produced DLL into Mechanical so my extension can use it.
- The DLL that is produced during compilation may end up in any number of different directories on disk.
- An ACT Extension must conform to a predefined structural layout on the filesystem. This layout does not map cleanly to the Visual studio project layout.
- The debugging experience in Visual Studio is best served by leaving the produced DLL exactly where Visual Studio left it.
The solution that I came up with to solve these problems was twofold.
First, the issue of loading the proper DLL into Mechanical was solved by using a combination of environment variables on my development machine in conjunction with some Python programming within the ACT main python script. Yes, even though the bulk of the extension is written in C#, there is still a python script to sort of boot-load the extension into Mechanical. More on that below.
Second, I decided to completely rebuild the ACT extension directory structure on my local filesystem every time I built the project in C#. To accomplish this, I created in visual studio what are known as post-build events that allow you to specify an action to occur automatically after the project is successfully built. This action can be quite generic. In my case, the “action” was to locally run a python script and provide it with a few arguments on the command line. More on that below.
Loading the Proper DLL into Mechanical
As I mentioned above, even an ACT extension written in C# requires a bit of Python code to bootstrap it into Mechanical. It is within this bit of Python that I chose to tackle the problem of deciding which dll to actually load. The code I came up with looks like the following:
Essentially what I am doing above is querying for the presence of a particular environment variable that is on my machine. (The assumption is that it wouldn’t randomly show up on end user’s machine…) If that variable is found and its value is 1, then I determine whether or not to load a debug or release version of the DLL depending on the type of build. I use two additional environment variables to specify where the debug and release directories for my Visual Studio project exist. Finally, if I determine that I’m running on a user’s machine, I simply look for the DLL in the proper location within the extension directory. Setting up my python script in this way enables me to forget about having to edit it once I’m ready to share my extension with someone else. It just works.
Rebuilding the ACT Extension Directory Structure
The final piece of the puzzle involves rebuilding the ACT extension directory structure upon the completion of a successful build. I do this for a few different reasons.
- I always want to have a pristine copy of my extension laid out on disk in a manner that could be easily shared with others.
- I like to store all of the various extension assets, like images, XML files, python files, etc… within the Visual Studio Project. In this way, I can force the project to be out of date and in need of a rebuild if any of these files change. I find this particularly useful for working with the XML definition file for the extension.
- Having all of these files within the Visual Studio Project makes tracking thing within a version control system like SVN or git much easier.
As I mentioned before, to accomplish this task I use a combination of local python scripting and post build events in Visual Studio. I won’t show the entire python code, but essentially what it does is programmatically work through my local file system where the C# code is built and extract all of the files needed to form the ACT extension. It then deletes any old extension files that might exist from a previous build and lays down a completely new ACT extension directory structure in the specified location. The definition of the post build event is specified within the project settings in Visual Studio as follows:
As you can see, all I do is call out to the system python interpreter and pass it a script with some arguments. Visual Studio provides a great number of predefined variables that you can use to build up the command line for your script. So, for example, I pass in a string that specifies what type of build I am currently performing, either “Debug” or “Release”. Other strings are passed in to represent directories, etc…
The Synergies of Using Both Approaches
Finally, I will conclude with a note on the synergies you can achieve by using both of the approaches mentioned above. One of the final enhancements I made to my post build script was to allow it to “edit” some of the text based assets that are used to define the ACT extension. A text based asset is something like an XML file or python script. What I came to realize is that certain aspects of the XML file that define the extension need to be different depending upon whether or not I wish to debug the extension locally or release the extension for an end user to consume. Since I didn’t want to have to remember to make those modifications before I “released” the extension for someone else to use, I decided to encode those modifications into my post build script. If the post build script was run after a “debug” build, I coded it to configure the extension for optimal debugging on my local machine. However, if I built a “release” version of the extension, the post build script would slightly alter the XML definition file and the main python file to make it more suitable for running on an end user machine. By automating it in this way, I could easily build for either scenario and confidently know that the resulting extension would be optimally configured for the particular end use.
Now that I have some experience in writing ACT extensions in C# I must honestly say that I prefer it over Python. Much of the “extra plumbing” that one must invest in in order to get a C# extension up and running can be automated using the techniques described within this post. After the requisite automation is setup, the development process is really straightforward. From that point onward, the increased debugging fidelity, added type safety and familiarity a C based language make the development experience that much better! Also, there are some cool things you can do in C# that I’m not 100% sure you can accomplish in Python alone. More on that in later posts!
If you have ideas for an ACT extension to better serve your business needs and would like to speak with someone who has developed some extensions, please drop us a line. We’d be happy to help out however we can!
Hey, did you know that you can access predefined views in both ANSYS Mechanical and DesignModeler using your numeric keypad? You can! Assuming the front view is looking down the +Z-axis at the X-Y plane, here are the various views you can access via your numeric keypad.
For this to work, make sure you’ve clicked within the graphics window itself—not on the top window bar, or one of the tool bars, but right in the region where the model is displayed. You may need to turn off Num Lock, though it works for me on both my laptop and desktop with Num Lock on or off.
With that out of the way, here are the views:
0) Isometric view, a bit more zoomed in than the standard auto-fit isometric view. This is my preferred level of zoom while still being able to see the whole model, to be honest.
1) Front view (looking down the +Z-axis)
2) Bottom view (looking down the -Y-axis)
3) Right view (looking down the +X-axis)
4) Back up to the previous view
5) Isometric view, standard autofit (I don’t like the standard auto-fit—too much empty space. I prefer the keypad 0 level of zoom.)
6) Go forward to the next view in the cache
7) Left view (looking down the -X-axis)
8) Top view (looking down the +Y-axis)
9) Back view (looking down the -Z-axis)
Here’s a handy-dandy chart you can print out to refer to when using the numeric keypad to change views in Mechanical or DesignModeler. Share it with your friends.
For many years we’ve been asked, “Can I use my old Mechanical APDL/ANSYS ‘classic’ model in Workbench?” Up until version 15.0 our answer has been along the lines of, “Uh, not really, unless you can just use the IGES geometry and start over or use FE Modeler to skin the mesh and basically start over.” Now with version 15.0 of ANSYS there is a new option that makes legacy models more usable in both functionality and level of effort required.
So what is External Model?
- A new capability at ANSYS 15.0 to use legacy MAPDL models in Workbench
- Reads the .cdb file (coded database) created from /PREP7 in MAPDL (CDWRITE command)
- Builds exterior skin geometry from the existing MAPDL mesh
- Creates solids from the skin geometry
- Retains the MAPDL mesh
- May have trouble for complex meshes, although we’ve been impressed in a couple of trials
- Has limitations on what is transferred into Mechanical
- No material properties, loads, or constraints
- May give you very large surfaces, making it difficult to apply loads on faces, but you can bring in nodal components from Mechanical APDL as Named Selections in Mechanical as an alternative load application method
- Allows us to apply new BC’s using geometry in Mechanical
Here is a representative Mechanical APDL Model. It’s a simple static structural run with loads and constraints.
Preprocessor > Archive Model > Write. Enter a name for the .cdb (coded database) file being written and click OK. Don’t worry about the .iges file.
Next, launch Workbench 15.0 and insert an External Model block from the Toolbox:
Next right click > Edit or double click on the Setup cell in the External Model block. Click on the […] button under Location to browse to your .cdb file created in MAPDL.
There is a Properties window (View > Properties) in which units can optionally be modified or a coordinate system transformation can be specified.
Next, click on the Workbench Project tab near the top of the Workbench window. Right click on the Setup cell and choose Update. You should now have a green check mark next to Setup:
Insert a new (standalone) analysis type to continue your simulation in Mechanical. Here we inert a Static Structural analysis. For some reason you can’t drag and drop the new analysis onto the setup cell, so we establish the link in a separate step shown below.
Note that the Model cell Properties contain a Tolerance Angle that can be adjusted to help with exterior skin geometry creation from the MAPDL mesh. Use this to help control where one skin surface starts and stops based on angles between element faces.
The two blocks are now linked as shown by the blue curve connecting Setup to Model:
Double click the Model cell in the new (Static Structural) analysis block to open the Mechanical editor. It should create geometry over the existing mesh, which is retained.
Although the mesh comes across, no material properties, loads, or constraints, etc. are retained from the MAPDL model
- These must be entered separately in Workbench/Mechanical
- There is no ability to remesh or modify the existing mesh
You can apply (or reapply) loads and constraints directly on geometry, or on nodal components that were defined in MAPDL which become Named Selections in Mechanical:
Solve and postprocess as usual in the Mechanical editor.
In conclusion, ANSYS 15.0 gives us new and enhanced capability for utilizing legacy models, particularly those from MAPDL saved as .cdb file format. Although not everything is retained, this capability does provide us with additional tools to reuse existing models without having to start from scratch.
A while back I did a webinar on POST26 in ANSYS Mechanical APDL and using it with ANSYS Mechanical. You know it was a while ago because… well… it was a webinar and I have not had time to do one of those for a long chunk of time now. Anyway, as usual the files used were placed on the blog in a posting.
Last night I got an email from a student in Australia who tried to use the file and found a problem with it. Now this was cool for a couple of reasons: 1) anytime someone from the opposite side of the earth reaches out to communicate, that is just makes my day, and 2) someone not only read the posting, but they tried to use it. Sometimes the only way we know people are using the content we create is when the find a problem. I’ll take it.
In figuring out what was wrong I figured it might be a good time to point out some things about the file manager in ANSYS Workbench, and how using it, you can fix the problem that this project had.
Projects – A Big Directory Tree of Folders and Files
If you ever looked at the directory your project is stored in you will see a big old tree of folders and files. All of the info needed or created for your project are stored in this directory tree. Why? Because the briliant thing about the project page is that it is designed to take all these different programs like ANSYS Mechanical, ICEM CFD, FLUENT, CFX, etc… and allow you to interact between them in a single tool set. In that each program was written by a different group of developers, and most of them when those developers worked at different companies, each one has its own unique file structure, files that it needs, and way of organization them. By giving each tool its own directory in the project, you can have the legacy data structure you need, but still keep all your files in one place where the project page actually knows where to find the information it needs.
Looking at your Files
This is done with the Files View in the Workbench Project page. By default it is hidden. Just go to View on the menu and click Files so it has a check next to it:
We did a post in the past explaining all the things this view does for you. Read it here.
Fixing a Missing File
If you should get the type of error message that our Australian friend got, you can easily remedy it with the files view. If it is missing it will show up with a big red X next to it instead of its normal icon. The whole line will in fact be red.
If you Right Mouse Button on it you will see a couple of options:
- Repair “filename”: This allows you to hunt and find the missing file. It should say “Identify Missing File” or some such, but repair works too. Click on that, find your missing file, and you are good.
- Remove “filename” is what you use if you don’t need the file, it is gone, and you want to get on with your life.
- Open Containing Folder is nice because it will take you to the folder that the file is supposed to be in. You might poke around in there and figure out what is going on.
That is it. Hopefully I made a mistake somewhere and someone from Argentina will email letting us know. I don’t believe we have been contacted by a user in Argentina.