Designing with Intent: The Vision Behind POST/TABLE

Overview

MIDAS CIVIL NX pursues user-friendly engineering solutions and provides various data in tables.

The “post/table” command is intended to develop and extract various data efficiently and easily. However, it contains a lot of tables, and the user might not fully understand them; I will provide usage details and additional information here. This content focuses on people familiar with CIVIL or CIVIL NX but unfamiliar with APIs.  

Pre-Process Table

The Pre-Process Tables were excluded from development in the Initial planning stage because they are almost the same as the DB data.

For example, nodes can be viewed using the db/node command(API), and the product in the table is similar.

Of course, API data formats and product tables are quite different, and we need some conversion. I will show you a Python example that converts API Response data to a table format.

import pandas as pd

def json_to_dataframe_with_units(data, unit_data):
    """
    Converts JSON data into a Pandas DataFrame and dynamically updates headers with unit information.
    """
    # Extract the main key dynamically (e.g., "NODE")
    main_key = list(data.keys())[0]
    nested_dict = data[main_key]

    # Convert the nested dictionary into a DataFrame
    df = pd.DataFrame.from_dict(nested_dict, orient='index')

    # Set index name dynamically
    df.index.name = main_key

    # Extract unit dictionary dynamically
    unit_main_key = list(unit_data.keys())[0]  # e.g., "UNIT"
    units = unit_data[unit_main_key]["1"]  # Get unit mappings

    # Identify the correct unit for distance-related columns
    dist_unit = units.get("DIST", "").lower()  # Get DIST unit if available

    # Update column names dynamically based on matching keys in unit_data
    df.rename(columns={col: f"{col}({dist_unit})" for col in df.columns}, inplace=True)

    return df

# Example usage
data = {
    "NODE": {
        "1": {"X": 0, "Y": 0, "Z": 0},
        "2": {"X": 1, "Y": 0, "Z": 0},
        "3": {"X": 2, "Y": 0, "Z": 0},
        "4": {"X": 6.25, "Y": 0, "Z": 0},
    }
}

unit_data = {
    "UNIT": {
        "1": {
            "FORCE": "KN",
            "DIST": "M",
            "HEAT": "J",
            "TEMPER": "C"
        }
    }
}

# Convert JSON to DataFrame with dynamic header updates
df_final = json_to_dataframe_with_units(data, unit_data)

# Display updated DataFrame
print(df_final)

# Save as CSV
df_final.to_csv('output.csv')

Some of the Pre-Process Tables were developed when,

 • In the case of non-DB data (i.g, Mass summary)

 • Present DB data but print additional information (i.g, Section, Material)

Based on these rules, we developed 20 tables; you can find the link below.

MIDAS API Online Manual – MIDAS Support

Post-Process Table

Printing the analyzed results is the most crucial function within API commands, and we focused on developing as many functions as possible.

For that, we now provide 147 tables, as below, and we’re still developing the rest.

 • Analysis Result Table (89)

 • Time History Result Table (52)

 • Heat of Hydration Result Table (6)

We tried to maintain user experiences that enabled extracting basic results and accessing advanced functions in the table(Select Tendon, CS, etc.).

JSON Structure

The table command can have various JSON Structures because 147 tables use only one Endpoint, and it is essential to know the structure. The structure can be changed depending on the table, and we provide each table's structure. When you fully understand its structure, you can expand your usability.

For this reason, I will write each "key" notion from this part.

TABLE_NAME

The user can name an arbitrary “TABLE_NAME” and locate it at the top of the Response. It is not an essential key. The Response will print an “empty” message if the user inputs nothing.

TABLE_TYPE

The “TABLE_TYPE” is a significant key for specifying tables. Each table has matched string data(value); the user can find it in the API manual on the support website.

EXPORT_PATH

The “EXPORT_PATH” key can save the Response JSON data. The direction Path and file extension should follow the JSON format.

