search

buildingSMART / IFC4.3.x-development

Repository to collect updates to the IFC4.3 Specification
Other
158 stars 81 forks source link

Structural Analysis Model #715

Open GioStamoulos opened 10 months ago

GioStamoulos commented 10 months ago

In the validation service, the types of topological representation (https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcTopologyRepresentation.htm) must be added to the valid_representation_type csv file, because for structural members (that are related to topological representations), the service gives rule errors (https://github.com/buildingSMART/ifc-gherkin-rules/blob/47b6a14/features/GEM004_Constraints-on-representation-identifiers.feature).

Vertex,topological vertex representation (with or without assigned geometry) Edge, topological edge representation (with or without assigned geometry) Path,topological path representation (with or without assigned geometry) Face,topological face representation (with or without assigned geometry) Shell, topological shell representation (with or without assigned geometry)

Also, is there any way to describe slave nodes? This information is essential in structural analysis.

@Jesusbill

aothms commented 10 months ago

Thanks, I filed an issue here as well: https://github.com/buildingSMART/ifc-gherkin-rules/issues/104

CC @jmirtsch

So (some of) the questions are:

GioStamoulos commented 10 months ago
MatthiasWeise commented 9 months ago
  • I think must contain boundary relations between connection points (slave points), if this could be possible to be described with ifc entities.

I am not fully sure what you mean here, but boundary conditions between all types of structural members can be described via subtypes of IfcBoundaryCondition (https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcBoundaryCondition.htm). Is that maybe what you are looking for?

GioStamoulos commented 9 months ago

@MatthiasWeise with IfcBoundaryCondition you can only set the stiffness (or whether it's free or not) of each DOF, but you can't relate the DOF of one node to another. This relationship is another factor that affects the shear force or moment associated with this DOF. Thus, this information cannot be imported using this Ifc entity.

MatthiasWeise commented 9 months ago

So you need to define a mechanical connection between two nodes that are at the same location?

My understanding for defining DOF between members and surrounding: The model differentiates between connection and members, where a node can be a connection only. I.e. there is a PointConnection but no PointMember, which is different to Curve and Surface. The curve member can for instance be connected to a point connection with 6 DOF. The point connection, if connected to a rigid surrounding, can define another 6 DOF. Any additional curve member that is connected to the same point connection can define their own 6 DOF. However, this model does not allow to define DOF between point connections. If something like this is needed you may use a very short or may even a zero length curve member between two point connections .

GioStamoulos commented 9 months ago

@MatthiasWeise I don't think that with this way this structural analysis information could be describe. I want to relate for example in the following case Dx and Dz degrees of freedom (only these) of N9 with the corresponding DOF of N5, N6, N7 & N8. image

MatthiasWeise commented 9 months ago

Is this a slab to be represented by a structural surface member and N9 is a node within this surface member? What is the meaning of N9, is it a supporting node?

GioStamoulos commented 9 months ago

N9 is a master node that is not related to structural surfaces or structural curves, and N5, N6, N7, and N8 are its slave nodes. I could describe the master node as a zero-length curvemember, but the master-slave node could not be described through the current boundary condition options. In my opinion, the option related or not must be added in some way to each DOF. image image

MatthiasWeise commented 9 months ago

Might be an extension to current definition then. If it can be handled by addtional information in IfcBoundaryNodeCondition it might be a new subtype in future IFC releases (similar to IfcBoundaryNodeConditionWarping). If I remember well, the use case with master-slave nodes has not been a topic in the discussion about the structural analysis model for IFC (also knowing that not all use cases can be covered).

jmirtsch commented 9 months ago

Constraint relationships like this are not explicitly supported in IFC at this point in time. If it's a one to one relationship, in my developments I have supported a user defined object type on a curve member and custom properties to nominate DOF. I'm not sure if there was any consideration of constraints in previous structural analysis exchange discussions. It seems it would need some implementer agreement on how best to convey them within the current schema (such as the approach above, perhaps also grouping them to nominate a many to one relationship).

MatthiasWeise commented 9 months ago

If it's a one to one relationship, in my developments I have supported a user defined object type on a curve member and custom properties to nominate DOF. I'm not sure if there was any consideration of constraints in previous structural analysis exchange discussions.

I am not sure if I understand the requirement with DOF for curve member. Have you looked into IfcCurveConnection and IfcBoundaryEdgeCondition?

It seems it would need some implementer agreement on how best to convey them within the current schema (such as the approach above, perhaps also grouping them to nominate a many to one relationship).

Before discussion extensions or special implementer agreements, let's recap the scope of the structural analysis domain. The focus of that extension was on data exchange between structural engineers to be able to coordinate main decisions regarding structural idealisation. For instance, finite element analysis and meshes have been left out on purpose. Please correct me if I am wrong, but my feeling is that we discuss special cases of idealisation.

jmirtsch commented 9 months ago

I don't recall this explanation of the scope of structural analysis exchange. It makes sense, but the official documentation contradicts it noting the word "all".

https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/IfcStructuralAnalysisModel.htm

The IfcStructuralAnalysisModel is used to assemble all information needed to represent a structural analysis model.

IfcCurveConnection and IfcBoundaryEdgeCondition represent different idealization. This constraint is point to point (often one to many). It is quite common in structural analysis models, particularly for high rise buildings to perform lateral assessments. Modern computing power perhaps has diminished the frequency of use. But it is a requirement that should be considered in any future work if it is judged to be out of scope at present.

MatthiasWeise commented 9 months ago

Regarding the scope of the Structural Analysis Domain: Better use this definition: https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/ifcstructuralanalysisdomain/content.html

Regarding point to point connection: If those points are at different locations I would expect to connect them via a structural member (curve or surface) with further structural properties such as moment of inertia etc.
The example given by @GioStamoulos looks to me like a plate with 5 points. If N9 is with boundary conditions, you need to model it. If it is a point within a plate and without boundary condition, you do not need to model it as there is no additional information (?). However, I am not sure about the master/slave nodes. I could also think about an idealisation as 5 points with 4 surface members.

GioStamoulos commented 9 months ago

@MatthiasWeise @jmirtsch In my case study, the footing (foundation) of the building is related to one node. Based on the ifc concept, nodes are point connections; therefore, a foundation could not be defined as just a point connection. My solution is for the foundation to be described as a zero-length curve member (with no representation) that is related to one node. Is it the correct solution, or is there another way based on the ifc schema (or also an ifc extension required)?

MatthiasWeise commented 9 months ago

It should be fine to represent the foundation as a point connection only. It is on purpose that there is no point member, because a zero dimensional structural element does not have structural properties. Please keep in mind that all structural properties of members and connections are just idealizations. If you want to analyse special structural behaviour of the foundation you may need a different structural idealization. Maybe a two dimensional idealization would be better then? Please also note that you can have as many structural idealization as needed, i.e. you are not limited to have one structural analysis model for your building or support condition.

Besides the idealization of the building in one (or maybe more) structural analysis models you may also want to keep the relationship between the structural items and the physical building elements. In my view that is the most powerful and interesting feature in IFC. This can be done by using the IfcRelAssignsToProduct relationship. In that way you can keep your design intent to idealize the foundation by a structural connection (or whatever idealization you have). Does that makes sense to you?

GioStamoulos commented 9 months ago

@MatthiasWeise Thanks for your information, you help me a lot. Furthermore, I wonder if there is a way to describe a solid element (used in the structural analysis model) using Ifc structural entities.

@jmirtsch

MatthiasWeise commented 9 months ago

Furthermore, I wonder if there is a way to describe a solid element (used in the structural analysis model) using Ifc structural entities.

No, that is currently out of scope of the structural analysis domain. If needed I could think about a new subtype of IfcStructrualMember (e.g. IfcStructuralSolidMember). Such extension should work with the topological representation of structural members as used in the current solution.