Post #4 Interactive Blocks & AI In ABAQUS

Dynamic generation of a 3D block in ABAQUS via an interactive dialog box

Question: Does AI bring productivity benefits when creating plugins for ABAQUS?

Exploring whether AI tools can assist the engineer to develop interactive plugins for ABAQUS. First test: developing a plugin that interactively generates a block with its dimensions controlled from a dialog.

Introduction

My belief is that productivity and quality improvement are the reasons to use scripting for ABAQUS. The gains in both can be huge. So, can other tools help bring about those gains more quickly? I have been learning a lot about using the latest LLMs recently, including prompting courses and the excellent introductory course I took with the IMechE. One of the most exciting use cases for me is assistance in improving and speeding up my code creation.

I am not a formally trained software professional. I am a mechanical engineer who has learned on the hoof and probably has the world’s supply of bad coding habits. An AI assistant which can nag me to get better seems like a great idea. One that can generate boiler plate code for me so I can generate interesting new apps more quickly sounds like a heaven-sent opportunity.

There are lots of demos online using very short prompts to get complete working apps back, for example clones of old console games. While I view these results with some little scepticism, it is enough to get me interested. Given my interest in Python scripting for ABAQUS it is obvious that I must try out some of these tools to see if they can help me create new plugins and scripts for ABAQUS.

Attempt #1

I have VS Code set up with the free version of Github’s Copilot. I started using Claude Sonnet 3.5 – I know better, newer, ones are available, but I want some proof of concept before I part with my over-taxed pennies.

My test case is a simple plugin which has three sliders that control the width, height and depth of a block that is updated in real time as the sliders change value. This is an example that I put in my book, ABAQUS Scripting Springboard. I am intrigued to see how the AI does straight out of the box with a very limited prompt.

I tried the recommended ‘agent mode’ first. The initial prompt:

Create a python plugin for ABAQUS. The dialog shall have three slider controls whose values define the width, height and depth of a block. The dialog shall be interactive, and the block size shall change immediately when the user changes a slider value. The plugin will be registered with a menu entry to launch it.

The results are odd and more than a little disappointing. I have tried this basic prompt four times and got four very different results. None of them work or are remotely close to working.

Each attempt produced a different file format; three had all the dialog code in one file with a separate kernel script. One had an extra file containing the plugin registration code. This last is the worst in that the plugin never even tried to register, so the other errors in the code did not get a chance to appear. On the plus side the registration code was correct, if in the wrong place. The other attempts were not correct without additional prompting. One attempt created an init.py file for no obvious reason.

For the most part the body of the code was useless and more or less unfixable. None of the attempts from this initial prompt came close to usable code. Beyond incorrect structure, and missing important elements, the output also fixated on functions and syntax that does not exist. Examples of the hallucinations that it came up with include:

self.heightSlidere = FXHorizontalSlider(	p=self, target=self, 
					selector = self.ID_HEIGHT_SLIDER, 						
					opts=SLIDER_HORIZONTAL|SLIDER_ARROW_DOWN)

Snippet1: There is no such widget as FXHorizontalSlider. This is a mixture of AFXSlider and FXHorizontalFrame. The rest of the syntax will work for an AFXSlider object.

self.width_slider = AFXSlider(p=GroupBox_1,            	
		opts=AFXSLIDER_HORIZONTAL|AFXSLIDER_INSIDE_VAL|LAYOUT_FIX_WIDTH,
		x=0, y=0, w=200, h=30,
		min=1, max=100,
		tgt=form.width_kw, sel=0)
self.width_slider.setValue(10)  # Default value

Snippet 2: In this case the AI has tried to create the slider widget correctly, however, the second option does not exist and you cannot define the range of the slider using max and min, especially not within the widget constructor.

cmd = 'BoxBuildKernel.create_cube(%f, %f, %f)' % (width, height, depth)
self.form.issueKernelCommand(cmd)

Snippet 3: The AI tried to call a kernel command from a message handler triggered by the movement of a slider control. This will work, but not using this non-existent call issueKernelCommand, the example later will use the correct sendCommand.

Attempting to use the AI to correct the code resulted in duplication of errors and the assistant doubling down on the non-existent functions. Significant debugging is required to make any of these samples operate. This requires a very clear understanding of what the answer should be before you start.

Revising My Prompt

Maybe my prompt was not clear enough. So, I had a think. While thinking I browsed YouTube and ran across the LYRA meta prompt. Again, enthusiasm for this sort of thing is running wild so I thought I would jump on the band wagon and see if the improved prompt that it suggested made any difference.

I restarted the project so that it would try to generate a result from scratch. I then gave it this much longer prompt generated by LYRA:

