Using Command Snippets in Solution (And a cool new ACT Extension to make life easier)

So you have results for a job that took several hours to run, or several days, and now you realize that you need to use a post-processing command snippet. In the past, prior to version 14.5, this would be a huge problem, because just adding the command snippet in the Solution branch would trigger a resolve. So, in those cases, we would usually just jump over to MAPDL to do the post-processing.  In version 14.5, however, ANSYS allowed you to add the snippet to the Solution branch without triggering a resolve.

When you hit “Evaluate All Results”, Mechanical will copy the files to a scratch directory and start a separate MAPDL session. This leads to a secondary problem. Often you need to select nodes or elements to use during your snippet. This is usually done with a Named Selection, or a material ID that you saved to a parameter in a Geometry command snippet.  The problem is that the Named Selections, or components in MAPDL, are not saved in the RST file, neither are parameters. They are stored in the DB file. If you thought ahead, then in the Analysis Settings, you set the ‘Save DB file’ option to ‘Yes’ before you solved. In your post-processing command snippet you could then use the RESUME command to bring the database back to the state that it was just before the solve – having all your Named Selections and parameters. But since the default is to not save the DB file, odds are that you don’t have it.  It’s okay, though. There are still some options.

The first thing I recommend is that you save the solved project, and then do a ‘Save As’ to make a copy from which to work, just in case something goes wrong.

Method 1:

When you hit the Solve button in Mechanical, it writes out a ‘ds.dat’ file that then gets run in a batch MAPDL run.

If you have all of your needed Named Selections setup prior to the Solve, then you can open an MAPDL session and use the File>Read Input From… command to read in the ds.dat file.  In interactive mode, the file stops just before the Solve command, so you can then save the database file at that point.  You then need to right-click on the Solution branch in Mechanical and hit “Open Solution Directory”, in to which you need to copy the new “file.db” file.  Then you can resume the file.db in your post-processing command snippet. 

If you need to add a new Named  Selection, you can add a new one, even in 14.5, without triggering a resolve, but then you will have to write out a new input file. To do this, highlight the Solution branch in the tree, go to Tools>Write Input File…, and then follow the procedure above.  

Method 2:

If you are using version 17.1 or later, you have another option. You can Right-click on a Name Selection and choose “Create a Nodal Named Selection”. Then right-click that new nodal named selection and hit “Export Selections to CDB File”.  You can select several Nodal Named Selections to export, and the export will all go to one file. Include that text in your snippet.

Method 3:

In R19.2, the Named Selections are now stored in the RST file. If you don’t need to add a new Named Selection, then can you access the Named Selections that were created prior to the solution run.  After a SET command in your snippet, you can just use the name in the NSEL command, as I did in the picture above, with no need to include the CMBLOCK from the CDB file.  If you need a new Named Selection, however, then you have to use Methods 1 or 2 above.

Pitfalls:

Now that all sounds somewhat difficult, and it actually gets worse. With Method 1, you have to know at least enough MAPDL to open it and read in the input file, and then save the database file.

With Method 2 and 3, the parameters are still not saved in the RST file. So if you need parameters that were created in earlier command snippets, then you have to go back to Method 1.

But there’s hope!!

Method 4:  Oh, Joy!!!

There is one other thing that you can do, and this is my favorite method. (Probably because I wrote it. J)  There is now a new free ACT extension in the ANSYS App store. It is called SAVE_DB, and was written because yours truly got tired of dealing with the other three methods above.  SAVE_DB allows you to save the MAPDL database file without having to solve the Mechanical model, or cause a resolve. SAVE_DB will automatically change the Analysis Settings > Analysis Data Management > Save MAPDL DB value to “Yes” so that future resolves are also saved. MAPDL will be run in the background on the same version as the Workbench project, and the “file.db” will be saved to the Solver Files Directory.  Now any new Named Selections that you add will be ready at the push of a button. This one:

This is the first of many helpful tools planned for a PADT_Toolkit. I will post another plug, I mean ‘blog’, when I get more tools added and the PADT_Toolkit uploaded to the APP Store.  Until then enjoy SAVE_DB!

Beware the ARGS, Matey!!

Pirate Joke:
One day me ARG says, “ARG, go to ARG and get the ARG to ARG the mainsail.” I says to me ARG, “ARG went yesterday. The ARG is over yonder by the ARG and the rum! Ha-ha-ha-ha-ARG!!”

Yeah… pirate jokes don’t work so well when the same ARG is used in too many places. The same goes for command snippets.

Summary Note: This article got longer than I intended, so here is a summary of the important points.

1. When using multiple Command Objects in a single mechanical session, the ARG variables initialized in earlier scripts are still active in later snippets if the ARG values for that snippet are not filled in the details window. Don’t assume the ARG values are zero, unless you set them to zero.

2. Output arguments are evaluated at the end of the MAPDL run. If the same variable name is used in multiple command objects, all the snippets will show the same output value, which is the value of that variable at the end of the solution process.

Now you can keep reading if you’re bored, or curious, or just confused. Smile

Up until a few days ago, I was under the impression that each command snippet that was added to a Workbench Mechanical had it’s own set of ‘ARG’ variables, like MAPDL does for macros, since each one has a details window with it’s own set of ARG Variables. Well, they don’t.

image

When you hit the ‘Solve’ button in Mechanical, it builds one large input file that it sends to MAPDL. This input file contains all the nodes and elements, loads and supports. It also contains any command snippets that you have in the model. All command snippets are run in the main namespace. ARGS from one snippet carry over to another.

As an example I set up a small command snippet with the details from the above picture. It uses two arguments, ARG1 and ARG2.  Below shows exactly what get added to the overall input file.

image

 

The first two lines are added by Workbench to initialize the variables. All looks good and works fine, until I add another command snippet.  This one is even simpler and just stores the ARG variable to defined variables that Workbench will then read back to the details window, which is discussed below.

image

As you can see below, the ARG1 and ARG2 variables are left blank, but the two output variables match what was set in the previous command snippet.  This is because the*SET commands that Workbench adds, are only added when the details window has values given. So ARG1 and ARG2 are never overwritten from the previous command snippet.  The way to avoid the overlapping of input variables is to fill in the Input Arguments with zeros whenever using multiple command snippets.

image

image

Which brings up another point, about output variables. As many of you know, but some may not, each command snippet has a “Parameter Search Prefix”, which is set to “my_” by default. This allows Mechanical to search through your snippet and find any variables that you define that start with “MY_”. In the example above, the output variables are MY_ARG1 and MY_ARG2. (Remember that MAPDL stores all variable in uppercase.) The values of these variables are then pulled out of the MAPDL database and shown in the details window for that command snippet.  The values are taken at the end of the solution phase, and not at the time they are defined. So this means that if two or more command objects use the same output variable names, whatever value the last command object set for the variables, that is going to be the same value read back in and displayed for all of the command objects using that variable. The best way to avoid this is to use different output variable names in each command object.

Since I already gave you the good points in the summary, I won’t restate them here. I will just add that command objects are great for adding functionality to your Workbench Mechanical runs. Just be cautious ARGS when using multiple objects. (Or pirate jokes, for that matter.)