General Discussion

Hi @david-polanski ,
Is Dalux also confirmed?
Thanks!

Hi @Matti-Kannala

Thanks for your answer… i understand most of what you say.

I can send you a smc file… maybe you can check it there.

Below an ITO of the levels… here you can see 2 models with different elevations but close to each other…
this is what is causing the extra footprint.

52a078a4-a412-4ef7-ba1d-86d9c328a3b2-image.png

The strange thing is… that if I add another model with lots of different levels with Elevations that do not match… no footprints are added.

Good luck on the new release!

Well, it is as I expected…

For some reason, the integers are not working. Maybe this has something to do with the German version?

For the time being, I simply used a text to get what I needed to work (working with variables of 0, 1 and 2.)

I didn’t play around with length that much…but I suppose that would be the only other possible option to use operators. “Real” Numbers also didn’t seem to work.

Since there are no replies, I figured I would revive this topic.

I have a similar issue. I am exporting a model with information regarding the concrete finishes. I would like to avoid setting unnecessary values in Revit. When I export my revit file, parameters which contain no value are no exported.

The operators in the classification are actually very very weak, and if I were able to, I could just handle this issue with wildcards.

What to do? It seems I need to create multiple rules just to handle a short-coming in the software. Is that so?

I guess if it’s Nemetschek…that makes sense…

Yes of course.
the issue is that accessibility rule gives quite many results. I’d like to know only if there is enough head space. So I thought that minimal distance rule should work, but is seams stairs do not work with it like slabs do.

In any case minimal distance rule should work or does the element need to be more regular shape?

Just seeing this post by now.
I just created a similar issue, which I found were related to the volume and size of the objects the rule is checking.

https://society.solibri.com/topic/2251/small-components-and-sol-234-1-2-issue

Hi Jeronen,

thanks again!
That’s a solution for me. Not as intuitive as i hoped it would be, but ok.
🙂

br
Marcus

@JSN

Then it partially explains, the level hierarchy is not taken by global coordinates, but by Top and Bottom elevation (properties) (*sea level or project), and the problem might lie inside of different software.

AR model is done in Revit, where is possible to export project coordinates and shared coordinates which include sea level, by defining sea level height - the top and bottom elevation in Solibri will show sea levels.

And EL model is done in CADmatic, and they have set floor heights by project heights.
and there is no such thing as a project or shared coordinates, where the model is set - that’s what you export. (with or without coordinates)

And seems that this explains the problem 🙂

As Solibri is unifying software maybe would be possible to integrate if there would be a possibility to pick by what the flooring hierarchy is done - top and bottom elevations or global Z elevation

This would solve some problems if the project is already done, for example,
we gonna test, EL gonna set the floor height by sea level and see if this works, or any other solution I will post an answer here. 🙂

Thanks.

@build-effects @JeroenKoomen @Harmen-Jorritsma @Ricardo @hkringsKUBUS

It seems that this is now working. Apparently Bimcollab is throwing and exception that version 9.12 can handle. Yesterday it threw an exception that 9.12 cannot handle, but 9.13 can.

Hi @cecilia-wang and @Paul-Linder

The new Info view looks like a great improvement 🙂

I agree with everything said (sticking the closest to bS terminology would be best, IfcQtoSets should have their own tab, selecting elements with same property value, seeing IfcProject in the hierarchy).

I have a related suggestion: pinning/bookmark some properties so that they appear on top of their tab or in a dedicated tab. That way you could have a quick manual check on how they are used throughout multiple elements. It would be nice to arrange and maybe even group your own pinned properties to your preference.
In this use case, it is also slightly annoying that the active tab is “reset” when you click on an element that doesn’t have the pset.
e.g I’m checking content of Pset_DoorCommon but click on a Door that doesn’t have it. Then when I click on the next Door, I need to reselect the Pset_DoorCommon.

Brilliant! This is more than what I was looking for…very helpful!

Hi,

I think this has to do with the IFC-Export options as well.

There may be a difference of how the IFC-Elements are geometrically constructed between 2x3 and IFC4…I’m still using IFC 2x3, but my faulty memory keeps reminding me of something to do with BREPs vs. Meshes.

There is a setting in Revit which allows you to specify how “exact” the elements should be geometrically exported. It would be amazing if this could be applied individually to elements, but it is a global setting by export.

Detail level of geometry = high will render a much more precise slab.

My interpretation (best guess) is that revit is facetting round objects with a set number of facets. Doesn’t matter if you have a 20cm column, or a 20m slab edge…the number of facets will always be the same; as determined by the Detail Level of Geometry setting I mentioned.

Unfortunately, using a higher level of detail can cause the model-size to balloon, especially if you have a lot of round columns / rounded surfaces in the project.

File size is also dependent upon the project size…a small building with a higher detail-level of geometry probably doesn’t affect anyone. If it’s a 20-storey building with a lot of rounded surfaces, you are probably creeping towards issues with file-size.

My best guess…

Cheers,
Matt

Here is the official statement from Solibri.

Just want to add a few thoughts on this topic:

If the quality of the IFC is so poor that it cannot be used without optimisation, it should be returned to the planner instead of optimising it afterwards.
There are very few use cases for optimisers that are actually necessary. Mostly the cause is poor export quality. Instead, one should start exactly there and improve it. If there are problems because the export of the authoring programme “can’t do it better”, instead of finding workarounds, pressure should be exerted on the development of the authoring software to better support the open and certified standard.

Double exported PSets, identical attributes existing several times in different PSets, etc. are not a reason for IFC optimisation, but problems that have to be solved in the authoring software. This also includes that models do not have to be separated in the IFC, be it due to their size or the fact that several buildings were modelled in one model.

One should keep in mind here that the planner owes a deliverable that is free of faults. Specifications on content and data quality should therefore be precisely defined in the BEP and also enforced.
Such duplicates and other flaws in the data quality are to be detected and communicated with Solibri so that they can be corrected.

@sarahhielscher @JENVDC

Thanks for the report. We are working on improving the Solibri IFC string decoding.

@Pasi-Paasiala

So how does it work?

Afaik if I load Classification B (which requires A) then nothing happens (also no warning) until I load A. Then A & B should be fine - I guess certain actions like loading/updating models/changing classifications … trigger (all?) classifications to be reloaded. But in which order?

If Classification C requires A & B then it should have no problem to scale.
If Classification A requires a Classification E (we assume it’s loaded) then I guess E is updated before all others. Is it?

And what if E is required as a column in A & B -> does this make any difference on calling/refreshing E or is it just iterating trough E’s values?

Problematic would of course b an accidental short cirtcuit when (A requires B and B requires A) - if this is the case e.g. on a classifcation change, then you classifications don’t update correctly - it seems like they only loose their results if a model is changed.

In general we try to use classifications in a kind of hierarchy from top to bottom to avoid such little accidents, but we also want to optimize their behaviour. Currently it seems like with many (depending) classifications little changes to classifications take a looong time.

Anyhow, I will try to find some time the above described behaviour and recreate a small mockup which can be transmitted for furhter investigation. In the meantime it would be good to understand the way how classifications work a bit more.