Formulas in ARCHICAD 22

One of the main innovations in ARCHICAD 22 is formulas, which proved much more versatile than they initially appeared.

Many users expected formulas in interactive schedules with functionality similar to Excel. Instead, formulas appeared in individual element properties, with some limitations that quickly became apparent.

For many people, a BIM model is primarily a three-dimensional building model. Yet without information, it is essentially just a 3D mockup. Adding that information manually is labor-intensive, so it may seem easier to write notes as plain text when preparing documentation. But projects are no longer just stacks of paper drawings.

More importantly, the goal is not merely to complete a design and hand it to a client, but to create a database of interconnected information where changes to any part propagate throughout the project. ARCHICAD has long offered ways to automate model information through element parameters. Formulas take these tools further by combining parameters and properties and establishing relationships between them.

General Features and Usage

Formulas were introduced as a new value type for custom Properties created in the Property Manager. Like ordinary Properties, formula-based Properties are assigned to element Classes, as shown in the lower panel on the right side of the dialog box (Fig. 1).

Fig. 1

Clicking Add opens the Formula Editor. The Parameters and Properties button lets you insert properties from the Classification and Properties panel of each element. You can type functions and units directly if you know their names and syntax, or select them using dedicated buttons.

Functions are grouped by type, with tooltips on hover and detailed help available through a right-click. When you select a function, the Formula Editor inserts its correct syntax; you only need to supply values (text in quotation marks and numbers without them). Hints appear in real time at the bottom of the editor while you type. Overall, the interface is approachable, and the syntax is clearly explained in the user guide.

Custom Properties, both with and without formulas, appear at the bottom of the parameter list available for the Formula Editor, autotext, and Interactive Schedules (Fig. 2).

Fig. 2

A more detailed explanation of formulas is available on the website, and the official GRAPHISOFT Russia channel has a dedicated playlist about formulas in Property values.

First, let's define the conventions used throughout the rest of the article.

• Formula examples will appear in italics.
• Element parameters and Properties inserted into formulas are shown in gray, matching their appearance in the Formula Editor. For example, if you copy the Roof Slope parameter from the editor into an external text editor, it appears as {Property:Крыша/Уклон}, which encodes the group containing the parameter. Therefore, you cannot simply copy the formula examples in this article. You will have to select or create the required properties manually. This selection process also helps you become familiar with ARCHICAD's standard element parameters and Properties.
• The custom Properties I created have a blue background.
• {ФОРМУЛА} denotes an abstract formula whose details are irrelevant to the example.

A central principle of BIM design, including work in ARCHICAD, is to create a standardized template. Formulas allow much more complex relationships among ARCHICAD element parameters and should become an important part of your working template. Since version 21, custom Properties have been assigned to element Classes rather than tools, so you need a clear understanding of how you classify project elements:

• Review and edit the standard classification or create your own from scratch.
• Assign the appropriate classification to Favorites elements.
• Understand and document all your attributes, including their names and storage structure.
• When creating new Properties, carefully plan their names and grouping.

Without these steps, formulas will introduce confusion into your workflow, making it difficult to navigate growing amounts of data (Fig. 3).

Fig. 3

Once the template is defined, documented, and its classifications understood, decide what problem you want a formula to solve. My first idea was to create a Property showing roof slope as a percentage. I created a Property in the Main Structures group, selected the applicable Classes (Roof and Ramp Flight in my case), set its default value to Formula, and entered:

100 * TAN (Уклон)

and finally changed the data type (to Number).

You can create all Properties in one group, but over time that becomes confusing. You can also make Properties available to every Class, but the list of Properties in each element's settings dialogs would grow indefinitely. Many formulas could not even be evaluated because the Slope parameter exists only for roofs.

You can define the formula directly as:

