Material/fr

Overview

This page is about the Material data system in FreeCAD.

It is currently being edited to reflect changes to the Material system currently under development.

Abstract

In a departure from how it was implemented in previous versions, materials are no longer implemented as a simple dictionary. The previous system had the advantage of simplicity, with the disadvantage of a limited range when describing material properties.

In the new system, properties are defined separately as a series of YAML files. Properties are then combined into a property description with values specified for the required properties. Newer data types, such as arrays, mean that this can no longer be accessed using simple dictionaries. Rather, an API is used to access the material property and data values. This allows for greater capabilities than previously possible.

Tools

There are some good resources out there to handle materials more easily:

• Units calculator to get your material information in the units needed for FreeCAD
• http://www.matweb.com/ free of charge Material database with thousands of material values
• UUID generator to create unique UUIDs for new models. A Version 4 UUID is recommended.

Properties

In contrast with the previous materials standard, material properties are clearly defined. They have been designed to be granular and extensible. Properties can inherit multiple properties, adding only what is different. This will improve searching and simplify implementation.

Currently, there is no dedicated property editor. It can be edited using any YAML tool, or a simple editor such as nano or Notepad.

The property definition files are referred to as models.

Example Property Model YAML file

Rather than a large monolithic definition file, properties are granular, typically focused on a specific task. Models fall into two basic categories:

• Physical models: identified by the keyword 'Model' as shown here, these define physical properties of the material
• Appearance models: identified by the keyword 'AppearanceModel', these define how the material will be displayed.

Each model has a unique identifier, or UUID, that is used to reference it internally. Consistency of this UUID is important as changing it for one document can also affect other documents. As a general rule, additions to the definition don't require an identifier change, as they can still be used in other documents, but value changes would require a new UUID.

An optional URL can link to a detailed description of the material property being described. Given that this is a description of the property and not the material itself, it should be pretty generic at this point. A shorter description, typically one or two lines, can be included in the model description as well.

Each material can also include a DOI (Digital Object Identifier) that links through https://www.doi.org/ to a research publication or similar item of interest.

Inheritance

Inheritance is a new capability. There are two principal use cases.

One use case is to provide the ability to tweak models without breaking other documents. For example, in cases where a property type is different, you can define a derived property model that only changes that specific property without breaking any existing documents that reference it.

A second use case is to group properties in a searchable fashion. For example, all physical objects have density, and in many cases, that will be all the information available for that material. In cases where linear elasticity properties are available, we would want to include those as well. In yet another example where the elasticity is different in different directions, such as wood, we can define yet another model that is derived from density. Information is not duplicated across the 3 property models. Additionally, we can do a search for materials that have the density property and return all three models.

The example shown above inherits from two other property definitions. It does this by specifying the 'Inherits' keyword followed by a list of the model names and identifiers. If there is no inheritance, this section may be omitted.

Properties

Properties are defined by providing the name of the property, followed by a series of descriptors. The 'Type' descriptor is always required. The remaining descriptors are only required to complete the Type information. The URL and description are optional but recommended where possible.

Property Types

Lists

There are three list types: 'List', 'FileList', and 'ImageList'. In reality, all three are the same except that they use different editors. For the 'FileList', each entry has a file chooser. Similarly, the 'ImageList' opens the image editor. 'ImageList' is different in that it is a very large string representation of an image and may produce extremely large material card files. Use with caution.

2D Arrays

Arrays have some unique properties compared to other property types. Each of the array columns needs to be described, necessitating the addition of the 'Columns' property. The columns property is then a list of properties describing each column.

2D arrays have a minimum of 2 columns and only support the 'Quantity' property type. This may be expanded to other property types in the future.

Values in the array are specified by providing a value from the first column.

3D Arrays

3D arrays are similar in implementation to 2D arrays described in the previous sections. There is a 'Columns' keyword followed by a list of properties to describe the columns. The first column describes the depth or 3rd dimension of the array, with the remaining columns describing the remaining columns. This can be thought of as an indexed list of 2-dimensional arrays.

Since a 2-dimensional array requires a minimum of 2 dimensions, this will require a minimum of 3 columns.

Values in the array are accessed by first specifying the depth, then the value from the first column of the 2D array (the second column here).

A note about arrays

These are a new feature, not previously available. Many capabilities may be added in the future that aren't currently implemented. For example, arrays with columns of strings are potentially useful but not currently implemented.

Interpolation is an important feature that isn't currently implemented. For example, an array with row entry values of 1 and 2 will only return exact matches. So a lookup of 1.5 will return an error. In the future, the arrays will determine an approximate value by interpolating from available data.

Material Database

Given that the above standard is implemented, it wouldn't make sense to store all the properties again and again to objects. Basically, we can build up a Material database with the Name as a primary key. So if you have no special needs for your material, you just define e.g. Name=Steel, and FreeCAD can retrieve all properties from that DB. Every additional property you set in the map overrides the one from the DB.

In the future, we can host that database somewhere on the Web and build up a general open-source material database.

At the moment, I think of a database compiled in a mini dataset with a set of "basic" materials and its basic properties, and a SQLite-based full version.

Material.py

Since handling material properties is tedious work, we should implement a Python front-end module called Material.py [source]. This will be the place to implement all kinds of helper methods for material handling.

• Calculation of mass out of volume and density
• Translation in different unit systems
• Calculation needed in a special application (such as FEM)
• And anything else we don't know yet

The module should be implemented in such a way that it can run in FreeCAD or stand alone on the command line (material-property-map has to be given as a Python map).

The FreeCAD material card file format

Working with materials often involves importing/exporting material definitions. Therefore, a file format is needed. Since we have only a key/value form, we can use a simple and easy-to-read to read and parse file format. Therefore, the ini-file format is chosen. It's standardized, and there are already parsers available. For example, the Config parser module in Python.

Each material definition resides in a file with the ending .FCMat. Some of these files are part of the FreeCAD source and get compiled into the binary. This is to save overhead in distribution and access. But also, files can be placed and searched in different places to allow additional non-standard material definitions.

Example .FCMat file

Material properties

Here's the description of the agreed material properties. Feel free to add a subsection for the material properties of your field of expertise.

General

ToDos: add some properties with an ordering system for materials (metal, alloy, mineral, wood, ...)

Mechanical

ToDos: add further properties needed for mechanical design.

Graphical

This section defines material properties that are related to the visual appearance of the material.

Thermal

Architecture and BIM

TODO

• add sustainability & LEED properties