4C Simulation

The basic command to execute 4C is (relative to the build directory)

./4C <input_file> <output_basename>

The input file is commonly a file with the suffix .dat, and it is commonly created by a preprocessing step, which is explained in detail in Preprocessing.

The <output_basename> should not have any suffix. Output generated by 4C consists at least of one file named <output_basename>.control. If further output has been requested, a number of further files are created. The file names are all given in the *.control file.

These results in the output files are by default stored in a proprietary format. However, output data can also be stored in a format that is readable by other programs. For further information, see Postprocessing.

All available options when starting 4C from the command line are shown by an output of ./4C --help:

NAME
	4C - simulate just about anything

SYNOPSIS
	4C [-h | --help] [-p | --parameters] [--to-yaml] [-d | --datfile] [-ngroup=<x>] \ 
		[-glayout=a,b,c,...] [-nptype=<parallelism_type>] \ 
		<dat_name> <output_name> [restart=<y>] [restartfrom=restart_file_name] \ 
		[ <dat_name0> <output_name0> [restart=<y>] [restartfrom=restart_file_name] ... ] \ 
		[--interactive]

DESCRIPTION
	The am besten simulation tool in the world.

OPTIONS
	--help or -h
		Print this message.

	--parameters or -p
		Dumps information about the parameters for consumption by additional tools.

	--to-yaml <in_file_name> [<out_file_name>]
		Rewrites a dat file to a yaml file. (default output: <in_file_name_without_suffix>.4C.yaml

	-ngroup=<x>
		Specify the number of groups for nested parallelism. (default: 1)

	-glayout=<a>,<b>,<c>,...
		Specify the number of processors per group. 
		Argument "-ngroup" is mandatory and must be preceding. 
		(default: equal distribution)

	-nptype=<parallelism_type>
		Available options: "separateDatFiles" and "everyGroupReadDatFile"; 
		Must be set if "-ngroup" > 1.
		"diffgroupx" can be used to compare results from separate but parallel 4C runs; 
		x must be 0 and 1 for the respective run

	<dat_name>
		Name of the input file, including the suffix

	<output_name>
		Prefix of your output files.

	restart=<y>
		Restart the simulation from step <y>. 
		It always refers to the previously defined <dat_name> and <output_name>. 
		(default: 0 or from <dat_name>)
		If y=last_possible, it will restart from the last restart step defined in the control file.

	restartfrom=<restart_file_name>
		Restart the simulation from the files prefixed with <restart_file_name>. 
		(default: <output_name>)

	--interactive
		4C waits at the beginning for keyboard input. 
		Helpful for parallel debugging when attaching to a single job. 
		Must be specified at the end in the command line.

Running examples

In tests/input_files a huge number of test examples are available. For example,

./4C tests/input_files/f2_drivencavity20x20_drt.dat xxx

runs the 2d fluid driven cavity example and writes the output to files beginning with xxx. You can also run the code in parallel with the mpirun command like this:

mpirun -np 1 ./4C tests/input_files/f2_drivencavity20x20_drt.dat xxx

Restarting an analysis

For restarting an analysis one has to provide restart information in the first simulation by including the parameter RESTARTEVERY  <numsteps> in the STRUCTURAL DYNAMICS section, so that the information is written every numsteps step.

In the second simulation, no additional parameters have be included. The information that it is a restart, is given on the command line:

./4C <restart_input_file> <output_basename> [restartfrom=<restart_filename>] restart=<step>

Here, one has to provide the step, at which the restart is started from the previous simulation. If the parameter restartfrom is given, the initial configuration is read from this file, otherwise it is read from <output_basename>. In the latter case the filename of the new output is the same with an appended number, e.g., outfile-1. Note that the value for step must be given in the file <output_basename>.control in one of the step lines: step = <step>.

Note

• The parameters RESTART and RESTARTTIME in the PROBLEM TYPE section are not needed anymore, and will probably vanish soon.

• The parameter MAXTIME indicates the maximum time of all simulations, it is NOT a step time, so be aware that MAXTIME in the subsequent simulation must be larger than in the first one.

• The parameter TIMEINIT can be 0 also in the subsequent simulation, it is not used, since the initial time is defined by the restart.