Ifcopenshell: Develop IFC2CA as part of IfcOpenShell?

[Moult]

@aothms - a while ago, @Jesusbill and I started work on a IFC<-->Code_Aster (structural simulation software) script. There are are two parts to this: the first part extracts IFC into a JSON data file, and then the second part which parses the JSON into various input files for the structural simulation.

Currently the first part lives in both this repo as well as his own repo, and the second lives purely in his repo: https://github.com/Jesusbill/ifc2ca

Would it make sense for @Jesusbill to be given write access to the IfcOpenShell repo and continue developing this utility under the IfcOpenShell umbrella suite of tools?

[aothms]

@Moult @Jesusbill thanks for your efforts on this. I think this is ground breaking work and I think people are following this closely.

I've added @Jesusbill as a developer with write access. You're more than welcome to continue in this repo. If you prefer something separate that's also fine.

What are the current remaining open challenges? Is there something I can help with? I'm not a structural engineer of course, but if there are tasks related to geometry (I don't know, connectivity detection, simplification of solids to surfaces or curves, ...) let me know.

Edit: looking at some of the code, open cascade has quite some functionality to calculate some of these properties on arbitrary faces, such as moments of inertia https://www.opencascade.com/doc/occt-7.0.0/refman/html/class_g_prop___g_props.html#af350927c79640480f0280958ab5bdfb3

[Jesusbill]

Wow thanks a lot @aothms for this possibility and thank you @Moult for starting this collaboration in the first place.

There are many challenges ahead. Currently we are exploring the structural-analysis-domain classes in the IFC schema and the first goal in my view would be to complete this part in terms of geometry and properties representation, connectivity, loads etc. and the correct implementations for the scripts needed for Code_Aster. I feel we are mid-way there although there is need to cover all cases of geometry representation in IFC, where I have limited experience but I try hard to catch-up.

Then, passing in the consideration of the 3D geometry and how we can derive the structural/analytical model (solids to surface or curves as you say) would be of the utmost value for the community and for this project. So any help on these aspects when the time comes would be greatly appreciated.

Thanks for the tip regarding opencascade some of these could be useful to have. Are they accessible with the python API or you need C++ to access them, cause C++ would be quite out of my skills.

Regarding the project location I would opt for a dedicated folder ifc2ca as there are at least three script files and then I am also building a library of examples. Not sure what is the best way, perhaps these examples that serve also as Code_Aster examples may not have the best place in the IfcOpenShell repo (with all the result files for example) but on the other hand they serve as proof of the implemented workflow. I have a feeling that having also a separate repo for some data could be useful but I am not sure. What do you think guys? Should I just transfer everything and go from there or it could make sense prototype and develop in the separate repo and transfer only the necessary files with "clean" and "few" commits in IfcOpenShell?

[lcpt]

I have some experience with C++, I can help if needed.

[Moult]

