User-defined Pset wit .txt file

[MichCarr]

Hello everybody,

I would like to ask what is the meaning of the "I" or "T" setting in the .txt file the user can define to export user-defined Property Sets.

Reading the Autodesk Revit IFC Manual: "Specifying “I” for instance or “T” for type determines wheter this is a type or instance parameter". Actually in a Property Set I can include values taken both from an instance and a type parameter, so I cannot understand what that statement refers to. The tests I made did not produce different results in the "I" case or in the "T" one.

Thank you for you help, much appreciated.

Michele

[StewartGH1970]

This reference to the Type of Revit Parameter i.e. Fire Rate is a Type Parameter and Comments is an Instance Parameter. You can export both Type & Instance Parameters to the same Pset but you will need to create 2 Psets one T and 1 I e,g,

PropertySet: DGC_Data T IfcElementType Data1 Text Fire Rating

PropertySet: DGC_Data I IfcElement Data2 Text Comments

Hope this helps

[MichCarr]

Thank you Stewart, actually I tried your method, but actually it confirms what I have said in my first message regarding the use or "T" or "I". I set this user defined property set txt file:

PropertySet: Pset1 I IfcDoor Contrassegno Text PropertySet: Pset1 T IfcDoorType FireRating[Type] Text

PropertySet: Pset2 T IfcDoor FireRating[Type] Text Contrassegno Text

Pset1 follows your suggestion: in my model 'Contrassegno' is an instance parameter, while 'FireRating[Type]' a Type one. Pset2 hosts both a Type and an Instance Parameter. As you can see, the use "T"/"I" and the choiche of the IFC Entities is random (on purpose).

You can see the final result in the image here attached (I still would prefer to have only one Pset1, with both Type and Instance parameter included).

Am I missing something, maybe?

[StewartGH1970]

i ran a test and i got the result i expected Pset2 didnt come through because it was a mixture of both T & I - Pset1 comes through as it has been split - one for T & one for I hence why Fire Rate (Type) is italics.

I would use IfcElement & IfcElementType not IfcDoor - i tried this and it made no difference

[StewartGH1970]

UPDATE

i ran a test changing IfcElementType to IfcElement and Pset2 came through so hopefully this solves your issue - i have seen this issue before especially for NominalLength dimensions which are Type but will only be exported to Ifc if exported via IfcElement and not IfcElementType so prob best practice to only use IfcElement

[StewartGH1970]

Also FYI you should refrain from using Pset as a prefix to your property set naming - BuildingSmart states only official property sets can be prefixed Pset_

just a heads up :-)

[MichCarr]

Thank you Stewart for you precious help.

Actually I can't obtain the same results as yours (I am referring to those ones in your last post, the one starting with "UPDATE"). Maybe because of different Revit or IFC for Revit version, or because of the MVD used. I really don't know!

