A friend of mine received a 800 Mo IFC and of course authoring tools struggle or fail to import it. Is there currently a safe way to split an IFC ?
If not it could be a good feature to develop. Maybe an ifcopenshell util.
Splitting by container (building, building storey etc…) should be doable.
I will split any import over 100 mB
Using BricsCAD , use bim explorer, sort on either story of spaces
Export IFC
[commercial advertising for myself wll follow now :P]
@magicalcloud_75 said:
Using BricsCAD , use bim explorer, sort on either story of spaces
Export IFC
Thank you but I am here to build and share process using FOSS software. I already know closed source software which can do this.
Let me reword this :
Is there currently a safe way to split an IFC with a FOSS software ?
By safe I mean to make sure there is no data loss during the process :
Modifying geometry is not acceptable
Optimizing data by grouping reference from object which share same properties is acceptable
Something like :
open Ifc file
delete all building elements which are not in the container we want to separate from the rest
delete all element which are not related to remaining elements
@Cyril I am not currently aware of a safe way, even with closed source software. Any software which does any translation at the moment cannot be trusted to safely split anything up - this goes for all BIM authoring tools that have an import / export function. There is no single tool that does translation that supports translating the full breadth of the IFC schema right now.
The only tools capable of doing it safely would be underlying IFC parsers, like IfcOpenShell, or others like XBim. If a closed source package has this offering, they must do it with their parser without doing any translation steps. I would be interested to know if one exists. Perhaps something like Solibri Optimiser. Even then, I would treat it with caution. Will it make assumptions, or can I count on it to preserve less-obvious data that may go missing, like IfcProcess, IfcResource, IfcTelecomAddress...?
The safest way to write this with IfcOpenShell is as you've described - to look at everything, and delete one by one. However, element deletion is expensive, because all relationships must be considered to all other elements. It may also leave the file in an invalid state, perhaps breaking some IFC WHERE rules. Also, deleting the object doesn't mean the geometry is also deleted (which may be shared with non-deleted elements), which means additional checks need to be written. In short, the quick way of writing it may indeed cut down the number of elements, such that your 800MB file can then be opened by an importer, but it may not necessarily cut down the filesize, which may mean that your importer won't be happy still. Vice versa applies: the slow way of writing it will do it carefully and properly, but may take annoyingly long to execute.
If instead we redefine "safely" based on some common heuristics like we assume geometry is the biggest bloat, and that our BIM authoring tool focuses on BIM products instead of non-rooted elements then it becomes a bit easier and we can get a relatively quickly processed file with the important stuff retained. Here's an attempt, which takes an input file and outputs one IFC file per IfcBuildingStorey. It is an IfcPatch recipe called SplitByBuildingStorey. Here's an example output when I ran it on a 250MB IFC file and took out the lowest storey. In my test of that file, which had 34 storeys, the lower levels (which were bigger) were reduced to approx 20MB each. The higher levels were smaller.
You can run it with: ifcpatch -i input.ifc -r SplitByBuildingStorey
Note that the sum of the IFC files will very likely be greater than the original IFC file due to geometry reuse.
Let me know if it works for you and if you come across any issues :) Ping @aothms who might have a cleverer way of doing it, especially to remove the need for the disk read/write per storey - that could easily add a good 20 seconds per storey for your 800mb file just for the read/write portion of it, regardless of processing the elements. In short, maybe make some coffee while running the script, and keep a close watch in the cwd for results (first you'll see a pure copy of the file with the full 800MB, then it'll overwrite it with a much smaller version)
@Moult Thanks a lot ! I ran ifcpatch -i input.ifc -r SplitByBuildingStorey on file and it worked. :-) It took several minutes but not that much considering file size.
I took a look a bit further in the IFC file. Considering it can barely be called an IFC file as all wall are BuildingElementProxy and I let you imagine the rest, we can say that this is a success.
@Moult said : If a closed source package has this offering, they must do it with their parser without doing any translation steps. I would be interested to know if one exists. Perhaps something like Solibri Optimiser. Even then, I would treat it with caution. Will it make assumptions, or can I count on it to preserve less-obvious data that may go missing, like IfcProcess, IfcResource, IfcTelecomAddress...?
I was thinking of simple bim. This 8 years old video is still impressive today :
But as you said as it is close source it is hard to make sure that there is no loss.
About Solibri Optimizer I heard that it alters too much IFC structure and there is no tool to split a file.
@Moult said : The only tools capable of doing it safely would be underlying IFC parsers, like IfcOpenShell, or others like XBim.
Exactly that's why I talked about ifcopenshell and considering to make a try if nothing was existing. But you already did it in such a short time. Thanks a lot ! I will study your code to learn maybe extend/improve it some day. I have a big energy model I would like to split for testing purpose. Maybe I will find a way to do it in your code.
Ah yes, SimpleBIM. As far as closed source goes, SimpleBIM is one I would probably trust to do a good job. But as you say, we can never be 100% sure. I have an impression of Solibri that they prioritise leniency and flexibility over correctness, so...
Happy to hear it works :) Good to know we have one more tool in the FOSS toolkit!
@Cyril I just realised you mentioned energy model. I have a very hastily written half-baked completely incomplete Blender->gbXML exporter code here. Maybe it is useful to you. Maybe you can help write a fully featured one? You no doubt have much more experience in energy models and I have zero experience :)
Once we have a reliable gbXML workflow (by the way, gbXML spaces have an attribute that relate back to IFC spaces), that would be a huge benefit as people can then use Blender as an authoring tool for energy models.
@Moult I think I could use your gbXML exporter quite easily in FreeCAD... Would you be interested in trying to make it Blender-independent? I'm thinking in FreeCAD it could be fed with a list of Arch Space objects. There is quite a lot that is geometry-dependant, but maybe we could isolate that as much as possible into separate methods, then in FreeCAD I can derive a new class from yours and reimplement the geometry-related functions
@yorik Sure thing :) I haven't touched the code in a while and it currently is quite low on the to-do list, but gbXML expects a closed mesh polygon to represent a space (and from memory, only supports that, not like IFC which has 200 options :) ). Each face of the polygon represents a "surface". This is very simple in Blender and is isolated to the create_space function. As spaces are almost always very simple boxes / box-like closed shapes, this should also be very simple in FreeCAD :) Feel free to use it and please let us know when you do :)
Login or Register to reply.