When developing customizations for Mechanical APDL, you can avoid problems and reduce debugging time by following a gradual, orderly process. Start with a trivial test. Then, add a few changes at a time so that if something goes wrong, the error that caused the problem should be isolated and relatively easy to locate.
The example procedure below illustrates this type of gradual process. The example assumes that you are creating a new element using the method described in Creating a New Element by Directly Accessing the Program Database. You develop and test it by performing these steps:
Get the applicable element subroutines for
uel101from the product distribution medium. Add a small change (such as a misspelling in an output heading), then compile and link the subroutines.Using a production version of the program, run several analysis problems using various elements to form a base for comparison.
Run the same problem using USER101 on your custom version of the program.
Compare the results from Steps 2 and 3. If they show discrepancies other than the misspelled output heading, resolve them before you go on to Step 5.
Choose the standard Mechanical APDL element that most closely resembles your new custom element, and run some problems on a production version of Mechanical APDL using that element.
Modify the element subroutines to match the element you chose in Step 5. Then, compile and link those subroutines into a custom version of Mechanical APDL.
Again, compare the results from Steps 5 and 6. If they don't match, resolve the discrepancies before moving on to Step 8.
Modify your element subroutines to include the features you want. Then, compile and link the subroutines into a custom version of Mechanical APDL.
Test the changes with a series of increasingly complex problems for which you already know the answers.