Frequently Asked Questions

romAI is a no-code application used for Reduced-Order Modeling and System Identification. It is made by a GUI (romAI Director) used for the generation and a block (romAI block) used for the deployment.

A ROM is an efficient model that can represent a static or a dynamic system. It is obtained by data generated by high-fidelity models. Although high-fidelity models compute all possible information, ROMs (Reduced Order Models) calculate only the needed ones with sufficient accuracy. For this reason, they run much faster than the high-fidelity models from which they are generated. ROMs generated by romAI are real-time compliant.

System Identification is a technique that starting from test data produced by a physical system or process try to identify a model able to reproduce its behavior.

Yes, even though it is a no-code application, it is optionally possible to run it in batch mode.

Yes, romAI processes data regardless of its nature.

romAI models can be used in digital twin applications, in real-time simulators, to speed-up optimization analysis.

Yes, romAI can be exported as FMU (Functional Mock-Up Unit) or DLL.

Yes, romAI can model either static or dynamic systems. In the latter case, state variables must be defined and the time label available in the dataset.

Yes, romAI can handle linear or non-linear systems. The option is explicitly provided in the GUI.

In a static model, the outputs depend only on its inputs. In a dynamic model, the outputs depend on its inputs and its state variables.

No, romAI cannot reproduce the field results. romAI is used for reduced-order modeling at a system level creating highly efficient real-time compliant models.

Yes, as far as you can parametrize the geometry of the system with simple variables such as: length, width etc. It can¬not be used for topology optimization.

Yes, romAI can be used to optimize the operational conditions of a system or process such as: flow rate, forces, orientation, velocity, power, etc.

Models produced with romAI usually have an accuracy of about 98% if compared with high-fidelity models or test data.

It is convenient when you deal with computationally expensive simulations or test data and the traditional equation-based approach used for reduced-order modeling or system identification cannot provide the needed accuracy.

Your training set must cover as much as possible the domain of variations of the inputs to romAI.

For dynamic systems, it is important to sample the signals with a proper frequency bearing in mind the Nyquist-Shan non sampling theorem. You do not need to sample the signals with a fixed sampling frequency, but you can sample with a higher frequency when the signals show a higher variation in time.

When you use romAI, you are performing system identification regardless if data is coming from simulation or test. For this reason, stepwise, sine-sweep, sine functions are usually employed as they enable the excitation of the eigenfrequencies of the system and so a good characterization of its transient behavior.

When dealing with a static model, romAI works as a classical feed-forward neural network.

Nevertheless, most of the settings are already optimized and you do not need to write or know any code. You just need to compile few settings in the GUI. Indeed, romAI democratizes access to artificial intelligence. romAI is particularly suited for non-linear applications where with a standard regression model it is not possible to reach the needed accuracy.

When instead the equations of the system under study are known, it is convenient to follow the classical approach.

Yes, when dealing with a linear model. When dealing with a non-linear system it depends by the application. If beyond the training domain the behavior is “similar,” romAI can provide a good approximation. If instead there are other non-linear effects not caught in the training set, romAI will provide wrong estimations.

The best way to check the accuracy of romAI is to check the Accuracy Check plot where the R2 index of targets versus predictions is calculated.

If your loss function did not reach the flat region, you should increase the number of epochs. If it reached the flat region but the accuracy is bad, you can increase the number of hidden-layers and/or the number of neurons in each hidden layer.

Nevertheless, consider that typically two or three hidden layers are enough.

You can append the new data to the former dataset and train romAI again. Since you will have already a romAI, it means that you have already identified a good set of hyper-parameters (number of neuros in each hidden layers, epochs etc.) hence the suggestion is to start from these settings.

Yes, in this case inputs and outputs must be formulated considering the frequency domain (e.g., input is a frequency value, output can be the amplitude and the phase at that specific frequency) and we will deal with a static model.

There is no rule. Nevertheless, it is a technology dedicated for reduced order modeling at a system level hence usually we deal with dozens of inputs and dozens of output at most. When dealing with dynamic systems, if linear, we have successfully tested romAI with problems with more than 20 state variables. When dealing with non-linear systems instead, usually romAI cannot handle problems with more than three state variables. This is because dynamic systems have memory and even a small error in the approximation is integrated in time and causes the divergence of the solution.

Yes, with static problems. With dynamic problems, you also need to check the time simulation plot.

Yes, romAI can be used to generate models on both platforms and the trained models can be executed on both too.

No, romAI can be used to generate dynamic models even from data available with a variable sampling frequency.

Yes, romAI generates real-time compliant models and we can also perform code-generation for them.

Yes, even though the output will be continuous. Nevertheless, if needed, you can round the outputs using a Twin Activate block.

Absolutely not. This is already handled by the application when defining the state variables.

If you have noise in your data that is corrupting the trend that you need to approximate, then it is better to filter it out. This is possible only with data related to time-histories as time variable must be present.