strusoft / femdesign-api

FEM-Design API
https://femdesign-api-docs.onstrusoft.com/
Apache License 2.0
41 stars 20 forks source link

Add option to lock numbering of structural/analytical id #390

Open JRiad opened 2 years ago

JRiad commented 2 years ago

Hi! We have had some struggles lately with objects being re-numbered. For example, if the walls in a model are called W1, W2, W3.... they will sometimes be called the same thing when the struxml file is opened in FEM-Design again, but sometimes they will be renumbered.

To stop this from happening, we can put "@" before the slabpart name in the struxml. Then the numbering will be "locked".

It is also possible to lock the numbering in the FEM-Design UI, but this setting disappears when exporting to struxml. image

We think it should be possible for the user to choose if they want renumbering or not. When renumbering is good: For example if you want to merge two models, or create a lot of objects and not want to handle potential conflicts between elements with the same name. When renumbering is bad: When you want to keep track of certain objects.

I'm not sure how this best could be implemented. Some ideas:

This has also been mentioned in case #81

JRiad commented 2 years ago

@andosca @Marco-Pellegrino what do you think?

andosca commented 2 years ago

Having a fixed identifier was discussed in #81 and is planned for implementation. So having the possibility to lock the identifier on the component level will be done.

Problem with export from FEM-Design should be raised to BP dev. team.

andosca commented 2 years ago

Duplicate of #81

JRiad commented 2 years ago

Having a fixed identifier was discussed in #81 and is planned for implementation. So having the possibility to lock the identifier on the component level will be done.

Problem with export from FEM-Design should be raised to BP dev. team.

👍 Great! I saw it was discussed in #81 but I thought it is better to have a dedicated case for each topic 😉 On what components will this be implemented? Or is there going to be a new component for this?

andosca commented 2 years ago

It will be implemented on any component that creates or modifies an element (bar, slab, support etc.)

xRadne commented 2 years ago

It will be implemented on any component that creates or modifies an element (bar, slab, support etc.)

Why not have this operation (of adding a single "@"/locking the identifier) as a separate component? Like below. element could be of type EntityBase or IStructuralElement

image

I think there might be cases were you want to lock the identifier without modifying the element.

andosca commented 2 years ago

Having a fixed identifier was discussed in #81 and is planned for implementation. So having the possibility to lock the identifier on the component level will be done. Problem with export from FEM-Design should be raised to BP dev. team.

👍 Great! I saw it was discussed in #81 but I thought it is better to have a dedicated case for each topic 😉 On what components will this be implemented? Or is there going to be a new component for this?

Maybe you are correct. I figured that they were so tightly related.

andosca commented 2 years ago

@xRadne That is also an option. Would possibly make for more components. As we intend to have a constructor/modifier for each type of element why not have it on that one as well?

image
xRadne commented 2 years ago

@xRadne That is also an option. Would possibly make for more components. As we intend to have a constructor/modifier for each type of element why not have it on that one as well?

image

I suggest we do not add any extra input to the components (they have plenty of inputs already), But instead the identifiers can be locked using a @ in the beginning (which will be equivalent to the .struxml). We should also add a grasshopper component that locks/unlocks the identifier of any element. This will be more intuitive to most users that don't know how the .struxml works.

Marco-Pellegrino commented 2 years ago

using @ at the beginning of the Identifier is a good option.

I am not a big fan of "large components" with several input and a custom component might be better from my point of view

xRadne commented 2 years ago

using @ at the beginning of the Identifier is a good option.

I am not a big fan of "large components" with several input and a custom component might be better from my point of view

Just to be clear, Adding @ in the beginning is already working. But, I think it is unintuitive for beginners, and if you want to modify (lock/unlock) then it is needed to 1 deconstruct, 2 add @, 3 modify bar/slab/panel/edgeconnection etc with new identifier