HyperWorks Solvers

Single Input File Format

Single Input File Format

Previous topic Next topic Expand/collapse all hidden text  

Single Input File Format

Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function  

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.

rad2rad_single_input_flowchart

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.

multidomain_sub

 

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.

multidomain_artificial_skin

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.

multidomain_full

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

Note:If a cross domains contact interface is split, a warning message "multidomain split contact interface" is issued.

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

/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 master 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 type 2 with master elements on one domain and slave nodes the other one, a different strategy is used. This strategy is similar to what is done for the contacts. The master elements are duplicated with void material in the domain containing the slave 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 master elements. If both domains contain slave nodes, the duplication of master 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 slave nodes on two domains, all the missing slave nodes are duplicated on both sides and all the slave 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


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

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 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:

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 listing 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

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.

hmtoggle_plus1SMP script example

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;

hmtoggle_plus1SPMD script example

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 (it will be possible to define several subdomains in a future release).

The following options are not yet compatible with /SUBDOMAIN:

/MODIF (run modification)
/FX_BODY

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