How do I get the function to create an object from the object itself?

Is there a means of identifying the function that will create an object of a specific DataModelObjectCategory?

From what I can tell, the function can frequently be identified by prepending "Add" to the beginning of the DataModelObjectCategory. However, sometimes the function for a given object category (ObjectCategory) is AddObjectCategory___(). Other times, it is Add_____ObjectCategory(). There are cases where the creation function is similar to but slightly different from the object category (e.g., AddContactTool() creates a PreContactTool object when the parent is the Connections branch in the tree and a PostContactTool when it is the Solutions branch), and other cases where there is no connection whatsoever in the naming (e.g., AddInitialInformation() creates a ContactDataTable object. Furthermore, there are cases where two different creation functions can create different object categories (e.g., AddFluidSolidInterface() and AddSystemCouplingRegion() both create FluidSolidInterface objects, but the properties are different and cannot be modified). Finally, there are cases where one creation function creates the object that you'd expect a different creation function to create (e.g., AddDirectionalDeformation() creates a DirectionalDeformationTracker, not AddDeformationPlotTracker()).

The code I have now, tries to build the name of the creation function based on the DataModelObjectCategory of the desired object, but that fails due to the above exceptions. As a result, I started going through all the different objects that can be possibly created in an effort to build a dictionary to lookup the creation function given the object category, but as I was going through that, I encountered several instances where different functions created the same object category depending on various different factors. Therefore, I thought I'd ask if anyone here is aware of a means of determining the function to create an object based on either the object category or some other property of the object itself.

The goal is to be able to write out all the properties of an object to a text file and be able to import the text file / create the object / set the properties in a new model.

Find more posts tagged with

AnsysACT

Mechanical

IronPython

scripting

Structures

Accepted answers

All comments

James Derrick

Hello! I think @AKD-Scripting-Team might be able to help

Tough.
If you have something random from the Mechanical tree, you could use parent to determine where it is in the tree.
name = 'Sizing'
original_item = ExtAPI.DataModel.GetObjectsByName(name )[0]

item_parent = original_item .Parent

Then use dir to get all the parent completion possibilities to a variable.

dir_parent = dir(item_parent)

Then use the type from the original item to try to locate how that item would be created with script.
creator = [i for i in dir_parent if name in i]

Which would return: ['AddContactSizing', 'AddSizing', 'UseAdaptiveSizing']

Which gets you pretty close to being able to generate namefrom some saved data and properties...

And if you are patient, you could then grab all the properties from your original (name) and then with the limited list of possibilities (creator) see which, when generated in your new model, has the same list of properties. That would be the one to create.

hack, hack, hack.

Just some ideas how it could be started.

tlewis3348

I'm assuming name = original_item.Name, and spaces, parentheses, hyphens, etc. are removed?

This would make a few assumptions, including at least these:

The user has not changed the name.
There aren't object names with text that isn't a subset of the creation function's name.

I'm actually somewhat close to having a complete list of all the creation functions and the resulting DataModelObjectCategory, and by all appearances, there is not a simple means of obtaining the creation function from the created object. Even with the full list, the dictionary I create will need to include in some instances where different creation functions will create objects from the same category with different settings. For example, almost all the objects that are named "Phase Response" are from the same object category as the objects named "Frequency Response". For example:

AddDeformationFrequencyResponse() => DeformationFrequencyResponse
AddDeformationPhaseResponse() => DeformationFrequencyResponse

In any case, this and similar issues seem easier to resolve than identifying all the special cases of naming oddities, even if it is clunky.