Modeling Process

---

A multiple input format setup was first introduced in RADIOSS Multi-Domain technique. The main drawback of this setup is that it implies a lot of work for the user who has to manually build several independent input files. It can be very long, difficult and the source of mistakes in the case of small domains extracted from very large and complex models.

The purpose of the single input file setup is to simplify the task of the user by building subdomains automatically. Only one Starter input file is required that includes the entire model, like a classic computation. Only the parts of the model to place in subdomains have to be specified. Then, the Starter automatically extracts the specified domains from the full model and generates one restart file for each domain.

Architecture of the subdomain setup

Currently, only one domain can be specified, but this limitation can be extended in the future.

Automatic Creation of the Subdomain

---

Definition

The subdomain is simply defined by a list of parts.

Model Splitting

The first step of the creation of a subdomain is the splitting of the full model. This is achieved by launching one Starter child process per domain. Each process only keeps the part associated to it and the corresponding nodes and elements. Entity groups, such as /GRNOD, /GRPART or /SURF are split as well, allowing a split of a lot of options (if an option refers to nothing in one domain it is suppressed). Some options are more complex to split and need a specific treatment which often implies a modification of the domain definition. Some other options can not be split. For more information about options incompatible with Multi-Domains, refer to Limitations.

As a result, a subdomain is most of the time composed of the parts specified by the user (with their related nodes and elements) and also by some other elements or nodes that are automatically added because of the split of some options.

Connections between Domains

The second step is the detection of the interactions between domains. The first type of interaction is the direct connection. The Starter automatically detects the common nodes between domains and creates Node-to-Node connections.

 

Contact between Domains

The second type of interaction between domains is the contact. The computation of contact forces between domains is based on the artificial skin method. It means that the contacts are not computed by the external program RAD2RAD but inside one of the two domains called master domain.

With the single input file setup the contacts between domains are always computed in the subdomain mainly because the quality of the coupling is far better when the contact is treated in the domain with the smallest time step.

Therefore, the surfaces of the main domain concerned by the contact with a subdomain are automatically duplicated in this subdomain with a void material having the same density and Young’s modulus. A cross-domain node-to-node coupling is then established between the nodes of the artificial skin in the subdomain and the ones of the original surface in the main domain.

This implies that in order to get good performances, all the contacts between main and sub-domain must be put in specific contact interfaces with as small as possible contact surfaces but without missing potential contacts. For example, if only one self-contact interface is used in a model with one sub-domain, the subdomain can potentially impact every parts of the main domain, then, the main domain will be fully duplicated with void material inside the sub-domain. The cost of the RAD2RAD will be huge and the performances very poor.

Furthermore, it is strongly recommended to not have asymmetrically defined cross domain contact interfaces where the subdomain is only defined on either the slave or the master side of the interface. In this case, only a portion of the contact interface is computed in the subdomain, what remains being computed in the main domain. In order to avoid asymmetrical contact interfaces it is recommended to systematically symmetrize the cross domain contact interfaces (by defining the subdomain in both: master and slave sides of the cross domain contact or correcting already existing asymmetrical contacts by adding a symmetric contact interface).

The following RADIOSS contact interfaces are compatible with Multi-Domain:

User-defined Connections between Domains

Some kinematic conditions can also create connections between domains, if they are defined across the Multi-Domains interface.

Other connection types cannot be split. It means that these connections can only be used inside one domain and away from the coupling zone. These options are:

 

Data Input

---

RADIOSS Starter Input File

The sub-domains are specified by parts.

/SUBDOMAIN/subdomain_ID

subdomain_title

 Part1    Part2  ...  Partn

Where, Partn is the identifier of the parts that belong to the subdomain, subdomain_ID is the domain identifier, and subdomain_title is the subdomain name (that will be the rootname of one Engine file).

 

RADIOSS Engine Input File

One Engine input file is required for each domain and in order to activate the coupling, these files must contain the following directive:

/RAD2RAD/ON

One Engine file name comes from the Starter input file rootname: "full_model_rootname”_0001.rad and the other Engine input file name relating to the subdomain comes from the subdomain_title: subdomain_title_0001.rad given to the /SUBDOMAIN card in the Starter input file.

 

RAD2RAD Input File

The RAD2RAD input file is a text file defining some additional information required by the RAD2RAD program. With the sub-domain setup the RAD2RAD input file is automatically generated by the Starter. One can access it and modify it in order to change the parameters of the Multi-Domain computation before launching the RAD2RAD and Engine processes. The name of this file is based on the full model rootname: “full_model_rootname”_0000.r2r

