MainV5.xml¶
mainV5.xml is the main input file needed to define the test case. It must be in the current test case folder. Its minimal structure is:
<?xml version = "1.0" encoding = "UTF-8" standalone = "yes"?>
<computationParam>
<run>example</run>
<outputMode format="XML" binary="false" precision="10"/>
<timeControlMode iterations="false">
<iterations number="3" iterFreq="1"/>
<physicalTime totalTime="8.e-3" timeFreq="8.e-4"/>
</timeControlMode>
<computationControl CFL="0.8"/>
</computationParam>
It contains general parameters for the computation listed below. Some are mandatory, others are optional.
Run name¶
<run>example</run>
The <run> markup is mandatory. It will be used to create the folder containing the test-case results in ECOGEN/results/.
Output format¶
<outputMode format="XML" binary="false" precision="10"/>
The <outputMode> markup is mandatory. The user can choose the writing output format. Attributes are:
format: Can take the value GNU (standard writing in column) or XML (XML VTK format).binary: Can take the value true or false. Binary (true) or ASCII (false) format can be chosen.
Output result files will be placed in the folder ECOGEN/results/ into a specific subfolder bearing the name of the run.
Time evolution control¶
<timeControlMode iterations="false">
<iterations number="3" iterFreq="1"/>
<physicalTime totalTime="8.e-3" timeFreq="8.e-4"/>
</timeControlMode>
ECOGEN is a CFD tool based on an explicit integration scheme in time. The <timeControlMode> markup is mandatory and defines the temporal evolution of the current simulation. It contains the
iterations attribute that can take the two values:
true: The time control is done thanks to the total number of timesteps and the
<iterations>node must be present.false: The time control is done thanks to the final physical time and the
<physicalTime>node must be present.
The <iterations> markup:
<iterations number="3" iterFreq="1"/>
ECOGEN automatically computes the timestep value thanks to a numerical stability criterion (CFL criterion). This markup is defined with following attributes:
number: Integer equal to the total number of temporal timesteps.iterFreq: Integer equal to the writing frequency of the results (results are written everyiterFreqtimestep)
The <physicalTime> markup:
<physicalTime totalTime="8.e-3" timeFreq="8.e-4"/>
If this markup is used, ECOGEN automatically determines the total amount of timestep to compute to reach the chosen physical time. Attributes are:
totalTime: Real number equal to the final physical time of the simulation (unit: s (SI)).timeFreq: Real number equal to the writing frequency of the results (results are written everytimeFreqseconds).
CFL criterion¶
<computationControl CFL="0.8"/>
The <computationControl> markup is mandatory. It specifies the value of the attribute CFL which ensures the stability of the temporal integration scheme: The value (real number) must be less than 1.
Global accuracy order of the numerical scheme¶
When it is possible, according to the mesh or to the flow model, ECOGEN can use a second-order scheme (based on MUSCL approach with a TVD slope limiter; see [SPLMD20] for details). In this case, the optional markup <secondOrder> can be inserted in the mainV5.xml input file as in the following example:
<secondOrder>
<globalLimiter>minmod</globalLimiter>
<interfaceLimiter>superbee</interfaceLimiter> <!-- optionnal node -->
<globalVolumeFractionLimiter>minmod</globalVolumeFractionLimiter> <!-- optionnal node -->
<interfaceVolumeFractionLimiter>thinc</interfaceVolumeFractionLimiter> <!-- optionnal node -->
</secondOrder>
The <secondOrder> markup must contain the node <globalLimiter>. The other nodes are optional. The slope limiters available in ECOGEN are the following: minmod [Roe86], vanleer [VL74], vanalbada [VAVLR97], mc [VL77], superbee [Roe86] and thinc [SX14] (only for volume fraction at the interface location). Markup significations are:
<globalLimiter>: Applied everywhere and on all variables unless it is overwritten by the following optional limiters.<interfaceLimiter>: Applied on all variables but only at the interface location. By default is equal to the global limiter.<globalVolumeFractionLimiter>: Applied everywhere but only on the volume-fraction and transport equations (THINC is only applied on the volume fraction) unless it is overwritten by the interface volume-fraction limiter. By default is equal to the global limiter.<interfaceVolumeFractionLimiter>: Applied only at the interface location and on the volume-fraction and transport equations (THINC is only applied on the volume fraction). By default is equal to the interface limiter.
Probes¶
It is possible to record over time flow variables at given locations in the computational domain. This is done by including to the mainV5.xml input file the optional <probe> markup.
<probe name="capteur1">
<vertex x="0.51" y="0.51" z="0.51"/>
<timeControl acqFreq="-1."/> <!-- if negative or nul, recording at each time step -->
</probe>
The two following nodes must be included in the <probe> markup:
- <vertex>: Specify the location of the probe into the computational domain in each physical direction corresponding to the attributes x, y and z (unit: m (SI)). Values must be real numbers.
- <timeControl>: Allow to specify the probe acquisition frequency (unit: s (SI)). If the value is set to zero or negative, flow values at the probe location are recorded at each time step.
Probe output-result files will be placed in the specific subfolder ECOGEN/results/XXX/probes/ where XXX represents the name of the run specified in <run> markup.
Remarks:
Recording probes with a high frequency could have a significant impact on computation performances due to the computer memory time access. To prevent that, one should fix a reasonable acquisition frequency.
Several probes can be added simultaneously. For that, place as many as wanted
<probe>markups in the mainV5.xml input files.
Simulation restart option¶
ECOGEN can restart a run from previously written results. To do so, the restartFileNumber attribute of the <restartSimulation> markup must be specified. Furthermore, this markup can include an AMRsaveFreq attribute which gives the frequency at which the mesh information of an AMR simulation is saved. Therefore, an AMR simulation can only restart from a time coherent combination of result and mesh information files.
<restartSimulation restartFileNumber="10" AMRsaveFreq="5"/>