Frequently Asked Questions (FAQs)
What data types do you support?
How much data do I need?
- 10 designs or test results: All you want to do, is to make sure that the next engineer you hire has access to the previous design files and information you gathered to get up to speed faster. This can be work with 3 data points or designs. To give a simple example: let's say an aerodynamicist just joined a racing company and needs to design a spoiler for a new car. The first step they will do is to have a look at the last 3 cars the company to learn from them. You can make this search and learn process a lot easier if you save the data in interactive 3D + functional data dashboards than by going through old folders. You can also solve it by creating 3 very neat folders and making sure the data in them is structured neatly so that people can compare future cars, so no need to use AI here.
- 50 designs or test results: You want to use insights from product testing or development to help your engineers make better decisions faster. You have noticed that there is considerable repetition, and from the last 50 projects you have done you can learn quite a few things using algorithmic methods. You can detect correlations, you look at failure scenarios, you can build simple models to make recommendations of what to test next. At this data level, algorithms can be a nice extension of the engineering expertise you already have.
- 150 designs or test results: You can make build an AI model to predict the result of tests or physical simulations. For example, you could predict the performance of a rim in a wind tunnel test, predict the maximum stress in a suspension system, etc. The prediction results will be not great if the problem is hard, and mostly we see people use AI at this data level for faster decision-making at the pre-design stage and they build models based on their own test data that is not biased by simplifying physical assumptions.
- 250 designs or test results: You can build recommender systems that can deliver really useful insights into what other solutions you could try. You can run targeted optimisation codes that tell you how to design things differently. This is the typical size of 'design of experiment' for optimisation studies based on CAE models, so we tend to get a lot of those at this data level.
- 500 designs or test results: You can build AI models that can predict the outcome of repetitive processes with good accuracy - sometimes as good as or even better than simplified physical simulations. This tends to be really beneficial for companies as they end up saving a lot of time and money on performing tests or running simulation if they can prove the use of an AI model for this scenario.
- 1000 designs or test results: You can build fully automated workflows. This is every engineering CIO or CTOs dream. Imagine this: a customer provides your team with their requirements, and you enter them into an online form where an AI algorithm will go into your PDM system and create a new product or component for these requirements fully automatically. I have seen this work for repetitive components like sealing solutions, pumps, bearings etc. so in general for suppliers who create many 1000 versions of the same component every year.
3D vs Tabular data, which one works best?
Both 3D and tabular data can be useful for AI depending on the specific task and the nature of the data. 3D data is typically used in generative design tasks on Monolith, where the input data consists of geometry information.
Tabular data, on the other hand, consists of data arranged in rows and columns, similar to a spreadsheet. This type of data is commonly used in machine learning tasks such as predictive modelling and classification, where the goal is to predict a target variable based on a set of input features.
In these tasks, various machine learning algorithms such as decision trees, random forests, and neural networks can be used to analyze and learn from the tabular data. In summary, the choice between using 3D or tabular data depends on the nature of the task and the type of data available.
Example where we worked with both file types: Kautex Use Case
Numerical vs categorical data?
The type of data used in an AI task depends on the nature of the problem and the type of model being used. For example, numerical data is often used in regression tasks, where the goal is to predict a continuous output variable based on input features. In this case, algorithms such as linear regression or neural networks are used to analyse and learn from the numerical data.
Categorical data, on the other hand, is often used in classification tasks, where the goal is to predict a categorical output variable based on input features. In this case, algorithms such as decision trees, random forests, or support vector machines are used to analyse and learn from the categorical data.
It is also possible to convert categorical data to numerical data using techniques such as one-hot encoding, where each category is represented as a binary value. This allows categorical data to be used in algorithms that require numerical input.
In summary, both numerical and categorical data have their uses in AI, and the choice of data type depends on the nature of the problem and the type of model being used.
Is there a limit to how much data I can import?
We can't give a concrete number - 3D data will depend on mesh sizes. Tabular will depend on models you want to train, number of rows vs number of columns etc.
We can always refer the prospect to the Software team.
In general: We do not stop users from uploading data!
Which platforms do we interact with (API’s)?
The Monolith API is a RESTful interface that can be provided to customers to allow them to automate their workflow. Some customers are currently using it to provide third party access to Monolith models, but it’s flexible and can be used for many applications.
An example is collecting test data in a SQL database. This database is not directly accessible but a customer built a Web interface which provides tools for users to filter their data and the query is built and sent to the database in the background. Currently they download the data from this web interface to their machine to upload the data to Monolith platform. One could technically add a web interface which sends the data retrieved from the database to the Monolith S3 bucket via API call.
Our current user is a consumer of this web interface. Therefore he needs to submit a request for change. To present the IT guys a proof we would like to start with an API push to our AWS storage from CLI so that he has a prototype to demonstrate.
Is there an installation process, if yes, how does that work?
We will provide access to the Monolith platform for your users. Monolith will be hosted in the environment agreed in the contract that best secures your data and enables the tool to be accessible for the engineers and easily integrated into your workflow. IT teams from Monolith AI and yourselves will need to be involved from the beginning of the project to ensure that your security needs are identified and addressed quickly and to sufficiently scope your storage requirements and cloud or on premise configuration to enable a smooth and speedy installation.
For a dedicated installation guidance, feel free to contact our experts.
Data ownership – who owns the data after being imported into the platform?
Data is and will always be 100% yours! The same goes for your IP.
You are always able to give our team access to set up or debug notebooks.
How do we know if the case study is feasible?
The 3 critical Feasibility milestones are:
Understand the Customer: We assess our customers’ existing workflows, processes and programmes, as well as the availability and quality of engineering data for AI modelling.
Establish the Value: We identify our customers’ pain points with their status quo and scope our solution to resolve these pain points and provide quantified business value to the organisation.
Present a Proposal: We present a project proposal to the stakeholders within our customers’ organisation and communicate the benefits and ROI that they can gain by partnering with Monolith to adopt AI in their engineering to test less and learn more.
The Monolith team will support you with the following points.
Define the problem: We will start by defining the problem statement clearly. What is the business problem that you are trying to solve? What are the goals of the project, and how will you measure success? It is essential to have a clear understanding of the problem before moving forward.
Gather and evaluate data: Collect data that is relevant to the problem at hand. The quality and quantity of the data are critical factors in determining feasibility. Evaluate the data to ensure that it is representative of the problem, and that it is accurate, complete, and consistent.
Determine the AI approach: Based on the problem definition and data, determine the most appropriate AI approach to use. For example, if the problem involves classification, then a decision tree or a neural network may be appropriate. If the problem involves forecasting, then time-series analysis or regression techniques may be more suitable.
Assess technical feasibility: Once the AI approach has been identified, assess the technical feasibility of the solution. Are there any technical constraints that need to be addressed?
Evaluate economic feasibility: Evaluate the economic feasibility of the solution. Estimate the costs of implementing the AI solution, including data acquisition and processing, hardware and software costs, and ongoing maintenance and support. Assess the potential benefits and return on investment (ROI) of the solution.
Test the solution: Test the AI solution to determine if it meets the defined objectives and requirements. Evaluate the accuracy and performance of the solution using appropriate metrics.
Use AI to predict fuel-sloshing noise, solve intractable physics
- Problem: Vehicle acoustics
- Methods tried: CFD, physics-based simulation
- Solution: Predict noise, reduce testing with self-learning models
"Using Monolith AI platform, we were able to import our rich test stand data and apply machine learning models to conclude on different development options much faster. "
Dr. Bas Kastelein, Sr. Director of Product Innovation, Honeywell Process Solutions
No code software
AI built by engineers for engineers
- Avoid wasted tests due to faulty data
- Build just the right test plan - no more, no less
- Understand what drives product performance and failure
- Calibrate non-linear systems for any condition