CONCAT ("i="; STR (100 * TAN (Уклон); "%"),

to get the text string “i=1,50%” (provided you change the data type to String). However, the result cannot be used in subsequent calculations. You can also add the required text to a Text/Autotext label and save it in Favorites, although the slope direction still has to be set manually.

Formulas should be available only for Classes where the calculation is relevant and possible. A custom Property may also be created and used in formulas without being exposed to any Class. For example, create a Fire Resistance Rating Property with the Option Set data type and values I, II, III, IV, V.

This acts somewhat like a Project Info field but lets you choose from predefined options instead of entering text. That can help because formulas require exact values, and even an accidental trailing space in a parameter can disrupt a calculation.

A Property may contain several formulas, evaluated in sequence from top to bottom. If the first formula cannot be evaluated for an element, the next is tried, and so on until a result is obtained or there are no formulas left. All formula results within a Property must have the same data type.

If all formulas have been tried and none applies, the result is <анализ формулы недоступен>, and the interactive schedule displays “---”. Therefore, for a Property containing multiple formulas with the String data type, I recommend placing a noticeable warning such as “!ОШИБКА!” last.

That message then appears in labels, schedules, and element Properties, making it clear that the formulas or applicable Classes need correction. Moving other formulas below the warning keeps them stored but excludes them from calculation (Fig. 4).

Fig. 4

A single Property can hold formulas for different element types (walls, columns, slabs, etc.). To restrict a formula to one element type, include at least one parameter specific to that type, even if the calculation does not need it. For example, in:

IF (Уклон <> Уклон; "!ОШИБКА!"; {ФОРМУЛА})

the condition comparing a roof's slope to itself can never be true. It is included solely to restrict evaluation to roof elements; other element types proceed to the next formula.

Currently, comments cannot be added inside formulas. When many formulas are stored in one Property, it becomes difficult to tell which applies to which element type. To identify them, I started adding an initial condition that is not necessary for the calculation itself.

For example (Fig. 5):

IF ("Стена" = "-"; "!ОШИБКА!"; {ФОРМУЛА}) Fig. 5

Obviously, the string “Wall” can never equal “-”, so the Property value will never become “!ОШИБКА!”. However, the start of the formula now includes a label identifying the element type for which it was created.

Complex formulas are often easier to manage when split into several Properties that perform intermediate calculations. For example, the result of a formula calculating roof slope as a percentage can be displayed on its own or used by other formulas, such as determining roof type (flat or pitched):

IF (Уклон в % <= 5; "Плоская"; "Скатная")

In other words, a roof is considered flat if the slope is 5% or less, and pitched if the slope is greater than 5%.

Pay close attention to the data types of formula-based Properties and how ARCHICAD determines them. For example, the Roof Slope parameter is initially an angular value, but after applying the tangent function it becomes a number. This behavior can be useful.

Suppose linear dimensions are displayed in millimeters but you need the lengths of certain elements in meters. Rather than changing the unit settings for one parameter, create a length Property for the required element type and enter:

3D-длина * 1 m

The original parameter's data type was Length. After multiplying by one meter, the numerical value stays the same, but the data type becomes Area and is displayed using the area settings (usually m2 with two decimal places).

ARCHICAD does not yet support formatting formulas. Inserting a line break does not cause an error, but the formula returns to one line after closing and reopening its dialog. For complex formulas, you can draw diagrams, as discussed below, or use an external text editor such as Sublime Text to check matching parentheses.

ARCHICAD formulas are sensitive to the language version: an element type is called “Стена” in the RUS version and “Wall” in the INT version. Built-in parameter values such as Position and Structural Function also vary by interface language. However, formula functions and the TRUE/FALSE values are in English in both versions.

Parameters and Properties inserted into formulas are tied directly to their definitions; renaming a custom Property updates it automatically in every formula where it is used. Property values, including Option Set values and built-in parameters such as Position and Structural Function, must still be typed into formulas manually. I recommend opening a second ARCHICAD instance to copy Property values more conveniently.

Sometimes a Property should allow either a formula result or manual input. In element Properties you can break the link to enter a custom value (Fig. 6), but restoring formula calculation then requires manually resetting the value to Default. This is inconvenient. In these cases, I create two Properties: A, a simple String value (or Option Set) defaulting to “-” for manual input, and B, which contains this formula:

IF (A<>"-"; A; {ФОРМУЛА})

If A has a value, then B=A; otherwise, {ФОРМУЛА} is evaluated.

Fig. 6

Example 1: Assigning Wall Fire Resistance Ratings Under Federal Law 123

A truly complex, multi-level formula requires a diagram of branching conditions to understand its logic and count and position closing parentheses. Deriving values from a table is one such task and can be considered a separate class of formula problems. As an example, I will show part of the process using the table for assigning fire resistance limits to building structures (Table 21 of Federal Law 123; Fig. 7).

Fig. 7

It was clear from the start that the fire resistance designation (R, RE, E, etc.) and the actual fire resistance limit should be separate Properties, substantially simplifying the formulas. Next, identify the inputs: which parameters already exist in ARCHICAD, which need to be created as Project Info fields or custom Properties, and which are automatic versus manually entered.

Such a formula naturally uses the standard Position and Structural Function parameters, making correct assignments essential. I created a Fire Resistance Class Property usable both in formulas and in project-wide data.

I also had to add a custom Property indicating whether a wall belongs to a stairwell because the built-in Name of Related Zone Property links the wall to the first adjacent zone created, which is inconvenient to track. Ideally, it would list all zones adjacent to the wall, rather than just the first one placed.

Before writing formulas, identify general patterns in how parameters are assigned rather than trying to calculate every table cell separately. For example, at fire resistance class V, no structures have a specified requirement, so that entire row can be excluded with a global condition. For exterior walls, the next relevant question is simply whether the class is I. I drafted the formula logic as shown in Fig. 8.

Fig. 8

Figure 9 shows the finalized diagram with explanatory notes for this article.

Fig. 9

As you can see, the final diagram differs slightly from the draft. I initially overlooked that only internal stairwell walls have different fire resistance requirements. To find mistakes, formulas must be tested across every possible scenario, preferably by someone who was not involved in writing them.

Notice also that after testing every possible fire resistance class, the formula returns not a generic error but a message explaining that the class is invalid—either missing entirely or entered incorrectly (with an extra space or a nonstandard value). Such internal checks can be built into formulas, but unfortunately only for the String data type.

The result is a formula that would be almost impossible to create without substantial preparation and careful planning of its structure:

IF ( "Стена" = ""; "!ОШИБКА!"; IF ( Предел огнестойкости <> " "; Предел огнестойкости; IF ( Длина Линии Привязки <> Длина Линии Привязки; "!ОШИБКА!"; IF ( Степень огнестойкости = "V"; "Не нормируется"; IF ( Конструктивная Функция = "Несущий Элемент"; IF ( Степень огнестойкости = "I"; "120"; IF ( Степень огнестойкости = "II"; "90"; IF ( Степень огнестойкости = "III"; IF ( AND (ЛК_Конструкции = TRUE; Расположение = "Снаружи"); "60"; "45" ); IF ( Степень огнестойкости = "IV"; IF ( AND (ЛК_Конструкции = TRUE; Расположение = " Внутри"); "45"; "15" ); "!Степень огнестойкости задана неверно!" ) ) ) ); IF ( Расположение = "Внутри"; IF ( Степень огнестойкости = "I"; "30"; "15" ); "Не нормируется" ) ) ) ) ) )

I labeled the formula because I plan to extend this Property to all required element types. I also created a duplicate Fire Resistance Limit Property in case the value must be entered manually. Another Property restricts the formula to walls.

Ideally, formulas would be created through a graphical diagram editor, reflecting the growing popularity of visual parametric tools such as Grasshopper. These formulas seem to stretch beyond the functionality originally intended for this tool. I expect future development to make them easier to use.

After creating the formula, you may want to use graphic overrides to check the results visually, but there is a software limitation: Properties with complex formulas cannot be used as graphic override criteria. A workaround was demonstrated by Igor Yurasov at a conference in Kyiv.

Create an Interactive Schedule containing the unique IDs of elements whose fire resistance Property equals, say, 90. Save the schedule as TXT and copy the list of GUIDs into a prepared Project Info field that acts as a data buffer. Then create a new Property with a simple formula:

CONTAINS (Уникальный ID;!ПБ 90!; FALSE),

Here !ПБ 90! is the field created in Project Info, and the formula checks whether the element's GUID is on that list. A Project Info field and GUID-checking Property are needed for each possible result of the original Fire Resistance Limit Property.

With help from Yuri Tsepov of Labpp, I automated writing element GUIDs into Project Info. A C++ script (GUID предел огнестойкости. cpp, included in the attached archive) lets me write lists of element GUIDs grouped by specified characteristics into prepared Project Info fields with one click in Labpp's free Goodwin GDL extension (or any of the company's paid products). The result is shown in Fig. 10.