I made some more detailed tests - which include also the test you made (n. 5) - in order to explain the situation I am facing. As you can see, I did not face any variation using T or I, nor using instance or type IFC Classes:(

I also check the outgoing IFC files with Notepad since different viewers show different results. In my opinion, waht usBIM.viewer shows is more compliant with what is in the IFC file, namely three different Property Sets attached to IfcDoor, and two Property Sets attached to IfcDoorType.

I hope to have been clearer now. Thank you again! IFCExport_Tests.pdf

[StewartGH1970]

i was using Revit 2019 IFC 2019.3 export also Coordination View 2.0

just a heads up but you should only be using IFC2x3 CV2.0 or COBie2.4 as these are the official certified exports by BuildingSmart as IFC4 isn't being used or supported as revit export hasn't been certified yet.

looking at your results you do seem to be getting the same results as me

C is weird as because you have mixed up T & I the psets in IFC get mixed up so i would stick with E ie T and IfcElement as this covers both T & I

[MichCarr]

Thank you again. I checked that the difference in the export is linked with the use of different MVDs.

Regarding the use of MVD, I do not think that Revit is COBie 2.4 certified by bSMART: https://www.buildingsmart.org/compliance/software-certification/certified-software/ Of course it is CV2.0 certified, but this does not ensure total compliance with the standard (at least for what I know about bSMART certification). For this reason, by a "safety" point of view, I do not see this huge difference in using IFC4 Reference View or IFC 2x3 CV 2.0.

Going back to the starting topic, I tried also with CV2.0 IFC 2x3. I know that C is weird, but I try that setting just to see if something changes using "T" or "I", and actually it seems that nothing changes. Neither using RV IFC4, nor using CV 2.0 (apart from the splitted use of italics in the Solibri Property Set tab: I did not manage to undestand from where Solibri takes that information - see the PDF attached).

By the way, since data - which is my actual scope - is exported in both ways (namely using I or T indipendently from Revit parameters), my question is: why should I define two Property Set, with the same name, one for Instance and one for Revit parameters?

I would understand if this would allow me to map separately Property Set linked with instance (es. IfcDoor) and type (es. IfcDoorType/Style) IFC Classes, but it seems that it is not possible. Isn't it? IFCExport_Tests_7-9.pdf

[AngelVelezSosa]

You can use IFC4 reference view. Even though it hasn't been certified yet, it is a real MVD, and our implementation is definitely usable.

[StewartGH1970]

@MichCarr appreciate COBie 2.4 MVD hasnt been certified but neither has any IFC4 MVD - i use the COBie 2.4 MVD as it exports Type Marks, Marks and Descriptions without any Ifc parameter mapping ie IfcName or IfcDescription.

Thanks @AngelVelezSosa i'll have a review but been keeping away from IFC4 given industry is mostly using IFC2x3

[WawanSolihin]

The answer to the question is yes, The I and T do not seem to make a difference. This is due to the way the Pset is defined in IFC, which always allow the Pset to be applicable to both Instance and Type. Therefore the Pset definition even if it is specified to be application to I IfcWall, will still be evaluated for the IfcWallType, and the other way round: T IfcWallType, will be evaluated for IfcWall too. So the better definition should be just:

PropertySet: BetterPsetDef T IfcWallType FireRating Text Contrassegno Text

(or in this case I IfcWall will have the same effect. Note that in IFC2x3 it is not always the case for MEP objects. The assignment to Type will include the instance, but not the other way round) So the above definition basically supports both IfcWall and IfcWallType. The decision on what parameter to be evaluated is by the existence of Parameter in Revit Instance or Type. Since Revit does not allow the same Parameter is assigned to both Instance and Type, Revit IFCExporter introduced "work around" by allowing suffix "[Type]" to be used for Revit Parameter to allow the same property to be applied to both Instance and Type. To clarify, the following example shows how that works: in Revit, I created the following Project Parameters:

Contrassegno (assigned to Instance) Contrassegno[Type] (assigned to Type) FireRating (assigned to Instance. Note no FireRating[Type] is needed since there is already "Fire Rating" parameter for the Wall Type)

The export result is as followed:

Hope that helps

[PeterTranberg]

@WawanSolihin Wich IFC viewer ar you using? In Solibri there is no separation between Instance and Type PropertySets to my knowledge. So just to Clarify the I and T in the mappingTXT refers to the IFC result definition not the Revit Definition?

Is there any usecase for the Instance and Type difference in IFC files, better workflows or data?

I Have been using this method to get all relevant information for a Building Owner: Pset Pset_KK I IfcRoot Property Text

It works for Revit Instance and Type Parameters. /PT

[WawanSolihin]

Oh well, as I mentioned the I and T in the user defined Pset is no longer make any difference. It will be evaluated depending on where the property is found in Revit, i.e. if the property is found in the Instance, the Pset will be exported in IFC attached to the object. If the property is found in the Type, the Pset will get exported to the Ifc type. Therefore as you said your user defined Pset Pset_KK works for both Instance and Type (as long as they use the same parameter name). What I mentioned also is that Revit allows a parameter to be assigned to Instance OR type. To overcome this limitation so that we can get the same Pset for both Ifc object and type, you may use [Type} in the type parameter. So you can have Property and Property[Type] parameters in Revit, one is assigned to the instance and the other one to the Type. Upon export the [Type] will be removed.