UNIT

For tables that need units, the user can choose four units. The “UNIT” key has the same structure as “DB/UNIT.” (Reference: Unit System—MIDAS Support) If the user inputs nothing, the API will generate a Response based on the product unit.

STYLES

The “STYLES” key acts like the Style Dialog function(in the product). The user can print in a customized format and decimal when the type is a real number(refer to the figure below). One thing is different: the user can set up each row in the product, but the API sets the whole table.

COMPONENTS

The “Components” is setting print components in the Response. There are basic rules as follows:

 • When omitting the “Components” key or emptying the value([ ]), print all data

 • The “HEAD” key prints the selected columns among the Response JSON keys.

 • The “Index” of “HEAD” is a default value indicating row numbers.

 • When the header has more than a double array, the header name expresses “/” separately.

 • In the case of a double(or higher) array header, the top header is a standard. Even if you specify only one of several, all applicable columns will be printed.

 • Systems of units don’t appear on the header.

This key would be rarely used, so it was not contained in the manual, even if it is an Enum data. I highly recommend creating the minimum input data, requesting the COMPONENTS in the empty status, and copying it from the Response when needed.

NODE_ELEMS

This key is used for tables to select nodes or elements. Over half of the tables use this key; the user can input it as shown below in the product.

To maintain user experience and convenience, the user can use three different formats.

 • “KEYS” → Request specific nodes or elements as an Integer array to print.

 • “TO” → Request range of print nodes or elements.

 • “STRUCTRUE_GROUP_NAME” → Designate structure group to print.

The Response shows all data if a specific node or element is not designated.

LOAD_CASE_NAMES

This key is used when tables need to consider load cases or load combinations. It is one of the essential keys, so over 80% of tables use it. This key indicated data on the product as follows.

Print all available cases if the user doesn’t designate any cases or the value is empty.

The user must obtain the case name through the DB and write the additional string that matches the case in parentheses to create the final string for the load case name.

The challenging part lies in handling Load Combination Cases. If a load combination does not include envelope cases, it can only be output as (CB). However, if envelope cases (e.g., load cases or combinations represented as envelopes) are included, the output must be (CB:all), (CB:max), or (CB:min).

An additional key "bCB" is inserted into the Load Combinations database to distinguish these scenarios. When querying a load combination:

 • “bCB”: false indicates no envelope involvement (CB).

 • “bCB”: true indicates envelope-based combinations (CB:all/max/min).

The product uses the load case names specifically designated for construction stages. Additionally, it can utilize the Dead Load for C.S. specified in the Construction Stage Analysis Control Data (Construction Stage Analysis Control Data - MIDAS Support).

The product's Record Activation Dialog is the most reliable method to verify this. Users familiar with the product should be able to utilize this feature efficiently.

TH_LOAD_CASE_NAMES

This feature is used to query the results of Inelastic Hinges and Fiber Sections during Time History Analysis.

This key has characteristics similar to the LOAD_CASE_NAMES key.

MODES

This is used to query tables related to vibration, bucketing mode shape, or nodal results for RS.

If no specific modes are specified or an empty array is requested, data for all available modes will be output.

PARTS

This feature is used to request table data related to Beam element results.

If not specified or requested with an empty array, data for all available Parts will be output.

SECTION_POSITION

This feature requests table data related to stress results for Beam elements.

If not specified or requested with an empty array, data for all available Section Positions will be output.

Depending on the table types, they have different section positions indicating names, so please be careful. (Checking it in the manual or product)

AVERAGE_NODAL_RESULT

This feature is used for querying result tables for elements of two dimensions or higher, including Plate, Plane Stress, Plane Strain, Axisymmetric, and Solid elements. The default value is False.

NODE_FLAG

This feature queries result tables for Heat of Hydration and elements of two dimensions or higher, including Plate, Plane Stress, Plane Strain, Axisymmetric, and Solid elements. The default value is False.