Data Output

---

Starter Output Files

Separate Starter output files are generated for each domain.

Time History Files

A single Time History file is generated containing all information from both domains. This file has the same rootname as the Starter input file. This file content is equivalent to what is obtained following a classical monodomain computation.

All parameters for Time History output (type of time history, output frequency, format, and so on) must be specified in the Engine file of the main domain. If the parameters for time history are defined in the sub-domain Engine input file, they will be ignored.

As the frequemcy for the printout of the TH file is defined by the mai domain, the minimum time interval allowed between two prints of a TH file is the time step of the main domain. For better accuracy, it is recommended to use a time frequency that is much higher than the time step of the main domain.

ABF Files

One ABF file is generated by each RADIOSS Engine. Therefore, to plot the whole model global variables, each domain’s global variable of must be added up.

Listing File

Global variables of the whole model can be computed by simply summing up the global variables printed in the listing file of each domain (each Engine output).

There are two exceptions:

Animation Files

A set of animation files is generated by each Engine. With HyperView it is possible to visualize the two domains simultaneously by simply making an overlay.

RAD2RAD Output

The output file rad2rad.out is generated by the RAD2RAD executable. This file contains useful information about the connections between domains (number of common nodes, type of coupling, and so on).

 

SPEEDUP Estimation

---

As of version 14.0, an estimation of the speedup is computed in the Starter in order to determine the potential efficiency of the multi-domains method. The value is printed in the Starter output file of the main domain. So, if during the computation the time steps change drastically in one domain, the speedup estimation will be irrelevant.

Time step control options defined in the Engine input file (/DT/NODA/CST, /DTIX, …) accounted for in the time step estimations in the Starter.

 

CPU Allocation

---

The RADIOSS domains are treated sequentially, which means that only one RADIOSS process is run at a time. The total CPU resource is automatically allocated to the running process and the others are put in a no CPU consuming waiting mode. With the subdomain setup, the same number of SPMD domains is automatically allocated to all domains. For better performances, the same number of SMP threads per SPMD domain should be used for each domain when running in Hybrid-MPP.

As of version 12.0.210, the RAD2RAD executable is fully parallelized. It means that RAD2RAD must be launched exactly like the Engine executables (same mpi options) and that the same number of SPMD domains must be used for both Engines and RAD2RAD processes.

 

How to Launch a Multi-Domain Analysis

---

There are two ways to launch a Multi-Domain computation: manually and through a script.

Manual Method

To launch a Multi-Domain computation, use the command line to browse to the working directory containing the input files.

Launch the Starter in a terminal using the command:

In UNIX: <install_dir>/hwsolvers/bin/linux64/starter_version -i “rootname”_0000.rad

In Windows: <install_dir>\hwsolvers\bin\win64\starter_version -i “rootname”_0000.rad

Then launch RAD2RAD in a terminal using the command:

In UNIX: <install_dir>/hwsolvers/bin/linux64/r2r_version “rootname”_0000.r2r

In Windows: <install_dir>\hwsolvers\bin\win64\r2r_version “rootname”_0000.r2r

RAD2RAD will then wait for RADIOSS connections from the individual domains.

Note: The file “rootname”_0000.r2r is automatically created by the Starter.

Launch Engine for each domain in separate terminals, as follows:

In UNIX: <install_dir>/hwsolvers/bin/linux64/engine_version -i “rootname”_0001.rad

In Windows: <install_dir>\hwsolvers\bin\win64\engine_version -i “rootname_of_the_subdomain”_0001.rad

All the RADIOSS processes will then connect automatically to RAD2RAD.

By Script

An easier way to launch a Multi-Domain computation is to use a script.

 

Current Limitations

---

Only one subdomain can be defined (it will be possible to define several subdomains in a future release).

The following options are not yet compatible with /SUBDOMAIN:

The following connections can only be used inside one domain, but cannot be used in the coupling zone or across the Multi-Domain interface.

Multi-Domain is incompatible with all kinematic conditions based on Lagrange multipliers, due to incompatibility with the coupling formulation.

Multi-Domain is not yet compatible with AMS (Advanced Mass Scaling), Rayleigh Damping (/DAMP), Dynamic Relaxation (/DYREL), unless nodes are not part of the cross-domain interface or contact, interfaces type 1.

The sensors of type GAUGE, INTER and RWAL are not yet synchronized between domains. Meaning that if a sensor and all its associated features are not confined in one domain, the behavior of this sensor may be incorrect. Nevertheless, sensors of type DIST, ACCE and TIME are fully compatible with Multi-Domain and synchronized between domains.