PSets and Exchange Requirements

[agroni]

I have been looking for topics about exchange information in Archicad and how could this be set up. Since I was not able to find anything, I will ask/suggest a workflow.

What we are stumbling upon is the required information that needs to be delivered at a certain stage of the project. These are usually defined Pset in a BEP Document. That is why, I was thinking of setting up these ERs (Exchange Requirements) in our template so we don’t need to invest time every time when a new project starts, but more to fine tune the current settings.

Usually Archicad comes with all possible Psets out of the box. My workflow to define these ERs would be to delete PropertySets (the red X) in the IFC Settings (Export) and save them as LODs. This way I can populate Psets according to the ER, which properties need to be delivered at what stage. If another project needs an additional Pset, then it can be generated.

Do you think this is a good idea? Or is there a better way?

[Anonymous]

agroni wrote:
Do you think this is a good idea? Or is there a better way?

This is a good idea. But there might be another way.
I personally don't like to use IFC Mapping. We used to use it a lot before Expressions in Properties where introduced. But it's quite tedious to manage.

I would rather make one Scheme according to BEP for final delivery. And then control the amount of data exported to IFC with Properties Classifications. So you can make Classification groups for each stage reducing the amount of data provided for each element. In IFC translator you have to just use the option to export only filled Properties to keep IFC size small.
This is an idea inspired by your question. I haven't tested it yet. Usually, we validate data outside AC.
There is one thing you need to be aware of. Not all Software supports multiple classification systems in IFC. For example, we have noticed recently that DDS-CAD goes crazy with mapping elements if you provide IFC with more than one system.

[agroni]

kzaremba wrote:
I personally don't like to use IFC Mapping. We used to use it a lot before Expressions in Properties where introduced. But it's quite tedious to manage.

Using expressions sounds like an interesting idea. Nonetheless I don't understand how did you manage to export this data into the specific Pset without the mapping, or did I not undertand your statement correctly? I personaly find the mapping a very cool thing

kzaremba wrote:
This is an idea inspired by your question. I haven't tested it yet.

The problem is of saving these settings as a preset that you can use or modify in the future. Making an efficient workflow is the key here. We also use a lot of Properties and Expressions, hence the problem of exporting "only the filled boxes", since our propterties for a not defined value look like this: ---
We use this to control variables if they are correct, missing or wrong for a speficif property. So the program recognizes this as a value (option set), hence exporting it even though it is not necessary according to the ER.

I will also try another workaround (if I find time) and will inform you if it turns out positive.

[Anonymous]

agroni wrote:
I personaly find the mapping a very cool thing

What I meant is that we used IFC Shemse as a kind of property with expression(before there were introduced). Since it has limited capabilities of editing text. For example, we did Space numbering consisting of Apartment number and Room number (ex 10.04). And then we made IFC property of Apartment by getting rid of Room Number (ex .04) with split option. Then we used it as property for schedules to Cluster Apartments. Now we do the same but directly in Properties. It's a nice way since you have only one place which determines Numbering and Apartments.
To sum it up I like mapping itself and of course, we use it. But the interface is not practical if you need to setup mapping for the whole project from scratch and maintaining it So I prefer to have possibly the smallest amount of schemes on the project. Especially that with several IFC translators for different purpose adding additional versions for each LOD will be a lot of Translators in Template.

agroni wrote:
The problem is of saving these settings as a preset that you can use or modify in the future

Yep, therefore, you need to set it up in the template. Preferably on the new project. Since modifying Properties might be tricky on bigger projects with lots of files. I did some testing and it seems to work fine. Some screens attached. I did one Scheme for Property mapping for both LODs. Classification Group is Controlling the LOI of an element. Properties are added with next LOD so each PSet shall have Group for each LOI.
There are two drawbacks I can see now. First, you can have two elements with two different LOI in one IFC. But this is quite easy to spot since you have to validate Classifications anyway.
Another one is that there is no way back when you use manual input. So if elements get LOD300 and then for some reason you decide to show the model in LOD200 then unchecking Classification will erase manual Input. But this also might be prevented however in most cases you just add more and more data anyway or tend to use expressions

agroni wrote:
I personaly find the mapping a very cool thing

What I meant is that we used IFC Shemse as a kind of property with expression(before there were introduced). Since it has limited capabilities of editing text. For example, we did Space numbering consisting of Apartment number and Room number (ex 10.04). And then we made IFC property of Apartment by getting rid of Room Number (ex .04) with split option. Then we used it as property for schedules to Cluster Apartments. Now we do the same but directly in Properties. It's a nice way since you have only one place which determines Numbering and Apartments.
To sum it up I like mapping itself and of course, we use it. But the interface is not practical if you need to setup mapping for the whole project from scratch and maintaining it So I prefer to have as small aoumt of shemed on project as possible.

agroni wrote:
The problem is of saving these settings as a preset that you can use or modify in the future

Yep, therefore, you need to set it up in the template. Preferably on the new project. Since modifying Properties might be tricky on bigger projects with lots of files.

[agroni]

That is a very nice example here.

The thing is, that I like to stick to the buildingSMART Schema, hence the properties (independently of their exchange requirements) are located in the *Common area. In your case you are separating the LOD200 and 300, which in this stage of the development of the industry it might create confusions where the information should be located, whereas the Pset_*Common is a general place for such information.

I have tested another workflow...

In the translator settings I have created two sets of classification mapping: LOD200 and LOD300. Then I went manually and deleted all unnecessary information in the 200. Because all my properties are correctly mapped with the Pset’s, the reduction was a simple step. This could be done when the BEP has been introduced into the contract.

In this case users populate all necessary properties in Archicad that are automaticaly mapped with both LOD200 and 300. It might happen that during the design phase a specifi information might start being implemented but is not necessary for the data drop. In this situation the separation of the LOD200 and 300 in the translator option separates such not complete information (which might be LOD300) not to be exported in LOD300. While switching to another planing phase, the translator needs to be updated to the correct classification mapping. I exported only populated Psets not to explode the IFC with unncessary garbage and as a result the IFC Schema looks very clean and according the ER.

The only disadvantage is the situation of adding new Psets in later project phases. The BIM Manager in this case must take causion to produce the correct naming, type (according to bsI) and mapping with properties.