If you're reading this, we've just migrated servers! If anything looks broken please email dion@thinkmoult.com :)

Adapy - A python library for structural analysis and design

edited April 2021 in General

Hello everyone,

I just made my first python package adapy - Assembly for Design & Analysis available on Github.

In short, adapy is a python library for structural analysis and design that focus on interoperability between IFC and various Finite Element formats. It also provides a neat framework for parametric modelling in python where you not only parameterize your CAD model but also your FEM mesh recipes. It is built on top of ifcopenshell and pythonocc-core and uses gmsh for constructing FEM meshes and it has some experimental integrations with meshio for converting FEM formats otherwise not natively supported by ada.

The library is something I have built over time as a personal experiment working with FEM analysis and having to deal with interoperability with different CAD systems. Adapy has now become a central component in pretty much anything else I create related to CAD or FEM in python.

Here are a few example workflows that I use adapy for myself (the figures and more description can be found https://adapy.readthedocs.io/en/latest/).

Build IFC files using a compact syntax

from ada import Assembly, Part, Beam

a = Assembly("MyAssembly") / (Part("MyPart") / Beam("MyBeam", (0,0,0), (1,0,0), "IPE300"))
a.to_ifc("C:/temp/myifc.ifc")

creates an IFC with the following hierarchy (as shown in the figure below taken from the awesome
blender plugin blenderbim)

MyAssembly (IfSite)
    MyPart (IfcBuildingStorey)
        MyBeam (IfcBeam)

Resulting beam in Blender

Build model in code, visualize, mesh, simulate and postprocessing all in glorious python

Work Flow Example 1

Create code "attached to structural components" that checks for penetrating pipes and automatically create penetration details
Work Flow Example 2

Last but not least, this library is still undergoing significant development so expect there to be occasional bugs and breaking changes :)

Best Regards
Kristoffer

MassimoJQLbitacovirbrunopostleJesusbillCadGiruLuiscvillagrasaplanettelexvpajic

Comments

  • edited April 2021

    Cool. We should link it here: https://wiki.osarch.org/index.php?title=Free_software_libraries_for_AEC_software_development

    Edit: included in Free Software Libraries Directory.

    krandeJesusbill
  • Really, really cool! Ping @Jesusbill !

    Jesusbill
  • Very nice work @krande . I think we should do an implementation of your approach starting from an ifc structural analysis model.
    Could be one of the simple ones that exist here. There is a json file for each model with already parsed properties that could be used in a script with the adapy api to create geometry and mesh for example.
    Did you also apply running code_aster from adapy?

  • Thanks!

    @Jesusbill . We can create a binder solution for ifc structural analysis examples so that people can try them out live (like I made for adapy and calculix in the example here Binder). My plan was to add support for IFC structural elements so that the elements and nodes in the FEM objects in adapy can be exported to IFC.

    Regarding Code Aster, I found building .export and .comm files to be straight forward. Regarding the MED file itself, currently I can only create the MESH (elements and nodes) so that it can be opened in Salome Meca before making it usable in code aster. But without element and node sets, it is rather useless. So once I crack the MED file's way of storing element and node sets I think it will be easy to start adding support for the various FEM related stuff in the .comm file!

    I guess my issue with element and node sets are somewhat related to your issue raised for meshio (https://github.com/nschloe/meshio/issues/1050)? If we can crack that together I think we are in good shape for further development of Code Aster support!

  • @krande : The most direct way to reliably construct MED files is the salome API but I guess that would be a parallel path to what you are doing with gmesh.
    So probably the best way is to confront the issue with meshio. Let's work on it then!

    We can create a binder solution for ifc structural analysis examples so that people can try them out live

    That would be awesome!

    So once I crack the MED file's way of storing element and node sets I think it will be easy to start adding support for the various FEM related stuff in the .comm file!

    Yes, and the ifc2ca scripts can help in this direction. Bear only in mind that the way ifc connections are defined and also implemented in ifc2ca are a bit complex; there are coincident nodes in intersections with zero length connecting springs for elastic releases, but I am sure we can start from the simple stuff and build up from there. Can you add with gmesh a zero lengh 2-noded line element?

  • edited April 2021

    Sounds good!

    The current way of thinking in adapy is that gmsh meshes all the physical geometries. For all non-physical elements I have created classes. See the Constraint class. This is what I use to define zero-length couplings and alike using FemSet's to define master and slave nodes in Abaqus and Hinges in Sesam. The intention is to create a sufficiently general container that can represent your kinematic constraint so that you will be able to convert between FEM formats (say hinge in Code Aster or coupling in Abaqus, etc.. ).

    It is all a bit abstract (and still very much experimental and lacking proper documentation), but I can try to make time to build an example demonstrating some of it :) But first I would like to add functional support for Code Aster!

  • The current way of thinking in adapy is that gmsh meshes all the physical geometries. For all non-physical elements I have created classes.

    Ok, as a philosophy sounds correct. Then let's see in each implementation what will be needed.

    But first I would like to add functional support for Code Aster!

    Sounds great!!! Yes, totally agree, let's go for functional support for Code_Aster!! And abstract sounds perfect, since you can handle various tools.

  • edited April 2021

    @krande:

    But without element and node sets, it is rather useless. So once I crack the MED file's way of storing element and node sets I think it will be easy to start adding support for the various FEM related stuff in the .comm file!

    the issue should be fixed now, pending the response from nschloe, I think we can move ahead!!
    Edit: Spoke too soon! :) But I think you got it right!

    krande
Sign In or Register to comment.