Single Input File Format

Model Setup

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. When using this method there can only be one subdomain but that subdomain can be made of multiple parts.


Figure 1. Subdomain Setup Architecture

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

Automatic Creation of Subdomain

The subdomain is simply defined by a list of parts.

Split Model

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 Current 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.


Figure 2.

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 main domain.


Figure 3.

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.


Figure 4.
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.
Note: If contact interfaces are badly defined, a warning message multidomain interface is too big is issued if the size of the duplicated part is less than 50% of the size of the full model. If this percentage is bigger than 50% an error message is issued.
Furthermore, it is strongly recommended to not have asymmetrically defined cross domain contact interfaces where the subdomain is only defined on either the secondary or the main 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: main and secondary sides of the cross domain contact or correcting already existing asymmetrical contacts by adding a symmetric contact interface).
Note: If a cross domains contact interface is split, a warning message multidomain split contact interface is issued.
Radioss contact interfaces that are compatible with Multi-Domain are:
  • /INTER/TYPE5
  • /INTER/TYPE7
  • /INTER/TYPE10
  • /INTER/TYPE11
  • /INTER/TYPE18
  • /INTER/TYPE24, if (surf_ID1 > 0, surf_ID2 > 0) or (surf_ID1 > 0, surf_ID2 = 0). Not if (grnd_IDs > 0, surf_ID1= 0, surf_ID2 > 0).

User-defined Connections between Domains

Some kinematic conditions can also create connections between domains, if they are defined across the Multi-Domains interface.
  • Rigid bodies: in the case of rigid bodies that connecting two domains, a specific treatment is applied. The rigid body is split in two, and a computation of mass, inertia matrix and position of the center of gravity is performed for each domain. Then, the two mai nodes of the two parts of the rigid body are coupled by RAD2RAD using a formulation similar to the one used for classical node-to-node coupling but adapted to non-spherical inertia.
  • Tied interface: in the case of a tied interface TYPE2 with main elements on one domain and secondary nodes the other one, a different strategy is used. This strategy is similar to what is done for the contacts. The main elements are duplicated with void material in the domain containing the secondary nodes in order to have the tied interface fully defined in this domain. Then, the Multi-Domain coupling is only applied on the nodes of the main elements. If both domains contain secondary nodes, the duplication of main elements is performed on both sides.
  • Rigid Links, RBE3 and Cylindrical Joints: the same idea is applied to rigid link and RBE3. If one of these options has secondary nodes on two domains, all the missing secondary nodes are duplicated on both sides and all the secondary nodes are coupled by the RAD2RAD. The option is then computed on both sides.
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:
  • /MPC
  • /RBE2
  • /GJOINT

Data Input

Starter Input File

The sub-domains are specified by parts.
/SUBDOMAIN/subdomain_ID
subdomain_title
Part1    Part2     ...      Partn
Where,
Partn
Identifier of the parts that belong to the subdomain
subdomain_ID
Domain identifier
subdomain_title
Subdomain name (that will be the rootname of one Engine file)

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 "_model_rootname"_0000.r2r.
Note: For more information concerning the RAD2RAD input file, refer to the online documentation of Multi-Domains.

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 frequency for the printout of the TH file is defined by the main 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.

Output File

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

There are two exceptions:
  • Energy error: The energy balance is computed in each domain independently from the other domain. It means that for each domain, the Multi-Domain coupling forces are considered as external forces and their work is added to the work of the external forces. This work is only used internally for the energy balance computation. It is not included in the value of the work of the external forces printed in the output file or in the time history.
  • Mass change: The mass change is also computed locally, meaning that it is the ratio of the added mass in the selected domain over the mass of this domain.

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 File

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 Engine and RAD2RAD processes.

Launch a Multi-Domain Analysis