Fig. 10

I may refine this formula structure later, or you may find a more elegant solution. The steps may sound extremely complex and time-consuming, but most require only one-time template setup and some practice during modeling. The result is a truly interactive BIM model rather than a simple 3D mockup.

Example 2: Naming Windows Under GOST 23166–99

A general GOST standard defines window naming rules, while standards for window units made from different materials use somewhat different names. I developed a compromise approach for my work.

Because formulas cannot yet use parameters from library elements, I created several Option Set Properties for selecting window material and opening type. I also created a thermal resistance parameter and a group of Boolean Properties for options such as transoms and vents.

This may seem like a lot of inputs to enter manually, but future formula development should reduce that number while retaining the database created now. Frequently used window types can also be saved as Favorites.

Previously, I had to consult standards to determine the GOST for a window material or the code for an option (Фр for a transom, КК for a climate vent, etc.). Now I can simply check the options needed for the window (Fig. 11).

Fig. 11

The thermal resistance Property defaults to the minimum permitted value for the project's region and applies to all windows. If the client later decides to improve building performance by upgrading the windows, changing the default in Property Manager updates the entire project. Individual windows with custom values, such as those in technical rooms, remain unchanged.

Set the applicable Classes for this Property group; in my case they are Window and Balcony Door.

For naming, we effectively need to populate two schedule fields: Designation and Name. The first uses a relatively simple but nested formula selecting the GOST standard based on window material:

