How to create a custom crack in the Fracture section?

AlexGh

I need to add an object to the project tree that inherits the properties of ArbitraryCrack and has some additional properties. Is there an approach that allows this?
I have examined the .dll libraries Ansys.ACT.WB1 and Ansys.Common.Interop for the required functionality. I also reviewed the .js code in aisol\DesignSpace\DSPages but couldn't find anything suitable. Perhaps it's necessary to implement the interface of the abstract class IDSCrackAuto and somehow add the resulting object to the project tree. But how can I add it to the project tree? I couldn't find functionality for adding it to a specific place in the TreeView (the functions AddNodeAndChildren, recursiveAddNodeAndChildren didn't work).

I have been trying to solve this issue for a month now.

Mike.Thompson

I think you have run into a limitation that Mechanical doesn't really have methods for customizable mesh routines (like creating your own crack in a mesh), and also doesn't have extensibility/modification of native objects. You can create your own custom objects that interact and reference the other tree objects, but you may need to work within these confines to build your solution.

For highly customized solutions you can also look at building a tool from the ground up (vertical application) using PyAnsys.

Mike.Thompson

I don’t believe what you are trying to do is possible, and if it is, it is not recommended or supported.

The recommendation would be to use either ACT or python code objects to create a second object that adds properties for inputs or options, and you can use a property of this object to scope to the native arbitrary crack object.
This second object can do additional things or modify the behavior of the native object.
If you are able to provide more context on what specifically you’re trying to do, perhaps additional guidance can be given.

AlexGh

If you are able to provide more context on what specifically you’re trying to do, perhaps additional guidance can be given.

In my case, the crack growth calculation is performed. The crack is inserted through an algorithm for ArbitraryCrack. At each step of the crack growth, the crack surface is saved as a Part in the project tree. The user should not have access to some properties of ArbitraryCrack (CrackFaceNodes, CrackCoordinateSystem, LargestContourRadius) because their modification is unacceptable for my algorithm. Additionally, ArbitraryCrack should have extra properties that are important for my algorithm.

According to my concept, the user should perform the usual actions to add the ArbitraryCrack (create Fracture -> add the modified ArbitraryCrack -> input settings -> run the calculation). Then my crack growth algorithm will execute, using the modified version of ArbitraryCrack.

Of course, I could attach a property controller to ArbitraryCrack and use callbacks to prevent the user from making changes to specific settings, but this approach, in my opinion, would not be very convenient since the user would need additional explanations about how the algorithm works. My task is to make everything as automated and user-friendly as possible (perhaps this is my idealism), and I am very interested in ACT extension development, constantly trying to improve my skills.> @Mike.Thompson said:

I don’t believe what you are trying to do is possible, and if it is, it is not recommended or supported.

The recommendation would be to use either ACT or python code objects to create a second object that adds properties for inputs or options, and you can use a property of this object to scope to the native arbitrary crack object.
This second object can do additional things or modify the behavior of the native object.
If you are able to provide more context on what specifically you’re trying to do, perhaps additional guidance can be given.

@Mike.Thompson said:
I don’t believe what you are trying to do is possible, and if it is, it is not recommended or supported.

The recommendation would be to use either ACT or python code objects to create a second object that adds properties for inputs or options, and you can use a property of this object to scope to the native arbitrary crack object.
This second object can do additional things or modify the behavior of the native object.
If you are able to provide more context on what specifically you’re trying to do, perhaps additional guidance can be given.

@Mike.Thompson said:
I don’t believe what you are trying to do is possible, and if it is, it is not recommended or supported.

The recommendation would be to use either ACT or python code objects to create a second object that adds properties for inputs or options, and you can use a property of this object to scope to the native arbitrary crack object.
This second object can do additional things or modify the behavior of the native object.
If you are able to provide more context on what specifically you’re trying to do, perhaps additional guidance can be given.

AlexGh

I apologize for the duplicate quotes, it happened accidentally.

AlexGh

@Mike.Thompson said:
I think you have run into a limitation that Mechanical doesn't really have methods for customizable mesh routines (like creating your own crack in a mesh), and also doesn't have extensibility/modification of native objects. You can create your own custom objects that interact and reference the other tree objects, but you may need to work within these confines to build your solution.

For highly customized solutions you can also look at building a tool from the ground up (vertical application) using PyAnsys.

Thank you for your time. I think you are right. But if by some magic I find a solution, I will definitely share it.