Replies: 2 comments 3 replies
-
|
Hello, Just a note to the third issue: I assumed that names are globally unique so you can't have two object with the same name neither with different types, since the IDs are not mandatory. Globally unique names will solve both issues 1 and 3, because than StructuralCurveAction, StructuralCurveMoment etc. don't have to know what is exactly the underlying object, it's enough that there are something which can act as a structural object's edge. I think this would make implementations easier and it would eliminate that erroneous case when you set the value of the "force action" enum but enter the underlying object's name in a wrong cell. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, we have always worked with names being unique within their own type, but this was never explicitly specified in the documentation. But if you've always worked under the assumption that names are unique across the entire model, even better! The force action kind of columns might look like a bit overkill indeed, but it does open up the ability to do more specific validations on your model and provide the user with better feedback. (which I believe was also the goal at the time, when we first introduced these sort of columns) With the current setup (force action column + dedicated column for each type of reference), you are able to generate messages like "You need to provide the name of ... because Force Action is set to ..." However, if you do not have a force action column, you'll have to use more generic messages such as:
Then from a technical point-of-view, which would be more performant you think?
But yes, globally unique names would have solved the issue if you only take into account the issue itself and not everything around it. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, full disclosure: I am from the same team as @reischlb . We of course know the constricting effects of time limitations on development. I also see that these proposed changes have gone through but would still like to answer to your points, maybe as something thought provoking for SAF 3.0: One of the better features of any kind of Interop format such as SAF is to make as much of the incorrect object states unrepresentable as possible with the data representation structure. Eg.: you say that without the force action column we lose the ability to automatically process which reference columns should we ignore. As for error reporting, yes, we would think it is much more useful to report to the user "This column must reference one of these kinds of objects: 2d member, region, opening". This is direct and actionable information. In any kind of error reporting relating to a specific object, which is better, if there are multiple objects with the same name leaving the user to take additional context into account in finding the problematic object, or if there is always just one object, that is easily identifiable through its name? Finally from the technical point of view, especially regarding performance, why on earth would we iterate over lists where the size is significant for lookup? Obviously we just use a hashmap of the names and objects, with approx constant lookup time, without the need to do prefilterings etc. Sorry for the ranty thoughts, but in my experience, globally unique names would be exactly the better systematic solution considering the wider implications, which is why it never even occurred to us that the names are only unique per type. |
Beta Was this translation helpful? Give feedback.
-
|
No problem at all, that's what discussions are for 👍 I've initially tried to introduce these changes as they were defined into the SDK, but it simply was not do-able at this time. But at least now we'll have a trail of some new ideas for the next version 😉 |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone,
Set the worksheet name to "StructuralSurfaceActionDistri" in SAF 1.0.9
Add new "2D member distribution" column which acts as the reference to StructuralSurfaceActionDistribution in SAF 1.0.9 Add a new enumeration, similar to the "Force action" enumeration which will specify which kind of type the StructuralSurfaceAction references |
Beta Was this translation helpful? Give feedback.
-
Dear SAF implementors,
Over the past weeks, some issues have been raised regarding some of the latest changes (version 1.0.9 and 2.0.0) on MS teams.
There haven’t been many responses, so I'm reaching out to you, hoping for more feedback before making any changes.
I can't stress this enough, that these are changes to be made to the already published SAF specification for 1.0.9 and 2.0.0.
This means that anyone who might have already implemented these versions, might need to make some changes.
• Issue 1: Multi-type reference columns have been introduced
These are columns in which references are made to multiple other types, by name.
In the past we've always had dedicated reference columns per type, so this is inconsistent with the rest of the specification.
Affected objects are:
o StructuralCurveAction - "2D member" column.
The "Force action" enumeration is updated in 2.0.0 with the values "On subregion edge" and "On opening edge", indicating that the "2D member" column will either contain the name of a StructuralSurfaceMember, StructuralSurfaceMemberRegion or StructuralSurfaceMemberOpening
Proposed change:
Add 2 new columns, "2D member region" and "2D member opening" which will act as reference columns to StructuralSurfaceMemberRegion and StructuralSurfaceMemberOpening respectively
o StructuralCurveMoment - "2D member" column.
The "Force action" enumeration is updated in 2.0.0 with the values "On subregion edge" and "On opening edge", indicating that the "2D member" column will either contain the name of a StructuralSurfaceMember, StructuralSurfaceMemberRegion or StructuralSurfaceMemberOpening
Proposed change:
Add 2 new columns, "2D member region" and "2D member opening" which will act as reference columns to StructuralSurfaceMemberRegion and StructuralSurfaceMemberOpening respectively
o StructuralEdgeConnection - "2D member" column.
In 2.0.0, a new "Boundary condition" column has been added, which would allow the "2D member" column to act as a reference column to either StructuralSurfaceMember, StructuralSurfaceMemberRegion or StructuralSurfaceMemberOpening.
Proposed change:
Add 2 new columns, "2D member region" and "2D member opening" which will act as reference columns to StructuralSurfaceMemberRegion and StructuralSurfaceMemberOpening respectively
• Issue 2: StructuralSurfaceActionDistribution name too long use as worksheet name
In 1.0.9 a new object called StructuralSurfaceActionDistribution was added, but the name StructuralSurfaceActionDistribution is too long to be used as worksheet name.
Excel has a limit of 31 characters for worksheet names, so we cannot use StructuralSurfaceActionDistribution.
Proposed change:
Set the worksheet name to "StructuralSurfaceActionDistri"
• Issue 3: Fundamental issue with reference to StructuralSurfaceActionDistribution on StructuralSurfaceAction
In 1.0.9, with the addition of StructuralSurfaceActionDistribution, an option was added to the "2D member" column on StructuralSurfaceAction object to also reference StructuralSurfaceActionDistribution.
While this issue is similar to Issue 1: Multi-type reference columns have been introduced, it has an additional flaw being that it is impossible to determine if the name in the "2D member" column refers to the name of a StructuralSurfaceMember or StructuralSurfaceActionDistribution object.
Imagine having both of these objects in your model with the same name!
Proposed change:
Add new "2D member distribution" column which acts as the reference to StructuralSurfaceActionDistribution
Optional additional change:
Add a new enumeration, similar to the "Force action" enumeration which will specify which kind of type the StructuralSurfaceAction references
Could you kindly please reply whether or not you agree with the proposed changes before the 23rd of July?
If I haven’t heard back from you by then, I’ll assume you agree with the proposed changes. Discussion is open here.
Beta Was this translation helpful? Give feedback.
All reactions