Clarifying the Similarities and Differences Between ADA and IfcTruss

[kulasegaram]

Dear @Krande,

I hope this message finds you well. I'm excited about both the “ADA — Assembly for Design & Analysis” and “IfcTruss” libraries, as they share a common focus on IFC and structural analysis. With that in mind, I would like to propose adding a description of ADA to the documentation website of IfcTruss, under the section titled “Various comparable libraries”. In this description, I plan to outline the similarities and differences between the two projects.

To ensure accuracy in my understanding of ADA, I kindly ask for your confirmation that this library allows users to create an IfcBeam entity and load its geometry into a finite element (FE) program for structural analysis. Additionally, is there a visualization feature available within ADA?

Could you kindly confirm whether the entities from the IfcStructuralAnalysisDomain are being utilized in ADA? Furthermore, do the results from the FE analysis get saved back into the IFC file?

Lastly, does ADA support other entities apart from IfcBeam from the IfcSharedBldgElements?

In contrast, IfcTruss is a Python library that exclusively represents trusses in IFC by utilizing entities from IfcStructuralAnalysisDomain. It offers structural analysis functionality and saves the results in IFC format.

I look forward to your valuable insights on these questions. Thank you in advance for your time and assistance.

[Krande]

Hey @kulasegaram,

thank you for reaching out! Always great to see others sharing their work within FE and IFC!

I'll happily answer your questions:

To ensure accuracy in my understanding of ADA, I kindly ask for your confirmation that this library allows users to create an IfcBeam entity and load its geometry into a finite element (FE) program for structural analysis.

Yes, IfcBeam elements are supported for importing and consequently meshing to various line, shell and solid element formulations using ADA. It also supports importing IfcPlate and several of the IFC geometry definitions. It also supports multiple types of boolean operations on the imported geometries.

Additionally, is there a visualization feature available within ADA?

Yes, ADA supports exporting FE results to GLB and VTU (so you can view your results in Paraview etc.) and comes with some basic visualization features. I have recently added a React threejs renderer for visualizations which supports FE results. It also supports visualization using pygfx (a webgpu based renderer). Note that the visualization capabilities are highly experimental and still very much work in progress,

Could you kindly confirm whether the entities from the IfcStructuralAnalysisDomain are being utilized in ADA? Furthermore, do the results from the FE analysis get saved back into the IFC file?

The short and simple answer is no. The core FE entities in ADA are based on generalized concepts I've had to re-use over the years to work across multiple different FE software. Hopefully the core FE concepts I've ended up with aren't that far from what exists in IfcStructuralAnalysisDomain. Today, there is only limited support for writing line and shell elements in https://github.com/Krande/adapy/blob/main/src/ada/fem/formats/ifc/writer.py. IFC FE results are consequently not supported in ADA.

Lastly, does ADA support other entities apart from IfcBeam from the IfcSharedBldgElements?

IfcPlate and IfcWall also have specific ADA entities. But you are free to create more of the IfcSharedBldgElements entities by simply setting the desired IFC class on either the generalized geometry container (see the Shape class) or a spatial hierarchy element (see Part class in the api module). The core geometry definitions within ADA are all modelled 1:1 (or as close to as possible) after the IFC geometry definitions. So it kind of mimics the geomtry-class relationship of IfcProduct (which is a superclass of all the IfcSharedBldgElements) and its geometry Representation.

For the geometry definitions you can take a look here: solids, surfaces and curves.

[kulasegaram]

Dear @Krande,

Thank you for your detailed response. I appreciate the information you have provided regarding the capabilities of the ADA library.

To clarify my understanding, you are implementing support for creating line, shell, and solid elements based on the entity types within IfcGeometricModelResource. These entity types are used as Representation in IfcProduct and its subclasses. The above line, shell, and solid elements are utilized for further analysis in FE programs such as Calculix and Code Aster. The maturity of this implementation is most advanced for solid elements.

However, I'm curious to know how loads and boundary conditions (e.g., IfcStructuralPointAction and IfcStructuralPointConnection.AppliedCondition from IfcStructuralAnalysisDomain) are defined within your library?

Additionally, the example in the ADA README demonstrates the analysis of a single IfcBeam. I'm interested in learning whether frames or trusses composed of numerous instances of IfcBeam and IfcColumn can be converted and imported into FE programs using ADA.

Thank you for your time and assistance in addressing these questions.

[Krande]

To clarify my understanding, you are implementing support for creating line, shell, and solid elements based on the entity types within IfcGeometricModelResource. These entity types are used as Representation in IfcProduct and its subclasses. The above line, shell, and solid elements are utilized for further analysis in FE programs such as Calculix and Code Aster.

Correct. ADA relies on GMSH as the meshing tool. So the IfcGeometricModelResource geometries are internally converted to OpenCascade C++ objects and passed in-memory to GMSH. In ADA you can also write simple python functions that describe custom geometry partitioning for whenever you require complex meshing of any type of geometry. The plan is to add some examples in the documentation once the ADA api is a bit more stable.

The maturity of this implementation is most advanced for solid elements.

Well, If you are referring to the maturity of the element implementation in the FE solvers themselves then you are correct regarding Calculix (it's a solid element solver, which utilizes on the fly conversion from line and shell definitions to solid elements). However, Code Aster has a very mature line and shell element library (in addition to a wide range of mature solid elements). If you are referring to the implementation in ADA, then I would say that line and elements is what I've used it for mostly. So support for line and shell elements are likely more mature than solid elements.

However, I'm curious to know how loads and boundary conditions (e.g., IfcStructuralPointAction and IfcStructuralPointConnection.AppliedCondition from IfcStructuralAnalysisDomain) are defined within your library?

Point, pressure and various acceleration fields are supported. See https://github.com/Krande/adapy/blob/main/src/ada/fem/loads.py. It's usually something I develop on a need to have basis. There is a lot of potential for improvement in the current state of load definitions. So I plan on improving it in the coming months.

Additionally, the example in the ADA README demonstrates the analysis of a single IfcBeam. I'm interested in learning whether frames or trusses composed of numerous instances of IfcBeam and IfcColumn can be converted and imported into FE programs using ADA.

Yes, numerous instances are definitively supported. There is no limit on how many beams, plates you include in your model. I have used ADA to create FE models with millions of line and shell elements.

I should also mention that I rarely import a pre-existing IFC and convert it to a FE mesh. And that is primarily due to the fact that most IFC files I've encountered are poorly suited for FE analysis. Instead I've ended up creating both IFC and FE models simultaneously using ADA by leveraging a combination of parametric and procedural modelling.

[kulasegaram]

Thank you very much for your comprehensive answer. I will reach out to you if I have any further questions.