Open imbur opened 8 years ago
Meeting notes from Madrid
UNINOVA materials found at https://github.com/mondo-project/mondo-demo-bim/tree/master/input
Interesting UNINOVA remarks:
We are not experts on edition of IFC files, but for our test we usually use a text editor (e.g. TextWrangler on Mac) but you can also use a IFC Viewer with edition capabilities such as DDS-CAD Viewer (http://www.dds-cad.net/downloads/dds-cad-viewer/). It’s free but only works on Windows.
“_elect” file corresponds to a view of the power distribution to be used by the electrical engineer “_mech” refers to the HVAC system and “_plumb” to the water system and are meant to be used by the mechanical engineer “_struct” represents the structural infrastructure of the building and should be used by the structural engineer.
We attached the a zip that contains IFC elements that are specific to some IFC domains (Domains.zip). Please notice that these IFC elements are not the only elements that will appear in a view as IFC elements shared by different domains (such as IfcWall) may also appear depending on the purpose of the domain specific view.
Typically, experts with the same role don’t work on the same building. But when the building complexity justifies it, they use duplicates of the same file and work on predefined spaces. The work is then merged by another expert, where he resolves any conflict that may occur. So no lock mechanism is used.
In our view for the MONDO use case, these situations may be handled by creating views based on domains and on spacial constraints (e.g. separation by building storeys). This way we can have, for instance, a different electrical engineer work on the power distribution in each floor.
Thinking again, maybe the files that we sent you are not the more appropriated. We are now sending a IFC file that have electrical, HVAC, structural elements and architectural elements. So that we can have may experts working over the same file (gold model).
Remarks from Antonio of York:
The GPL update site (the one with the Neo4j backend) has the BIM plugin as well, which embeds the EMF-compatible IFC parser of BIMserver. It should be enough to simply ensure that your Hawk setup includes this plugin.
If you need to run from source, the org.hawk.ifc/lib/README.txt file explains how to do it: you'll need to download two distributions BIMserver 1.4.0 and manually extract certain .jar files from them. We have to do it this way to avoid the usual EPL/GPL problem.
- On the procedure of BIM exports:
- Index the IFC models with Hawk on the MONDO server.
- Use a .hawkmodel with the appropriate effective metamodel to retrieve the part we want. The effective metamodel is defined by including excluding metamodels/types/slots or importing another .hawkmodel's effective metamodel.
- Right-click on the .hawkmodel and use "Export to IFC STEP" to fetch the part we want over the network and produce the .ifc file.
Antonio:
The relevant code is in the hawk.servlet plugin: the HawkModelElementEncoder class is responsible for skipping over excluded types and excluded features, and it will remove the excluded types from EReferences as well (so no dangling edges - it's as good as if they didn't exist in the first place):
- https://github.com/mondo-project/mondo-integration/blob/master/uk.ac.york.mondo.integration.hawk.servlet/src/uk/ac/york/mondo/integration/hawk/servlet/utils/HawkModelElementEncoder.java#L342
- https://github.com/mondo-project/mondo-integration/blob/master/uk.ac.york.mondo.integration.hawk.servlet/src/uk/ac/york/mondo/integration/hawk/servlet/utils/HawkModelElementEncoder.java#L384
Marcio:
These files were generated to comply to the IFC2x3 Coordination View 2.0 specification (http://www.buildingsmart-tech.org/specifications/ifc-view-definition/coordination-view-v2.0/summary). This view consists in a subset of entities of IFC2x3. Buildingsmart provides [http://www.buildingsmart-tech.org/downloads/view-definitions/coordination-view/sub-schema/CoordinationView_V20_EntityList_IFC2x3_Version16_Final.pdf] as a list of entities to validate Coordination view. Where BuildingServices contais the entities related with MEP (Mechanical, Electric and Plumbing).
"Spatial constraints":
One idea is to only allow editing elements contained in a specific floor (floor identified using IFCBUILDINGSTOREY element and associated with that floor using IFCRELCONTAINEDINSPATIALSTRUCTURE ).
@debrecenics: I have added hello world model at https://github.com/mondo-project/mondo-demo-bim/blob/master/input/helloworld.ifc
Uninova:
In attachment you can find a simple IFC example. This IFC4 example describes a simple house with 4 walls, one floor and one roof.
Picking up my example, you can find the definition of IFCBUILDINGSTOREY in line 74, corresponding to element ID #38.
In line 81 you can find the definition of IFCRELCONTAINEDINSPATIALSTRUCTURE with the ID #44. In this definition you can find a list of elements between “(“ “)" that are placed in that storey (identified in the last argument: “#38”). In this case, 7 elements are associated to the storey: 4 walls (#60, #87, #111, and #134), 1 floor (#158), 1 roof (#173), and 1 logical space (#188).
So, our ideia is to separate the building elements editable by storey, using the list in the IFCBUILDINGSTOREY to define the set of editable components that a certain expert may edit. Notice that even from the set not all components may be editable (e.g. electrical engineer can only edit electric-related components).
IFC files are indeed not easy to read. But most of the elements define geometric properties of the building components.
Current status: managed to find @debrecenics 's BIM-related projects, breathed life into them, did some small adjustments / modifications, and implemented the most recent Bien-Zenker case study.
With 4G heap memory, it now takes approx. 277 sec to run a GET for a model of approx. 100k elements.
How to serialize BIM models (@debrecenics, @bergmanngabor):
Basically, we need to create a Serializer and populate it with the relevant objects in the Hawk resource, and then we use the writeToFile(...) method to produce the IFC STEP file.
Quick measurements: a clean GET from scratch takes approx. 280-300 sec per front model, while propagating changes into a previously created front model takes approx. 70-80 sec perc front model. Propagating changes back (PUTBACK) is likewise around 70-80 sec.
Note that unique id matching is still imperfect, so a little bit of unnecessary retransformation happens every time, but it only amounts to ~1sec.