Write a Python plugin for Abaqus/CAE 2022 that adds a new menu item “Interactive Block” under the Plug-ins menu. When selected, it opens an Abaqus native dialog containing three floating-point sliders labelled Width, Height, and Depth, each ranging from 1.0 to 10.0. As the user drags any slider, the plugin must immediately modify or recreate a single solid block in the active viewport with the corresponding dimensions, without requiring an “Apply” or “OK” button. Use only Abaqus’s built-in GUI classes (, , , etc.), implement event handlers for real-time updates, and include:

1. Full import statements (, , ).

2. A mediator or form class that defines the three sliders and binds their

events.

3. Methods that generate or update the block geometry in the current

model database () and refresh the viewport.

4. Registration code to hook the plugin into the Plug-ins → Interactive

Block menu on startup.

5. Clear comments explaining each section and how the sliders trigger

the geometry update.

Ensure the code is ready to drop into a file in the Abaqus plugins directory and runs under Python 3.7 (Abaqus 2022).

Key Improvements:

• Explicit environment and version (Abaqus/CAE 2022, Python 3.7) to

avoid compatibility issues.

• Clear menu registration instructions so the plugin appears under

Plug-ins → Interactive Block.

• Real-time geometry update requirement spelled out, removing any

ambiguity around “Apply” or “OK.”

• Detailed widget classes and event binding expectations for

immediate feedback.

Techniques Applied:

• AI persona assignment (“Write a Python plugin…”) to focus on code-

generation expertise.

• Layered contextual information (version, target menu, GUI classes).

• Explicit output specification (complete file, comments, drop-in

readiness).

• Task breakdown into imports, UI, event handlers, modeling,

registration.

Pro Tip:

When binding events, use (and equivalents) so each drag instantly invokes your geometry-update function.

This time, something very similar was produced, but now in only one file. A mass of hallucinations, missing elements and nonsense. The kernel script has been included in what should be the dialog definition, which is derived from the wrong base class. Needless to say, this code did not even register as a plugin, far less actually do anything. Attempts to prompt it to improve resulted in massive duplication of already incorrect code and further hallucinations. In short total chaos.

In its initial form, shown below with some of the issues highlighted, it can be salvaged with some significant editing, but again, you need to know what the answer should be before you start. It does not offer any advantages over developing your own libraries of templates and using the RSG plugin as demonstrated below.

Snippet 4: The results from the GitHub Copilot chat when prompted using the more specific output from LYRA. Some of the errors are marked up.

I suspect that the issue is that there is not enough training data available for the ABAQUS specific parts. I shall not be making the electronic version of my book available for them to scrape any time soon! Pure Python code works quite well in my very limited experience so I shall use the AI to generate better elements within the kernel scripts, but GUI building still requires some proficiency from humans.

A Working Example – Not The Best Way

The easiest way to get started with GUIs is to use the Really Simple GUI (RSG) plugin that ships with ABAQUS. It will do 90% of the things that most users need a GUI to do. It will not, directly, allow you to create interactive GUIs. You can use RSG to build the bulk of the GUI, save it as a standard plugin and then edit it. The preferred method for making interactive GUIs is to use keywords attached to the controls and the processUpdates function, which is the way the example in Chapter 45 of ABAQUS Scripting Springboard works.

This was not what the AI was trying to do. It was attempting to use the messaging system that is normally used to respond to button pushes. You can make this work, as the demo below shows, but there is a price: keywords cannot be updated by controls that are already linked to a message. The data values have to be accessed directly from the control, which means that there are no keyword values available for the GUI to send to the kernel when the OK button is pressed. This example has no keywords in it at all, no AFXGuiCommands are sent and there are no keywords. This is not recommended, apart from anything else you have to manage all the value updates and keep any related variables correct, which the messaging framework and keywords can do for you.

Warning: If you are sensitive to flashing lights put a delay timer into the message handler in the dialog definition file; the updating solid flashes very rapidly with changes to the slider position.

A dialog definition file set up to work with this non-standard method of gaining an interactive response for the kernel part. Note how the value of the slider control itself if passed out to the kernel via sendCommand, rather than using keywords. This is NOT recommended!

The matching mode or form definition for the interactive block creation plugin.

Kernel script to generate a part called Interactive Box in the current model. Works by overwriting any existing part with the same name.

Conclusions

Playing with the prompting method is not helping the quality of the results from the AI. While my prompting technique, as a newbie, is probably poor, I suspect a lack of training data is also in the mix for the poor results. I probably need to try adding some context, possibly in the form of blank plugin files, more or less templates.

At that point much of the gains are eliminated since RSG works very effectively to generate useful GUI templates. I shall continue to experiment with the ABAQUS side but feel that for the moment at least the biggest gains are to be had in generating useful Python snippets to incorporate into the kernel script rather than on the GUI side. There is very clearly no substitute, at present, for understanding what you are trying to do and how you do it.

To obtain the source code for this demo become a member of the site and click the download button at the top to browse all the blog post source code examples.