APIname exists not for all variables of project

[ValentynBarannik]

Hello team,

We faced with the problem of automatic reading of Mechanical results. in our case the outputs are calculated based on python script. to add these outputs to project tree and read it automatically we used code my_+name_of_variable. after this the outputs are displayed in project tree. we read all inputs outputs based on API name that should be unique for each variable and is not requires the updating of variables list if name of variable is changed. but for "Comands (APDL)" variables the APIname is absent.
Could somebody help to solve this issue, maybe we incorrectly create the variables from script? There is a way to replace utilization of APIname to variables name, but it seems that APIname has advantages and it is more preferable to use this properties for out goals

Best regards,
Valentyn

[pmaroneh]

Hi @ValentynBarannik , can you share a couple of screenshots to illustrate? I'm afraid I don't understand your question here.
FYI the Ansys Developer Forum is prefered for these kind of questions.

[pmaroneh]

Thanks @ValentynBarannik, this helps. To be honest I'm never seen the use of APIName in any project except yours. Usually we don't even use the VisibleProperties and simply go :

total_def = ExtAPI.DataModel.Project.Model.Analyses[0].Solution.Children[1]
total_def.Minimum

which returns a Quantity.
Now, as you've experienced, APIName is missing for MAPDL command snippets, as well as a way to retrieve the results directly. I'll report this to the Mechanical API team as this is not related to PyMechanical but to the Mechanical API itself.
However, I'm still curious to understand why you prefer to use the APIName?

[ValentynBarannik]

Thank you , Pernelle for the response. We already reimplement in our tool the way you showed.
In general, by using APIName we saw some benefits, APIName does not relate to the User name of variable and for example if we created some workflow in optiSLang and made some mistake in name, renaming of User variable in Mechanical project will not change APIName and there is no need to update Mechanical connector in optiSLang or any other integration tool. In our integration tool if the name of variable is changed, it is equal to deleting of existing variable and creating the new one, with variable deleting all connections we have will be destroyed. So utilization of APIName allows saving of integration tool connections when the name of variable should be changed in Mechanical project

[pmaroneh]

Thanks Valentyn, this helps understand the need.

[pmaroneh]

Hi @ValentynBarannik , it seems that there is actually an API to access the results in a more straightworward way (thanks @koubaa for letting me know!) . Use: cmd.OutputParameters

[ValentynBarannik]

Thank you, Pernelle. we will try this approach as well