Joint restraints when the input is a list

[anagpuyol]

[anagpuyol]

Never mind, I got that to work, but the joints come out with no dyn label assigned

[anagpuyol]

Also, when I pass the frames and the joints together I get the duplicate warning in the collector

[anagpuyol]

and they are missing in SAP

[anagpuyol]

General discussion here:

For frames, we have been creating a new label when the load is set, as seen below. I think we should keep the same label and run the checkDuplicates method inside the collector. If the elements have different labels, we can't know if they are the same one, and thus the user might input the same element twice. I am exemplifying this on joints, where both are dyn_0.

Now, there is a bug in the creation of the IDs, which starts from zero on both joints and frames. We could add a prefix for the type of element: dyn_frm_0, dyn_joint_0, dyn_cable_0, dyn_shell_0 or keep track of all them in the trace cache. I like having a different label because one can easily check in the list what type of elements they are, but I also see how just "dyn_" is very clean. Thoughts @bhowes-tt @eertugrul ?

[eertugrul]

yes I agree with u for the first part, we have just talked, we are creating a new member but we are passing the label then we check the duplicated items at Collector node.

I set separate Trace mechanisms(TracedManager) for the objects such as Frame, Shell and Joint for now cable will be following next phase. So the labels' string format is the same but this doesn't create any problem on SAP and in Dynamo. The names are unique for each type of structure. Element class has Type enum, each time we create object we pass the appropriate type.

🌹

[anagpuyol]

This has already been addressed and fixed

[bhowes-tt]

I couldn't quite understand the issue during our meeting today, but it sounded like it still needs to be resolved... Assigning @anagpuyol

[eertugrul]

now it is working ! Beware the list should be Flatten list before collector! working now.

Thank you