IF ( OR ( Признак предела огнестойкости_Ф <> " "; ОК_Материал = "Индивидуальный" ); "Индивидуальный"; IF ( ОК_Материал = "ПВХ"; "ГОСТ 30674-99"; IF ( ОК_Материал = "Алюминий"; "ГОСТ 21519-2003"; IF ( ОК_Материал = "Дерево + стеклопакет"; "ГОСТ 24700-99"; IF ( ОК_Материал = "Дерево + стекло"; "ГОСТ 11214-2003"; IF ( ОК_Материал = "Дерево мансарда"; "ГОСТ 30734-2000"; IF ( ОК_Материал = "Защитное"; "ГОСТ 31462-2011"; "!Материал задан неверно!" ) ) ) ) ) ) )

In my work I do not specify a particular manufacturer of fire doors. First, the formula checks whether either the Fire Resistance Designation_Ф Property has a value or ОК_Материал is set to “Индивидуальный”. If either is true, Designation also becomes “Индивидуальный”. Otherwise, the appropriate GOST is selected based on the value of ОК_Материал. Once all possibilities have been checked, a validation value is included to flag a wrongly entered custom Property.

Name is a more complex parameter, so I divided it into several formula-based Properties. First, the product type (ОК_1_Вид) is determined:

IF ( OR ( Признак предела огнестойкости_Ф <> " "; ОК_Материал = "Индивидуальный" ); "Оконный блок"; CONCAT ( IF ( КЛАССИФИКАЦИЯ моя - 22 = "Балконная дверь"; "Б"; IF ( КЛАССИФИКАЦИЯ моя - 22 = "Окно"; "О"; "!Ошибка Классификации!" ); IF ( ОК_Материал = "ПВХ"; "П "; IF ( ОК_Материал = "Алюминий"; "АК "; IF ( ОК_Материал = "Дерево + стеклопакет"; "Д"; IF ( ОК_Материал = "Дерево + стекло"; "Д"; IF ( ОК_Материал = "Дерево мансарда"; "Д МАНСАРДНОЕ"; IF ( ОК_Материал = "Защитное"; "П защитный"; "!Материал задан неверно!" ) ) ) ) ) ) ) )

First, I again check whether a window fire resistance rating is specified or the material is set to “Индивидуальный”. If not, the product-type code is selected based on one of two classifications, with a final validation step. CONCAT combines the product-type code with the material code selected according to ОК_Материал.

Next, define the window construction (ОК_02_Конструкция общая):

IF ( OR ( Признак предела огнестойкости_Ф <> " "; ОК_Материал = "Индивидуальный" ); ""; IF ( ОК_06_Заполнение = ""; "О"; IF ( ОК_Материал = "Дерево мансарда"; "-1"; "ОСП" ) ) )

Again, we first check whether the window is custom. Otherwise, if the next Property describing the glazing is empty, we insert the single-glazing code. We then choose between a roof window with a center-pivot opening mechanism (GOST 30734–2000) and a single construction with insulating glass.

This formula shows that I did not cover every possible window configuration, only those I encounter in my work.

Next comes a seemingly simple size Property (ОК_03_Размеры). But in case I ever need to classify a Library Object as a Window, I added two formulas. The first is for an actual window:

IF ( "Окно" = ""; "!ОШИБКА!"; SUBSTITUTE ( CONCAT (STRCALCUNIT (Ширина); "-"; STRCALCUNIT (Высота); IF ( КЛАССИФИКАЦИЯ моя - 22 = "Балконная дверь"; Ориентация; "" ) ); " "; "" ) )

The formula starts with a label. CONCAT then combines Width, a dash, and Height. If the object is classified as a Balcony Door, the opening orientation is appended to the dimensions. Each Length parameter must first be converted to a String using STRCALCUNIT, because only strings can be concatenated.

In ARCHICAD, number grouping (sets of three digits) is controlled through Windows Control Panel -> Region -> Additional Settings -> Digit Grouping. In ARCHICAD 22 formulas, changing that setting does not affect digit grouping. I therefore had to remove the spaces between digit groups. TRIM does not remove these spaces, so I copied the separator into a SUBSTITUTE formula and replaced it with nothing (two adjacent quotation marks).

The second formula in this Property is for a Library Element:

IF ( "Объект как Окно" = ""; "!ОШИБКА!"; SUBSTITUTE ( CONCAT ( STRCALCUNIT (Длина (A)); "-"; STRCALCUNIT (Высота) ); " "; "" ) )

This formula largely repeats the previous one, replacing Width with the Library Element parameter Length (A).

Next, I add codes for additional window options under the Property (ОК_04_Конструкция_Детали):

IF ( OR (Признак предела огнестойкости_Ф <> " "; ОК_Материал = "Индивидуальный"); ""; TEXTJOIN (" "; TRUE; IF ( ОК_Форточка = TRUE; "Ф"; ""); IF (ОК_Фрамуга = TRUE; "Фр"; ""); IF (ОК_Клапан вентиляционный = TRUE; "ВК"; ""); IF (ОК_Клапан климатический = TRUE; "КК"; ""); IF (ОК_Система самовентиляции = TRUE; "СВ"; ""); IF (ОК_Система безопасности = TRUE; "СБ"; ""); IF (ОК_Открывание = "Поворотно-откидное"; "ПО"; IF (ОК_Открывание = "Параллельно-выдвижное"; "ПВ"; ""))))

The formula begins with the usual custom-window check. That check could have been extracted into a separate subproperty and reused, but I already had enough Properties. Codes for window options (transom, vent sash, etc.) are then combined into a string when their values are TRUE. Finally, the opening types I use are evaluated. TEXTJOIN joins these codes, allows a separator to be specified, and ignores empty values.

The final subproperties (ОК_05_Класс and ОК_06_Заполнение) have the same structure and determine their values from ОК_R:

IF ( OR ( Признак предела огнестойкости_Ф <> " "; ОК_Материал = "Индивидуальный" ); ""; IF ( ОК_R >= 0; ""; IF ( ОК_R >= 0,8; "А1"; IF ( ОК_R >= 0,75; "А2"; IF ( ОК_R >= 0,7; "Б1"; IF ( ОК_R >= 0,65; "Б2"; IF ( ОК_R >= 0,6; "В1"; IF ( ОК_R >= 0,55; "В2"; IF ( ОК_R >= 0,5; "Г1"; IF ( ОК_R >= 0,45; "Г2"; IF ( ОК_R >= 0,4; "Д1"; IF ( ОК_R >= 0,35; "Д2"; "" ) ) ) ) ) ) ) ) ) ) ) )

I check the R values (thermal resistance) in sequence according to Clause 4.7.1 of GOST 23166–99. The formula for selecting insulating glass is similar, but uses the designations of the glazing units you work with and their R values instead of class labels.

Finally, the ОК_НАИМЕНОВАНИЕ Property combines the calculated subproperties into a single name:

TRIM (TEXTJOIN (" "; TRUE; ОК_01_Вид; ОК_02_Конструкция общая;

Д/ОК_01_Описание_Начало; ОК_03_Размеры; ОК_04_Конструкция_Детали; ОК_05_Класс; ОК_06_Заполнение; Д/ОК_02_Описание_Конец; CONCAT (Признак предела огнестойкости_Ф; Предел огнестойкости_Ф)))

Property values are joined with TEXTJOIN, and TRIM removes extra spaces as a precaution. Д/ОК_01_Описание_Начало and Д/ОК_02_Описание_Конец are simple custom String Properties for adding a description at the beginning or end of a window or door name when needed.

The resulting Interactive Schedule for window infill is shown in Fig. 12.

Fig. 12

The left section contains the schedule intended for the drawing sheet. The columns on the right, with crossed-out headers, are used to manage names directly in the Interactive Schedule and are cropped out when placed on a Layout.

The result of this automation can be used directly for graphic overrides through the ОК_Материал Property (Fig. 13).

Fig. 13

To conclude, I want to repeat that this material is intended to explain how the new tool works. It does not claim exact compliance with regulatory requirements, although it meets my practical needs.

Example 3: Selecting a Ventilation Duct Cross-Section in an Apartment

In this example, I will demonstrate how to automate an HVAC team's task of sizing natural ventilation ducts in apartments, using formulas, the Labpp_Квартирография extension, and ARCHICAD's new custom Label feature.

On many projects I waited a long time for the HVAC team's required natural ventilation duct areas for apartments (our clients do not want to use standard prefabricated ducts). Eventually, I obtained a general set of requirements (Fig. 14).

Fig. 14

Seeing those tables was discouraging, and I had to think through what to do next. I do not intend to debate the correctness of the calculations or the assignment itself, because I never managed to obtain references to the exact standards governing the calculation.

Essentially, I need to determine apartment type from the location and number of bathrooms, which I can only do manually. I also could not automate the number of residential floors or floors with commercial space in a building section, especially since a project may have multiple sections with different parameters.

The number of vertical duct-area zones or groups also has to be entered manually: sometimes there are two grades, sometimes four, and sometimes one duct area for the entire height. The resulting Property set is shown in Fig. 15.

Fig. 15

All these Properties are available to my custom Annotation Class, which I created for apartment markers supplied with the Labpp_Квартирография extension.

The add-on extends ARCHICAD formulas because, although formulas operate on individual elements, the add-on combines areas from many zones into one object, groups them, and enables calculations using the aggregated data. The Library Object Property values must be transferred to custom Properties in the Property Manager. The add-on includes a dedicated script, which I modified for this task to transfer the apartment's living area into a custom Property.

Let's follow the duct-selection process. First, model the apartment, place Zones, and link them to the apartment Marker. I demonstrated the apartment-planning add-on in detail in a dedicated webinar.

Then run the script (S жилая OP-UP.cpp in the attached archive) and transfer the apartment living area to the S жилая custom Property (Fig. 16).

Fig. 16

Next, manually select the apartment's KV ventilation duct type, enter the number of residential floors and the first residential floor number. This raises a problem: I must either memorize apartment types or consult a reference. ARCHICAD's new custom Label feature helps.

You can draw the required diagram using lines, polylines, and fills, insert text or autotext at specified positions, then save it through Document -> Annotation -> Label to use as a custom Label. I made such a Label to assist with duct sizing (Fig. 17).

Fig. 17

The left side shows guidance for selecting the apartment type. Next comes the selected type written vertically, followed by three duct area values for different rooms.

The original tables show that apartment living area determines the duct type, not directly the duct area. Therefore, all duct types are calculated for each apartment, and the appropriate one is selected based on apartment type and living area in the S канала Кухни, S канала С/у-L, and S канала С/у-S Properties.

Let's look at duct area calculation using the Property for type I (S канала I):

IF ( № этажа расположения > Кол-во жилых этажей; "!!!Этажность меньше текущего этажа!!!"; IF ( Кол-во жилых этажей <= 7; "0,067"; IF ( Кол-во жилых этажей <= 13; IF ( Кол-во зон = "1"; "0,133"; IF ( OR( Кол-во зон = "2"; Кол-во зон = "3/4"); IF ( № этажа расположения <= 7; "0,067"; "0,133"); "!Ошибка количества зон!")); IF ( Кол-во жилых этажей <= 21; IF ( Кол-во зон = "1"; "0,222"; IF ( Кол-во зон = "2"; IF ( № этажа расположения <= 13; "0,133"; "0,222"); IF ( Кол-во зон <> "3/4"; "!Ошибка количества зон!"; IF ( № этажа расположения <= 7; "0,067"; IF ( № этажа расположения <= 13; "0,133"; "0,222"))))); IF ( Кол-во жилых этажей > 25; "!Количество этажей больше расчетных 25!"; IF ( Кол-во зон = "1"; "0,267"; IF ( Кол-во зон = "2"; IF ( № этажа расположения <= 13; "0,133"; "0,267"); IF ( Кол-во зон <> "3/4"; "!Ошибка количества зон!"; IF ( № этажа расположения <= 7; "0,067"; IF ( № этажа расположения <= 13; "0,133"; IF ( № этажа расположения <= 19; "0,222" ; "0,267" )))))))))))

First, the formula validates its input: the total floor count must be greater than the apartment's floor number, which is calculated by this formula (№ этажа расположения):

Номер Собственного Этажа — (№ первого жилого этажа — 1)

I subtract one from the first residential floor number because, if apartments begin on the first floor, nothing should be subtracted from their own floor. I chose not to use the Number of Nonresidential Floors parameter: on uneven terrain or in a multi-section building, a section's first floor may correspond to the second floor or even the minus-first level.

The duct-area formula then checks table values according to the number of residential floors and the apartment's floor. With 7 floors or fewer, the minimum duct area is the same throughout the building. At 8–13 floors, either one zone with a uniform area or two area groups (up to floor 7 and above) can be used.

At 14–21 floors, one, two, or three zones are possible. At 22–25 floors, the area can vary across one, two, or four zones. This is why the last possible Number of Zones value is “¾”.

If a building has more than 25 floors, either the value is wrong or the building falls outside the original calculation assumptions and needs additional analysis. The formula includes a warning for this case. Although Number of Zones has only three values (1, 2, and ¾) and is an Option Set, I added a validation check as a precaution.

I try to structure formulas so that the final branches contain as few alternating values and closing parentheses as possible, making them easier to follow. Type II and III duct areas are selected in the same way.

Let's examine selection of a duct type using the kitchen duct (S канала Кухни) as an example:

IF (S жилая = 0; "!!!НЕТ ЖИЛОЙ ПЛОЩАДИ!!!"; IF ( Тип КВ для вентканала = " "; "Выберите тип КВ для вентканала"; IF ( OR (Тип КВ для вентканала = "1"; Тип КВ для вентканала = "3"); IF ( S жилая <= 50; S канала I; S канала III ); IF ( Тип КВ для вентканала = "2"; IF ( S жилая <= 63; S канала I; S канала III ); "!Ошибка типа квартиры!" ) ) ) )

The formula first checks whether the living area was transferred from the marker object to the custom Property. It then validates the apartment type and selects the appropriate value from the source table based on living area and apartment type.

Input data (number of floors and location floor) can be entered for all markers on a floor at once. The script also transfers living area values for every marker in the project. You can then place the prepared labels in a batch for all apartment markers on that floor (Document -> Annotation -> Label Selected Elements) and proceed with duct placement.

My ventilation duct is a group of elements: walls with openings, a Library Element separating the intake channel, a profiled column made of transparent material with high intersection priority, and a Label displaying the S КАНАЛА Property. This Property must be compared with the minimum duct area specified by the HVAC team, to three decimal places.

Rather than constantly changing the display precision of areas, I tried to implement this with formulas. First, I calculate the column area with the decimal separator shifted three places to the right (S канала_черновая) (Fig. 18).

Fig. 18

SPLIT (STRCALCUNIT (Толщина / Диаметр Ядра * Ширина Ядра * 1000)); ","; 1)

