I have received IFC files for other members of the design team. When i import the IFC file into AecoSIM i get different (and less acceptable) results than if i open it in AecoSIM. Why is this? Secondly is there any way around this? If i import i can get the family and parts and therefore cut sections and plans etc (apart from the missing elements that disappear when i import!) however if i open it i do not get any of this and therefore cant use the model in my drawings.
Opening an IFC file in AECOsim Building Designer is comparable to opening the IFC file in an IFC viewer. The graphic output you see is usually very good but AECOsim Building Designer only creates solids.
Importing the IFC file in AECOsim Building Designer creates AECOsim Building Designer elements as far as possible using families and parts. If AECOsim Building Designer creates a reference during the import you can merge the reference into the active file. Then you have e.g. walls, etc.in the active fille that can be edited.
The IFC 2x3 CV2.0 data exchange format - CV means Coordination View - is only designed for a coordination view not for an 1:1 data exchange. The creation of AECOsim Building Designer elements is done as a best effort but does not ensure that all elements are displayed correctly.
- Did you check the options in File menu > Import IFC > Settings tab?
- As an alternative you can reference the ifc-file and then merge it into the active file.
- You can check if the IFC export in the software that created the ifc-file offers different options. That might improve the ifc-file and also the IFC import result in AECOsim Building Designer.
- This thread about IFC import might also be helpful: IFC import - dataset mapping
"The creation of AECOsim Building Designer elements is done as a best effort but does not ensure that all elements are displayed correctly."
wow, that's a pretty fundemental to say that the program doesnt do!! so how am i supposed to know if the elements are displayed correctly???? I've got a 13 storey building with many thousands of structural elements it is impossible to go through and manually check each and every one to ensure that they have been displayed correctly.
- Yes I've checked the options in the import IFC tab.
- I cannot reference the IFC file in as i require the model to be imported on a floor by floor basis due to it's size and for ease of use when modelling. I also need the family and parts applying so that i can get plan and section cuts taken from the model.
- The IFC is exported absolutely fine, it's independently checked via Solibri by a 3rd party before we are issued with the information.
- We are data mapping everything correctly and as per the IFC import thread.
Below is just one example of a random 'block' that appears and stretches up through 13 storeys of building!!!
The top view is taken from Solibri and the bottom view is the imported IFC from AecoSIM. This is just one of a number of similar errors we are seeing with these files and it's making it very hard for us to trust the information we are modelling against, we've had;
- slabs disapprearing
- random placement of structural blocks
- flanges from steelwork disappearing
- holes in slabs not showing
Yea.. BEP's tend to be pretty clumsily written. They tend to be written by guys who have no idea of the actual implications on the ground. And when you ask if you can deviate slightly because what is asked for is problematic, you are told you do so at your own risk. I would not confuse the need to use IFC as an exchange medium and what each participant has to do to 'read' and 'present' the contents. Every app will be mangling the IFC information suit their purposes when they import the shared info. The problem is that in order to use Aecosim to create documentation, you need to have to attach F+P info to the elements... forcing you to import the IFC info... which means that Aecosim has to process the info further and convert the info into what ever 'schema' or approximation that works for Aecosim. This is probably a very error-prone task for the developers. Solibri etc only have to provide something that displays correctly. Once you import, the geometry will need to be editable / understood by the Triforma / DGS tools. I bet that this will be pretty daunting task for the resourcing bean counters at Bentley, if you take into account the need to also do this for ProStructures, Speedikon, Openplant, STAAD, RAM etc etc... and also all the road and bridge apps once IFC5 comes along. I suppose that's why they have started talking about a 'common modelling environment' with CE, which would be based on the new Parametric Solids. Hopefully, the old Triforma solids will be re-born as platform-wide Parametric Solids. And F+P and DGS will be subsumed by Element Templates and Element Types. That way, Igor only has to target one base case?