Names (for IFC)

[_c_]

Hello,

I am a new AC user from the German version (but I am not German) and am struggling to find a reliable way to fetch names of things.

Is there a singular parameter that fetches all conceivable names? I can use "Building Material / Composite / Pro­file / Fill" in schedules, but cannot find this parameter in the list of properties.

[Nathan Hildebrandt]

It is a lot easier but it may still not give you everything you want. It takes a little bit of time to work through all of the mapping. I would start higher up the tree where you can so you don't have to set mapping up for each IfcElementType and then when you need the extra granularity you do it per IfcElementType.

[_c_]

Thank you again,

I can thus generate the needed strings at property level while using the better coding facilities, then assemble all in the IFC Mapping.

[_c_]

Am I wrong, or it is not possible to parse certain infos of nested objects.

For example, if I wish to construct the name of a stair using its structural type, which is WITHIN the stair object. The only data I can fetch are a few thread/risers data.

How do you do this for the purpose of IFC mapping, be it in the properties or direct mapping?

[Nathan Hildebrandt]

Try this in the IFC Translator. The little down arrow enables you to access Library Part Parameters. You might find what you need, you may not, it is a complex process managing and exporting information.

[_c_]

Hello Nathan, 

please forgive the delay in answering. I got sick. Again thank you for your precious hint. Very interesting approach.

 Archicad is quite hard a nut to crack. I am really trying to find a common solution for a naming protocol, but even the easiest task seems to be impossible.

What we are trying to achieve is a naming structure in the form: AB-CDE-FGH-xxx-. This should work through all main ifc entites, it might - or might not - need to use material/profile/composite name.

Examples:

WA-STB-XPS-001 = reinforced concrete wall, xps cladded < uses material

ST-HEA-160-001 = column HEA 160 < doesn't use material

This kind of naming structure implies if conditions and string parsing.

1. properties that are accessable in the property manager are not necessarily available in the IFC Mapping dialog, see for example "Building Material / Composite / Pro­file / Fill"
2. the IFC Mapping tool doesn't allow for string parsing but some splitting, so we need to prepare chunks as calculated properties in the Parameter Manager
3. different element types have different parameter access. For example a GDL Beam has a different Material access than a built-in Beam, AND
4. elements based upon profiles have again another access. Materials are in this case based on the 2D geometry inside, but I am unable to fetch the list of materials for a calculation, as I can through an autotext label, for example.

I made a list of parameters using the little python access that I could see in Archicad, there are bucketloads of parms. An interesting question is, where is it documented, what is accessable where?

[Nathan Hildebrandt]

I personally haven't dug deep into what is available. I built a very strict set of Building Materials, Cut Fills and Surfaces that together with a strict naming convention for Composites and Complex Profiles meant that the capability of IFC mapping as it currently stands works for my workflows. You may find that those options are not viable for you and you have to find another way. I also had strict modelling rules for how each element is modelled and which tool is used for specific tasks. By doing so it enabled my whole system to work. I also know that composite data is exported in IFC so when you look at  it in Solibri the whole composite break up is identified in the material section. So I do wonder if there is such a need to drive that through to the Element Name or Description. In COBie workflows the Element Name needs to be unique. So your Type Name and Element/Type Description is where you can drive material or other identifiers.

[_c_]

So it is indeed only possible to fetch materials, cut fills AND/OR surfaces.

Be it.

Solibri is not the only application where we use our IFC models (whereby Solibri is indeed a blessing for most checking tasks). Whatever name one generates, one can add an ID to make it unique, so that's not the problem. 

IFC based cost software is mostly rather limited as of data parsing and works best with type names. Names are visible in lists without the need of filters. Whatever we can give out as type names, we should, and it must be consistent. Controlling names means also a gate to any kind of project-specific data transformation.

Also, the increase of team efficiency in resolving naming issues at export level is huge. Generating names, vs. manually setting them up, allows to force a "fix" for a number of user errors (the kind of stuff that seems to be always piling up no matter how good office templates are). 

In IFC-based workflows the main issue are hidden semantic mistakes or inaccuracies. There are these methods to spot and fix semantic mistakes in other software (which don't exclude each other):

1. advanced: scripts --> highest efficiency, lowest user stress
2. middle: families/styles/types
3. low: humans (coordinators checking and bashing their team on and on)

AC has a rudimentary Python access compared to other BIM software and doesn't have any way of consolidating types into some type definition (families, styles). I hope this changes soon.

AC is for many other reasons the best BIM app for the architect, it should fix these issues fast or...

Nathan, I'll look at all you published. You have been a great help to me.

PS

I worked with Vectorworks, Revit, Allplan and Microstation and I am looking forward to learn Archicad, my last one.

[Nathan Hildebrandt]

I did testing back in 2014 with several quantity surveyors, mind you they were all using Costx. I have jumped back into my testing folders to try and find the data they were able to receive (at the time) and I can't find it. I do know that depending on the settings they would even get around 50 columns of data for each element even with the bare minimum data export settings turned on. As you say the estimation software doesn't have all of the access to the IFC properties like Solibri does, but I think the way I structured our attributes solved all of the problems you are trying to solve. Mind you I think that your type naming strategy is a little bit more complex than the approach that I took. 🙂