Model Checks

I would like to share my latest thoughts and findings in dealing with Model Checks. First let me break the term Model Checks into some smaller categories.

1. Admin ( filenaming, object naming, model breakdown )
2. Spatial ( georeference, base point, clashes/clearances )
3. Element ( element properties/attributes )

I hope you will appreciate this is an attempt to be more specific about which information, "I" in BIM, I am actually evaluating. Combined these checks give an impression about the technical quality of the models, not of the overall design quality.

Element Information Checks

To do this, I find it an essential step to think about the project and develop two checklists.

1. a high level element check, e.g. for a house project I would expect a model to have a foundation, floors, walls, doors, windows, roof, etc, but I would not expect it to have bridge or rail elements in there.
2. a detailed element check, e.g. for a door I want to know, length, width, height, color, supplier, mark, installation date, fire rating.

These checklists should be agreed between stakeholders, be expressed in the BEP, and be alligned to an Internal Modelling Standard.

Without an internal modelling standard you open yourself up to inefficiencies.

Tools for Information Checks

Over the years I have used many tools such as Navisworks, Solibri recently I started adding #Verif3D, Desite, #BlenderBIM / IfsOpenShell to the mix. Why? Because they offer even better ways for automation ( to me ).

I always start of analysing the Model Elements Information in PowerQuery just to get a feel for what I am looking at, do some cleaning, basic wrangling ( such as unpivotting, grouping, adding colums, and relationship building ). Why? Because I can do that quickly and it is all very visual.

Once I understand the Model Element Information, I look will examin the structure of the checksfiles ( usually .XML or .JSON files ). Usually they have a structure to them that is easy to follow, e.g. a Desite check is build as followed <ruleItem id="value" name=value##value pattern="value"/>. I will fill those values by hand when I am in the Proof of Concept (POC) stage. Why? Because I can show my client exactly what is happening and they can try by themselves.

If the client is convinced our plans automating the checks are feasible I will use Python to automate the creation of the rule check files. Typically this involves reading a file, cleaning it, wrangling the data, exporting the results. Python is highly flexible and depending on your preferences you have multiple options to read .CSV or .XSLX files and produce .JSON or .XML files in return.

Summary

• more clients are telling the designers and contractores what elements and element properties/attributes they expect to see in the model.
• designers and contractors forgetting to think about their own needs, e.g. they might require specific information in the model for quantity extraction or the steering of construction vehicles.
• Tools are currently limited to support designers and contractors to validate their models prior to delivery to client. Basic checks if a specific element group has a certain set of properties, is possible. It gets difficult if you want to check for properties that vary for each instance of that element.
• BIM Consultants / Developers are still needed to support clients, designers and contractors meet their goals.

Examples

A #Verifi3D .JSON check that was manually adjusted.

Results of a #Verifi3D check. I deliberately failed the Assemblyhandle by adding a value that did not correspond with the information in my model.

Automated making of a #Desite check file. Here the focus lies on creating the string I mentioned earlier. I prefer the use of Jupyter to have more control over my coding and to see the interim results. Once I am fully satisfied I will refactor the code to a true .PY file.