OPT_CS

This key is used to query result tables for construction stages.

To understand its functionality, let's consider the product's behavior:

1. After analysis, the Model View automatically sets to "POST CS" state.

2. In this state, we can view results from the post-construction stage.

3. Construction stage results are available through Load Combinations, but these represent the final results of the last stage.

To view results for specific construction stages or elements not active in POST CS:

1. The Model View must be set to an arbitrary construction stage.

2. Regardless of which construction stage Model View is selected, results for any desired stage can be obtained.

Thus, all results can be accessed by toggling between POST CS and any construction stage.

Key functionality:

1. It sets the internal state to either the construction or post-construction stages, independent of the visible Model View.

2. When False: The product internally enters "POST CS" state.

3. When True: The product internally switches to the first construction stage state.

4. This change is internal and doesn't affect the product's external appearance.

Usage note:

 • The default value is false.

 • This key must be explicitly set to true to query construction stage results.

This approach allows engineers to analyze structural behavior at various construction stages, which is crucial for planning safe and efficient construction processes.

STAGE_STEP

This feature is activated when OPT_CS is true—input the construction stage name for access. If not specified or requested with an empty array, data for all available Construction Stages will be output.

The construction stage designated name is given automatically based on the Construction Stage setting.

Define Construction Stage - MIDAS Support

Let’s look into this rule. (CIVIL users would be familiar with it.)

There are three kinds of data involved in composing a name.

᛫ NAME
᛫ bSV_STEP
᛫ ADD_STEP

If you create several datasets considering several cases, it would be helpful to understand the naming rule.

“NAME” is essential, and let it be a fixed value; change bSV_STEP and ADD_STEP.

1. In the case of only having NAME

2. In the case of having NAME and vSV_STEP

3. In the case of having NAME and ADD_STEP

4. In the case of having all data

To summarize, “NAME” and “:” are essential components and follow numbers and a string of construction stages. “(last)” is always activated. In front of the number, the total number will be decided by the number of total ADD_STEP, adding 1. If the duration day is 0, “001(last)” is created. When ADD_STEP exists, the stage of ADD_STEP is set as (user i), and the number will be designated 1+i.

DISP_OPT

This key checks the node displacement results in the construction stages. Only two tables use this key.

Displacements - Analysis Result Table - MIDAS Support

ITEM_TO_DISPLAY

It uses tables that can generate a View by Max Value. The accessible items depend on the table type; please check the available keys in the manual or product.

ADDITIONAL

This key controls the data query setting for the tendon-related tables Arrangement, Loss Force/Stress, and Element Properties at Each Stage. The user's request must include this key to access results.

PART

This key is only used when accessing the Beam Section Properties at the Last Stage table. (It is different from the PARTS key, notice it)

It prints all available parts when no components are designated or a request is made with an empty array.

Beam Section Properties at Last Stage - Analysis Result Table - MIDAS Support

FIBER_CELL_MINMAX

This key is only used for the Japanese version to access the Time History result of the Fiber Section.

Fiber Section Maximum Strain of The Cell - TH Result Table - MIDAS Support

SECT_POSITION

This key is only used for the Japanese version to access the Time History result of the Fiber Section.

Fiber Section Maximum Strain of The Cell - TH Result Table - MIDAS Support

Fiber Section Event Step - TH Result Table - MIDAS Support

Fiber Section Average Compression Strain - TH Result Table - MIDAS Support

OUTPUT_STEP

This key is only used for the Japanese version to access the Time History result of the Fiber Section.

Fiber Section Average Compression Strain - TH Result Table - MIDAS Support

Conclusion

As reviewed above, the functionality of POST/TABLE has been designed to reflect the user experience of our product closely.

Of course, providing additional convenience features (e.g., fetching a list of available output cases) is expected to make the system even more accessible. These convenience features are always part of our development plan, and we are committed to delivering them as quickly as possible.