Before converting to a string, I use SPLIT to remove the fractional part of the area (the comma and everything after it). I then display the resulting value as a decimal with three digits after the separator, using the fact that ARCHICAD 22 does not remove spaces between digit groups in formulas, as noted earlier:

IF (CONTAINS ( " "; S канала_черновая ); SUBSTITUTE ( S канала_черновая; " "; "," ); CONCAT ( "0,"; S канала_черновая ) )

This formula uses only text-conversion functions. If S канала_черновая has more than three digits, it contains a space, which I replace with a comma; otherwise, I prepend “0,”. This solution is absurd, unscientific, and not universal (for example, it will not work correctly with areas containing more than six digits), but it works and demonstrates that unconventional problems can be solved with flexible thinking.

The result is far from full automation: I have essentially removed the need to consult tables during design and reduced the chance of mistakes when choosing the minimum duct area. Again, I am not claiming the original requirements are entirely correct or encouraging anyone to follow my formulas exactly. I want to show general ways that routine tasks can be automated with careful upfront planning.

Conclusion

Formulas are a major step toward automating model information in ARCHICAD. Tasks previously handled through obscure IFC schema tools (such as combining multiple parameters into a string) are now available directly in Property Manager.

Calculations that used to require exporting data to Excel and processing it there (such as the share of living area in an apartment's total area, or apartment areas on a floor) can now be performed automatically within ARCHICAD and displayed in Labels or Interactive Schedules. Even fire resistance limits for building structures, previously assigned manually, can now be calculated automatically.

Formulas already have a broad range of applications, especially with third-party add-ons. As the tool develops, its possibilities will be limited mainly by users' imagination.

Finally, some readers may feel that these activities have little to do with an architect's traditional work. Yet architecture has always required knowledge of many adjacent disciplines, and programming is simply another one. Like English, programming is an international language of our time. Refusing to learn even its fundamentals is effectively refusing an opportunity for professional development.

“…it takes all the running you can do to stay in the same place. If you want to get somewhere else, you must run twice as fast.”

Lewis Carroll, Through the Looking-Glass

Article author: Egor Zakharov