There are two ways to launch a Multi-Domain computation: using the Altair Compute Console or manually.

  1. The easiest way to launch a Multi-Domain computation is to use the Altair Compute Console.
    1. Select the multi-domain Starter file as the input file and define the number of cores to be used in the simulation.
      The Compute Console will then run the Starter, Engine, and the RAD2RAD process. Refer to Altair Compute Console (ACC) for more details about using the Altair Compute Console with Radioss.
  2. To launch a Multi-Domain computation, use the command line to browse to the working directory containing the input files.
  3. Launch the Starter in a terminal using the command:
    Option
    Description
    Linux
    <install_dir>/hwsolvers/bin/linux64/starter_version -i "rootname"_0000.rad
    Windows
    <install_dir>\hwsolvers\bin\win64\starter_version -i "rootname"_0000.rad
  4. Launch RAD2RAD in a terminal using the command:
    Option
    Description
    Linux
    <install_dir>/hwsolvers/bin/linux64/r2r_version "rootname"_0000.r2r
    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.
  5. Launch Engine for each domain in separate terminals.
    Option
    Description
    Linux
    <install_dir>/hwsolvers/bin/linux64/engine_version -i "rootname"_0001.rad
    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.
  6. Launch an SMP manual script. 
    Linux : run_linux_SMD
./s_<version>_linux64 -i FULL_0000.rad

./e_<version>_linux64 -nt 4 -i FULL_0001.rad > out_1 &
./e_<version>_linux64 -nt 4 -i SUBDOM_0001.rad > out_2 &
./r2r_<version>_linux64 -nt 4 FULL_0000.r2r
    Windows : run_win_SMD.bat
E:\Rad2rad\s_<version>_win64.exe -i FULL_0000.rad

set KMP_STACKSIZE=64M
start /B E:\Rad2rad\e_<version>_win64.exe -nt 4 -i FULL_0001.rad > out1
start /B E:\Rad2rad\e_<version>_win64.exe -nt 4 -i SUBDOM_0001.rad > out2
start /B E:\Rad2rad\r2r_<version>_win64.exe -nt 4 FULL_0000.r2r
    Windows (cygwin) : run_win_SMD
./s_<version>_win64.exe -i FULL_0000.rad;

./e_<version>_win64.exe -nt 4 -i FULL_0001.rad > out1&
./e_<version>_win64.exe -nt 4 -i SUBDOM_0001.rad > out2&
./r2r_<version>_win64.exe -nt 4 FULL_0000.r2r;
  7. Launch an SPMD manual script. 
    Linux : run_linux_SPMD
./s_<version>_linux64 -np 4 -i FULL_0000.rad

mpiexec -n 4 ./e_<version>_linux64_impi -i FULL_0001.rad > out_1 &
mpiexec -n 4 ./e_<version>_linux64_impi -i SUBDOM_0001.rad > out_2 &
mpiexec -n 4 ./r2r_<version>_linux64_impi FULL_0000.r2r
    Windows : run_win_SPMD.bat
E:\Rad2rad\s_12_main_win64.exe -np 4 -i FULL_0000.rad

set KMP_STACKSIZE=64M
start /B mpiexec -n 4 E:\Rad2rad\e_<version>_win64_impi.exe -i FULL_0001.rad> out1
start /B mpiexec -n 4 E:\Rad2rad\e_<version>_win64_impi.exe -i SUBDOM_0001.rad> out2
start /B mpiexec -n 4 E:\Rad2rad\r2r_<version>_win64_impi.exe FULL_0000.r2r
    Windows (cygwin) : run_win_SPMD
./s_<version>_win64.exe -np 4 -i FULL_0000.rad;

mpiexec -n 4 ./e_<version>_win64_impi.exe -i FULL_0001.rad > out1&
mpiexec -n 4 ./e_<version>_win64 impi.exe -i SUBDOM_0001.rad > out2&
mpiexec -n 4 ./r2r_<version>_win64 impi.exe FULL_0000.r2r;

Current Limitations

Only one subdomain can be defined.

These options are not compatible with /SUBDOMAIN:
  • /DFS/DETPOINT/NODE
  • /FX_BODY
  • /SPHBCS
The following connections can only be used inside one domain, but cannot be used in the coupling zone or across the Multi-Domain interface.
  • /GJOINT
  • /MPC
  • /RBE2

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 TYPE1.

The GAUGE, INTER and RWAL type sensors 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.