@Jesusbill I think it would be great for you to do work in src/ifc2ca/* for all the code :)

I also think that there should be another repo created to hold test / demo IFC files, like IfcOpenShell/test-cases. This can store all of the regression files that @johanrd is using, as well as test IFC files that the BlenderBIM Add-on and FreeCAD community use to check regressions... and it can store structural analysis models too.

The IfcOpenShell website _really_ needs to be updated with all these new tricks :)

[Jesusbill]

Ok @Moult I like your proposal, it would indeed make sense to have the test-cases in a separate repo.

[aothms]

Thanks for the tip regarding opencascade some of these could be useful to have. Are they accessible with the python API or you need C++ to access them, cause C++ would be quite out of my skills.

Yes, the large majority of functionality from Open Cascade is available through pythonOCC, which I think is bundled by @Moult in BlenderBIM.

I have some experience with C++, I can help if needed.

@lcpt perhaps most related this, is see if we can make the ifcopenshell.geom.iterator (a wrapper around a C++ class) more interactive. Below are some (from @Moult or me):

• request both pythonOCC shapes as well as Blender meshes (now there is one type returned based on settings)
• ability to selectively process elements (now this is governed only by settings supplied during initialization)
• more granular access to representation items (for example to map IfcExtrudedAreaSolid to a Blender extrusion).
• convenient access to IfcPropertySet values from the iterator
• pre-calculate properties in a uniform fashion (like the profile properties such as inertia, and length / area / volume measures; because explicit properties in IFC can be unreliable and missing) (there is something now in the IfcGeomServer, but rather limited and not exposed to Python https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.6.0/src/ifcgeomserver/IfcGeomServer.cpp#L478)

The IfcOpenShell website really needs to be updated with all these new tricks :)

Yes, you're right. I think I'll be able to move it to a public repo and accept pull requests soon.

test-cases in a separate repo

I think (but I might be wrong) that it's best to keep these out of the repo for regression testing and create a separate repo for this with more specific documentation, output results (maybe as ipython notebooks that render nicely in github, not sure..)

[lcpt]

@aothms Are you talking about the iterator implemented here?

[aothms]

@lcpt yes that's the one. Unfortunately it's one of the messiest files in the repository. A cleaner entrty point is perhaps the BRepElement class https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.6.0/src/ifcgeom/IfcGeomElement.h#L176 which is what the iterator constructs based on the processed representations. Triangle meshes (TriangulationElement) get derived from that. You have access to the data from the file (such as explicit property sets) by means of IfcUtil::IfcBaseEntity* product.

[Jesusbill]

Based on what has been discussed we can proceed with:

• a dedicated folder in src/ifc2ca/* for all development files
• a dedicated repository in IfcOpenShell for ifc2ca examples/test-cases organized as folders.
• a possible inclusion of the structural ifc example/test-case files in the repo used for regression testing (?)

I will be proceeding shortly with the first step.

I think (but I might be wrong) that it's best to keep these out of the repo for regression testing and create a separate repo for this with more specific documentation, output results (maybe as ipython notebooks that render nicely in github, not sure..)

Just keep in mind @aothms that currently Code_Aster is not a python module that you can directly import in a python script (bit of a long story) so the analysis execution has to be done manually. The output files contain, typically, two binary files with the mesh (.med) and results on the mesh (.rmed) and a .txt file with results, so ipython notebooks may not be an option.
But, the development team has been working already on this and I know that there should be sooner or later the testing version of the code_aster python module. That would also break the barrier of the use for Windows since as of now the official certified version is built only for Linux. Anyway, perhaps I went a bit off topic but I wanted to give the context

[lcpt]

@lcpt yes that's the one. Unfortunately it's one of the messiest files in the repository. A cleaner entrty point is perhaps the BRepElement class https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.6.0/src/ifcgeom/IfcGeomElement.h#L176 which is what the iterator constructs based on the processed representations. Triangle meshes (TriangulationElement) get derived from that. You have access to the data from the file (such as explicit property sets) by means of IfcUtil::IfcBaseEntity* product.

Ok, I'll take a look and try to understand how it works.

[Jesusbill]

@aothms I am trying to push the first commit directly to the v0.6.0 branch but I get a permission denied error

$ git push origin v0.6.0
ERROR: Permission to IfcOpenShell/IfcOpenShell.git denied to Jesusbill.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I used SSH to clone the repo since it is more convenient and secure but maybe this has something to do with it?
Will try now with HTTPS as well and update the status here

[Jesusbill]

Same error also with HTTPS

$ git push origin v0.6.0
Username for 'https://github.com': Jesusbill
Password for 'https://[email protected]': 
remote: Permission to IfcOpenShell/IfcOpenShell.git denied to Jesusbill.
fatal: unable to access 'https://github.com/IfcOpenShell/IfcOpenShell.git/': The requested URL returned error: 403

[aothms]

@Jesusbill it seems you haven't accepted the invitation yet to the Developers team. In github you need to click the accept button. Some other platforms process the invitation immediately.

[Jesusbill]

Ooops ... you were right, thanks and sorry for bothering for no reason.

[Jesusbill]

I think (but I might be wrong) that it's best to keep these out of the repo for regression testing and create a separate repo for this with more specific documentation, output results (maybe as ipython notebooks that render nicely in github, not sure..)

Do you see this separate repo within the IfcOpenShell organization? Can I create one called something like ifc2ca-test-cases?

[Jesusbill]

@Moult @aothms guys I am getting a bit desperate with the ifc2ca work. I have had major difficulties to continue developing the project; basically after 2-3 weeks of attempts I am still at the same point ...

The main difficulty is the lack of ifc files with structural analysis models. I found a couple of them that either were not complete or with the IFC3 schema and I ended up writing a bunch of useless code that was not in the right direction (too many if statements to consider incomplete data that ended up breaking also the existing examples). My colleague also downloaded a trial version of sofistik, a structural analysis software, with the idea to construct some models there and export to structural ifc, but also this has been a disappointment. Too many data missing, a bit of a mess in the representations, it just looks like this export to structural ifc is just not something well done in this software but I fear in general, given that it is not a common approach among the structural engineering software. I have also contacted two other friends and also one of the users of the BS forum; supposingly they should be helping but until today I have not received anything yet.

Perhaps I can try to use some trial versions of other software but at this point I would hesitate to develop the code if I am not sure that the ifc files are correctly done.

I think the first important objective is to be able to parse reliably the geometry of the structural elements and the connections between them. Point connections are arguably considered based on a couple of the existing examples (although there are two aspects in this regard that do not make sense in my opinion and I will make two posts on the BS forum about them) but I am still missing curve and surface connections. I am also missing any consideration of the local-axes/orientation of connections as this plays a significant role in applying the correct conditions. In a second moment, loads, load cases and load case combinations I think that would then be easier to deal with, if the part of the geometry, the connections and their properties are correctly and efficiently dealt with.

I am asking if you can provide some advice, based on your experience, on what could be the best approach to continue. I am fully committed to working on this with all my available forces but there is a need to take an approach that will bring some fruits on the table and will keep the moral and the motivation high. Perhaps my inexperience in ifc is not helping much, either, given that I started working on this topic only during the last two months...

In any case I am not giving up (we will try to test other commercial software if possible) but any helpful contribution in this regard would be much appreciated. Maybe an approach could be to develop our own correct ifc structural files? If that could be a solution, what could be a plan of action and how I can contribute most to it?

Thank you in advance and sorry for the long read. If you think it is more appropriate I will open another issue with this subject.

[Moult]

@Jesusbill The only thing I can help with is to develop more structural support into the BlenderBIM Add-on so that Blender can author structural models. Unfortunately, I'm a bit tied up with a few others things on the to-do list, but once I return to it, hopefully I can help that way.

[Jesusbill]

I appreciate your support Dion, it will be great to have BlenderBIM for structural models!

I think I also have to change strategy and try to author structural ifc files with ifcopenshell ... and ideally create a ca2ifc converter of the json model; not sure how difficult it can be though

[aothms]

Yes this is tough. For anything besides the typical coordination workflows that work well now in IFC, you're always running into chicken and egg kind of problems.

I indeed see two options for this:

• Dry to derive the information from the typical architecural/structural exchanges with geometric reverse engineering. Not being a structural engineer I can't judge how feasible this is. But it doesn't have to be a fully automated solution. If you can just derive the geometry of the schemas and what not from the architectural model and refine and fill in the missing bits in Blender BIM perhaps you have a solution that saves you 80% of the time.

• And indeed, maybe that's not so different from the other option to focus more on authoring. One thing that this enables is for example interoperability between Blender and FreeCAD by using the IFC structural analysis model. This is very powerful and other applications can later connect to that. In a way this reminds of the work Jon Mirtschin (@jmirtsch) has been doing wrt to exchange of parametric information and constraints in IFC. In the end I think nobody besides him support these kind of concepts (IfcMetric, ...) but with his own plug-ins for various tools (Revit, Rhino, ...) he has been able to exchange detailed parametric information from one tool to the other, reusing the support these tools (and his own software) have for the geometric constructs in IFC. His perspective would surely be interesting, he's also a structural engineer.

[lcpt]

Hi.

I'm a bit overwhelmed now, too many things to solve at work, but I'll be more than happy to help in a near future.

[Jesusbill]

Thanks for the insights Thomas, I will work to get more acquainted with authoring scripts and I will keep looking for other models for reverse engineering.

[Jesusbill]

Hi all, it looks like everything has been going better with respect to last week. I experimented on authoring and I think I can handle it so as to create some test files, but most importantly I started understanding much better the schema, the associations, the resources on the website, etc. It is kind of strange, as if all this struggle in the past weeks was doing me "good", like I was learning in the sub-conscious part (kind of breathe-in breath-out Miyagi training ... :)). I also had a good answer in one question on the forum, so all in all I am positive I can continue working on this project with the elements I have. I am also happy to see that the ifc schema is very general regarding the connections between elements and I think now the challenge is on the code_aster implementation. Let's see how it goes but if we manage to have a general implementation of the connections I think it will be really a break-through for Code_Aster users.

Last but not least, regarding the examples, @aothms can you make another repository in ifcopenshell? Or how can we handle this aspect? On my part some examples can serve as testing examples but I would also like to have more examples not necessarily with a testing value but more with an illustration value. For example, I managed to have an example with a tall building these days; always from the same software vendor so it has known problems, but it is a good illustrative case. But then again such a repo with "examples" could live outside ifcopenshell. Not sure what is the best way. Perhaps have the "testing" examples in an ifcopenshell repo and keep the other somewhere else?

[aothms]

@Jesusbill great to hear. I have created https://github.com/IfcOpenShell/analysis-models and you're an admin. Have a look at Large File Storage https://git-lfs.github.com/ if you intend to store larger (like, several MBs and up) models. LFS is not perfect, I think there is some lockin.

When there are some example models, I'll see how they perform in the basic ifcopenshell.geom.app. Looking forward.

[Moult]

Btw I found that it is possible to migrate Git LFS from one host to another to prevent lock-in - but it has to be done client side (e.g. not like vanilla Git where you can copy over the bare repo server to server - in contrast, you need to clone all, then push to a new LFS host)

[Jesusbill]

Great @aothms! Off to work!