Integration of Code_Aster in an IFC-driven workflow for structural analysis

edited October 2020 in General

This thread is about the integration of Code_Aster, an open-source finite element solver developed by Electricite' de France (EDF) (, in a structural analysis workflow with models extracted directly from IFC data.

A successful proof of concept has been completed in BlenderBIM ( and in the ifc2ca repository ( for a simple cantilever beam under its own weight.



  • New example added in the repository of a portal frame (ifc file taken from buildingsmart site and modifications in the json schema and the ifc exporter:

    • Added portal example
    • Changed section to profile and added I profile
    • Modified material and profile schema with mechanical and common properties
    • Added geometry identification for point connection from representation
    • Added connections along with supports based on the number of elements a connection is applied to
    • Applied conditions with elastic stiffness values is still not implemented. Only True/False values are accepted.

  • @Moult : I will be working on the load/loadcase definitions and on the surface structural members from this and some other ifc structural files I have just found.

    Just to make sure I got it right, we cannot import an ifc file and visualize the structural members yet in BlenderBIM right?

    The latest release of BlenderBIM contained anything related to the structural part in the UI?

  • Correct, BlenderBIM has a few options in the UI which affects export, but not import currently.

    I've been very busy with a few other things which have held up any work on BlenderBIM :) But I look forward to resuming work on this! It's on the to-do list!

  • Sounds great 👍️

  • Latest update in dev ... getting into structural surface members

    example taken from:

  • Update on the ifc2ca project:

    • Added beam and building examples
    • Added support for I sections and calculation of section properties if not provided (assuming fillet radius is zero)
    • Added support for surface members (shells)
    • Refactored the script
    • Added support for rigid links
    • Added advanced meshing script to correctly simulate connections and independent meshing of structural elements (no common nodes)

    Some screenshots of the building_01 example

  • I am also developing a web viewer that will host all the examples and will convert the structural ifc files into json, as per the script.

    I hope this can be a good way for people to try and convert their files without necessarily setting up everything needed for the scripts to work.

    Of course, the second part related to the actual code_aster analysis part still has to be done manually ... for now.

    The first basic version is ready, including the backend service. Struggling a bit with the SSL certification but hopefully it will be taken care of soon.

  • Great work @Jesusbill ! I was checking very quickly the thread on github and found that comment about Salome/CodeAster licencing:

    I think that concerns the Qt framework right ?

    I Don't no exactly what are Qt licences issues here, but I imagine that the library in itself is not affected by that right ?

  • Thanks! Yes it has to do with the license of pyQt for a commercial version of Salome-Meca.

    But it has no implication for this project.

  • Very cool web viewer! Is the source available?

    If you need help with hosting (or even a publicly accessible demo!) let me know - I have a server and would be happy to provide free hosting, and also happy to help with SSL issues.

  • Thanks Dion. As of now the source is not public.

    We (as Aether Engineering) have not decided yet how we want to handle this aspect, but it is very possible that we will make it OS in the near future. It is just something we were not intending to develop, to be honest, when we started the IFC2CA project and we want to have some clear ideas of the scope and be sure we can "support" it, which is the case for the IFC2CA project, should we decide to release it as OSS.

    That said, if you want I can invite you in the repository, no problem with that. Do you have anything specific in mind?

    And thanks for the availability to provide hosting and the rest, I appreciate it. Thankfully, today all issues have been resolved, the back-end is up and running and very soon it'll be online for viewing and file conversion.

  • @Jesusbill I like IFC2CA, however, I think you have enough expertise and knowledge to stat a promising WebGL viewer based on 3D tiles and other technologies

    Some solutions like XeoKit or X3DOM-based are preliminary in my eyes, and Autodesk Forge ( is somewhat good but ...

  • 3D tiles look nice ...

    But maybe what you propose is out of my league a bit, i mean I am mostly about Engineering, I think you refer to something more general

  • 3D Tiles mainly is a technique (LOD manager) to handle big and complex scene with high performance which is a normal technique in VFX industry too

    You can use 3D Tiles among others like ThreeJS

    However, maybe in the PLM industry you find better ideas and solution related to engineering purposes

  • The Viewer is up 👍️ (

    @Moult I did not push the in the IfcOpenShell repo for quite some time, I will be doing that later today, I guess we are still on the same page on maintaining this file in the IfcOpenShell repo, right?

  • @Jesusbill - very, very cool! I'll share it with my colleagues! More than happy for you to maintain it in the IfcOpenShell repo - it might grow into its own thing, i.e. in src/ifc2ca/* rather than inside BlenderBIM. That way, we can then connect it to FreeCAD (ping @yorik , @bernd )! I will ask permission from Thomas Krijnen to see if he's cool with it, but I don't see an issue!

  • @Moult I don't remember some months ago when you invited me to join FreeCAD movement was talking about issues in the industry

    It seems that you guys in FreeCAD and IfcOpenShell follow the same mindset some companies like Autodesk follow, and personally I won't be part of and won't support after this

    Good luck

  • Sounds good @Moult, I think it makes sense to have a separate repository for IFC2CA as there is now, where the development will take place and where other files can be hosted (examples, result files from code_aster, other scripts) and push in the IfcOpenShell repo the essential ones at regular time intervals. Regarding FreeCAD I do not have any experience and I don't think I will personally have the time to get involved, but let's see. From a past discussion with @bernd I know he is in great favor of using solid elements, which are not however included in the ifc schema, plus making the scripts work for solids will be more tricky and time-consuming, so I do have some reservations, but again .. let's see.

  • @Moult I have one question: How were the json files in the schema folder ( produced? Did you use some scripts or manually?

    I'm asking because they contain useful information for developing and exploring ifc classes, thanks

  • @Moult I was looking at BIMTester, it would be nice to use it in order to check if the structural elements have the required properties, etc.

    Is there any documentation or perhaps an example to understand how it works?

  • @Jesusbill - the schema files are produced with - fun fact: I originally wrote the script to implement dynamically created attributes in FreeCAD - and then re-used, and improved the script in Blender. I daresay this is another one of the things that FreeCAD and the BlenderBIM Add-on can share :)

    As for BIMTester, this wiki page should give an overview. However, I am actually in the process of heavily simplifying this so that anybody can use with absolutely minimal setup - i.e. no need to set up a features directory, no need to follow careful Gherkin syntax if not required ...

    Perhaps this weekend during the call I can give a demo :)

  • I checked .py files and it's interesting, but it seems that it was generated manually. What if you think about the whole process automatically? IFC2JSON?

    BIMTester is another interesting project, which has its own pros and cons:

    1. If we see BIMTester as a validator to insure that always the file imported and even exported is correct then I'd like it, and shared some ideas with Dion, but didn't work on them, like if file has errors, BIMTester opens a Error log window to correct them manually on the fly
    2. Is we see BIMTester as something like IDM Toolkit (part of IfcXtreme would act as IfcToolkit), I think it'd be weak, because working with would be agony, to define rules (requirements, usages, ...) and process them in IDM/MVD way (However, Dion don't think so, so I've waited to see BIMTester could be an alternative for IDM Toolkit or not?)
  • @Moult : thanks for the info, I will study , could be very useful for development. BIMTester sounds also very interesting, yeah it could deserve a very small spot during the call this weekend, which I am looking forward to.

    @ReD_CoDE : Yes the python script is manually created but it "spits" the json files that show the schema; this an be useful for someone who wants to develop using IfcOpenShell. But it is not an IFC2JSON translator of an IFC file.

    I see BIMTester as a validation tool, it can have various implementations depending on the context. Modifying ifc files to make them "compatible" with ones requirements, as prescribed in ones implementation of BIMTester, would be another extra component in the process. Probably it would need a User Interface as well.

  • Very cool web viewer! Is the source available?

    I have just made the website repository of aether engineering, and thus the structural bim viewer, public.

    I know it would have been better to release the viewer as a stand-alone app but it would require extra effort, time and dedication which at this moment I do not have. I do not plan to fully support it, as of the current circumstances, nor will I be promoting it as an open-source project but I did want to share it with the community here. I plan to keep developing it to support the ifc2ca project as much as I can, but with limited resources and while our "heavy-duty" developer will be fully busy with some other projects.

    That is the status for now, of course I don't know what tomorrow may bring ... In any case, if someone wants to contribute on it, let me know and we can discuss.

  • @Moult I want to improve some of the work done in ifc2ca and set some more stable base on some aspects, especially the geometry and orientation of structural members and structural connections. As of now, I have not really considered at all object placements and stuff, treating all coordinates as global and orientations as global or default as well, but I feel I have to cope with this well, above all for defining then correctly the implementation in Code_Aster. I will be taking a more offensive approach (I am not good in asking questions but I have to improve) providing my interpretation here and asking if that is correct, hopefully this can be a more efficient way to go forward.

    Of course anybody that will be able to verify my interpretation or guide me in the correct direction is welcomed to help.

    So, let's start with the geometry coordinates of the objects, members and connections.

    My understanding is that I have to consider two transformations (where each transformation can have translation and rotation in 3D) to get the global coordinates from the coordinates I read from the representations:

    1. The SharedPlacement property of IfcStructuralAnalysisModel (sth similar to WorldCoordinateSystem of IfcGeometricRepresentationContext)
    2. The ObjectPlacement property of IfcStructuralItem or IfcStructuralConnection

    Would that be correct in your opinion? Or there can be other transformations possibly to consider?

    For the SharedPlacement the documentation states "Per informal proposition, this attribute is not optional as soon as at least one IfcStructuralItem is grouped into the instance of IfcStructuralAnalysisModel."

    My understanding is that it is a mandatory property. What's your take? If not provided should I relate to the WorldCoordinateSystem or just ignore it overall?

  • Thinking more on this I guess the placement of the model itself is not important for the structural analysis. And if all members/connections have the same object placement I will not have to account for any of that (?)

  • Correct, the placement of model is not important for structural analysis so long as all items are relative to one another. This makes life easy :)

    I would ignore the WorldCoordinateSystem for now, since it may only apply if you need to convert local coordinates to a global CRS. This is definitely never required in a structural analysis workflow.

    From my reading of the documentation, it seems like the object placement of all structural items must be the same, and then once you place it in an analysis model, that must also have a SharedPlacement property that has also, the same object placement. Therefore I do not interpret the SharedPlacement as an additional transformation to be applied - it seems like superfluous metadata.

    If one or more structural item is grouped into an Analysis Model, the attribute SharedPlacement shall be provided with a value.

    The object placement of all structural items which are grouped into the same instance of Analysis Model shall refer to the same instance of as .SharedPlacement.

    So I guess if I had to parse it, I'd just read each structural item's object placement and call it a day without applying any more transformations.

    I hope I've understood it right.

  • Ok, I think it makes sense, I will be considering only one possible transformation related to the object placement, thanks

  • Finally, some updates on the Ifc-To-Code_Aster project. I prepared a brief deck, attached here as images, to show the current state of development through a simple portal example. Glad to say that internal releases of beam elements with respect to any arbitrary orientation is now implemented and it looks great!
    Point supports can be also defined with any orientation although this case is not covered in these examples.
    Next targets down the road? Implement elastic internal connections and elastic supports for beam elements and point connections, respectively.

  • edited May 2020

    That's awesome! In FreeCAD, structural elements like beams and columns already contain a linear representation. So far, this isn't exported to IFC, though. I'd be glad to work through that at some point, so we can export files that are ready to process in CodeAster..
    If someone happens to have a very simple IFC file with, say a portal like the image above, I'd be really interested in having a look at it

Sign In or Register to comment.