3.2. General User Guidance

3.2.1. Check List for Input Deck

To prevent potential code crashes resulting from errors in input parameters, it is strongly recommended that beginners use GASVIEW to generate the input deck. Even advanced users should exercise extreme caution if they decide to edit the input file directly. Before initiating a calculation, to ensure a smooth and accurate simulation please carefully check the following:

1) The name of the input file must be "ingf" which stands for "_in_put _gasf_low". For the GASFLOW calculation to run successfully, it is crucial to execute it in the same directory where the "ingf" file is located. This ensures that the program can access the necessary input data and configurations without any issues. Additionally, please take note of the following:

• A "sortam" file is necessary when the input parameter "sortami" is greater than 0.

• A "cadarray" file is required when the input parameter "import_cad" is greater than 0.

2) The input file should consist of seven essential parts: $innet, $xput, $meshgn, $grafic, $rheat, $parts, and $special. Each part should be concluded with "$end". For initiating a GASFLOW run, it is mandatory to define parameters within $xput and $meshgn sections. However, users have the option to leave other parts blank when they are not required for their specific simulation.

Below is a fictitious sample problem with the minimum input parameters. The scenario involves a closed box filled with pure air, and no external disturbances are applied. As time progresses, the solution is expected to demonstrate no deviation from the initial conditions, which consist of 300 K temperature, 1 bar pressure, and no fluid flow.

The problem is represented on a 2-D domain measuring 100 cm x 250 cm, where the grid spacing is uniform with deltax = deltay = deltaz = 5 cm. The fluid cells are discretized into a grid of dimensions 20 x 50 x 1, corresponding to the x, y, and z coordinates, respectively.

 ; Duct
 $innet
 $end

 ; Main input	
 $xput	
   ; Total physical time (s)
   twfin = 10.0,	
   ; Maximum number of cycles allowed in the calculation. Default value is 10.
   maxcyc = 9999999,  
   ; Gas species	
   mat = 'air',	
   ; Initial conditions throughout domain
   gasdef(1:14,1) =  1, 21, 1, 51, 1, 2, 1, 1.0e6, 300.0, 2, 0.0, 0.0, 'air', 1.0,
 $end	

 ; Mesh generation
 $meshgn	
   iblock = 1,
   nkx = 1,
   xl(1) = 0.0, xc(1) = 0.0 , nxl(1) = 0, nxr(1) = 20, dxmn(1) = 9999.,
   xl(2) = 100.0,
   nky = 1,
   yl(1) = 0.0, yc(1) = 0.0, nyl(1) = 0, nyr(1) = 50 , dymn(1) = 9999.,
   yl(2) = 250.0,
   nkz = 1,
   zl(1) = 0.0, zc(1) = 0.0, nzl(1) = 0, nzr(1) = 1 , dzmn(1) = 9999.,
   zl(2) = 5.0,
 $end	
 
 ; Graphical output
 $grafic	
   ; time interval for time history data to be written and plotted. 
   thdt = 0.1,     	
   ; define two points that would cover the entire physical x-y domain.
   pnt(1:4,1) =  1,  1, 2, 1,
   pnt(1:4,2) = 21, 51, 2, 1,
   ; velocity vector plot on plane defined by points 1 and 2.
   v2d(1:3,1) = 1, 2, 1,             
   ; temperature contour plot on plane defined by points 1 and 2.
   c2d(1:4,1) = 1, 2, 'pn', 0,  
   c2d(1:4,2) = 1, 2, 'tk', 0,     
 $end
 
 ; heat transfer model input
 $rheat
 $end
 
 ; Lagrangian particle model input
 $parts
 $end
 
 ; Special model input for developers
 $special
 $end	

3) Ensure that all input parameters conform to the cm-gram-second unit system. It is crucial to maintain consistency in units throughout the input deck to guarantee accurate and meaningful results. Any discrepancies in units could lead to erroneous calculation results. Therefore, thorough check of all input parameters to the CGS unit system are necessary.

Quantity	CGS unit name	Unit symbol	Unit definition	In SI units
length	centimeter	cm	1/100 of meter	10^−2 m
mass	gram	g	1/1000 of kilogram	10^-3 kg
time	second	s	1 second	1 s
temperature	kelvin	K	1 kelvin	1 K
force	dyne	dyn	g⋅cm/s^2	10^-5 N
pressure	barye	Ba	g/(cm⋅s^2)	10^-1 Pa
energy	erg	erg	g⋅cm^2/s^2	10^-7 J

4) Commas are used to separate items and to separate input values for elements of the same array. Input items take the following forms:

Variable = value,

Array = value[,value,] . . .,

Array(subscripts) = value[,value,] . . .,

where subscripts are integer constants identifying particular elements of the array. Brackets indicate optional entries.

To maintain accurate data reading and prevent incomplete variable or array reads, it is essential to consistently include commas after each value. Avoiding missing commas is crucial to ensure the proper parsing of data. Examples like below must be avoided:

   twfin = 10.0	
   maxcyc = 9999999	
   mat = 'air'
   gasdef(1:14,1) =  1, 21, 1, 51, 1, 2, 1, 1.0e6, 300.0, 2, 0.0, 0.0, 'air', 1.0

5) To ensure a clear representation and better maintainability of multidimensional arrays, it is highly recommended to explicitly specify the size of the arrays. Following this practice will enhance readability and prevent any potential errors. Examples of input to be recommended:

gasdef(1:14,1) =  1, 21, 1, 51, 1, 2, 1, 1.0e6, 300.0, 2, 0.0, 0.0, 'air', 1.0,
gasdef(1:14,2) = 11, 16, 1, 51, 1, 2, 1, 1.0e6, 400.0, 2, 0.0, 0.0, 'air', 1.0,
gasdef(1:14,3) = 16, 21, 1, 51, 1, 2, 1, 1.0e6, 500.0, 2, 0.0, 0.0, 'air', 1.0,

By explicitly defining the dimensions of the array and using the array assignment syntax, the input file becomes more organized, easier to read, and less prone to errors.

It is advisable to avoid using input formats like the ones presented below, as they can potentially lead to unexpected errors, particularly with certain compilers.

Examples of input to be avoided:

gasdef(:,1) =  1, 21, 1, 51, 1, 2, 1, 1.0e6, 300.0, 2, 0.0, 0.0, 'air', 1.0,
gasdef(:,2) = 11, 16, 1, 51, 1, 2, 1, 1.0e6, 400.0, 2, 0.0, 0.0, 'air', 1.0,
gasdef(:,3) = 16, 21, 1, 51, 1, 2, 1, 1.0e6, 500.0, 2, 0.0, 0.0, 'air', 1.0,

gasdef =  1, 21, 1, 51, 1, 2, 1, 1.0e6, 300.0, 2, 0.0, 0.0, 'air', 1.0,
         11, 16, 1, 51, 1, 2, 1, 1.0e6, 400.0, 2, 0.0, 0.0, 'air', 1.0,
         16, 21, 1, 51, 1, 2, 1, 1.0e6, 500.0, 2, 0.0, 0.0, 'air', 1.0,

Using input styles shown above can introduce parsing and processing issues in some compiler environments. To ensure compatibility and smooth execution, it is best to adhere to standard input formatting guidelines recommended by the compiler or language specifications. This practice will help prevent any unexpected errors and ensure the code's robustness across different platforms and compilers.

6) Using blanks to enhance legibility in the input file is permissible. However, it is crucial to avoid embedding blanks within names, values, or between an array name and the open (left) parenthesis that encloses the array indices. For instance:

• Correct: gasdef(1:14,1) = ...

• Incorrect: gasdef (1:14,1) = ...

Introducing blanks in such incorrect ways may cause input processing errors, and thus, it is essential to adhere to the correct formatting to ensure smooth execution and accurate results.

3.2.2. Always Start with a Simpler Problem

Before setting up a complex problem, it is always helpful for the user to run some similar but simpler problems first. Doing so will allow the user to quickly gain insight to the problem and verify the majority of the input deck.

Common ways of simplifying a problem include the following:

1) Use a coarser mesh. In a heat-transfer problem, also coarsen the nodalization in all heat conducting solids.

2) Use default physical models, which are normally the simplest options.

3) Reduce the problem time, i.e., twfin.

4) Relax the pressure iteration error criterion, i.e., increase epsi0.

5) For large-scale, long-running problems, it is advisable to use the restart capability of the code to break the problem into a series of shorter runs.

3.2.3. Unphysical Results or Extremely Small Time Step

If a calculation yields unphysical results or unexpectedly small time steps, it is crucial for the user to thoroughly review the input deck. This situation may arise from the incorrect selection of physical models. Often, the root cause of such issues can be traced back to incorrectly specified initial and boundary conditions. Therefore, carefully scrutinizing these conditions should be the user's primary consideration. When faced with unexpected outcomes, users should:

1. Double-check the chosen physical models to ensure their appropriateness for the simulation.

2. Verify the correctness of initial and boundary conditions.

3. Inspect the input deck for potential mistakes, such as incorrect units or values.

The user should ask the following:

1) Have all fluid cells in the entire domain been given the correct initial conditions via defining the gasdef array appropriately? If not, please check all the gasdef definitions if extremely high pressure difference exists in some cells causing the calculation failure or extremely small time step.

2) Are there any open boundaries across which inflow can occur? If so, do the boundary cells have the appropriate fluid conditions defined via gasdef? Check if the duration of each gasdef, defined in gasdef(11,*) and gasdef(12,*), has been set correctly.

For instance, in gasdef(1:16,2) below, the user specifies the boundary cell conditions from 100 s to 1000 s. However, it is important to note that the calculation might encounter failure immediately after start as no conditions are defined for the time interval between 0 - 100 s. Similarly, if the physical time exceeds 1000 s, the calculation may also fail due to the absence of defined conditions beyond 1000 s. Ensuring proper boundary condition definitions for the entire time range is crucial to avoid such computational issues.

gasdef(1:16,2) = 1, 'im1', 1, 'jm1', 0, 1, 1, 1.013e6, 298.,2, 100, 1000, 'air', 0.9, 'h2o', 0.1,

The optimal approach is to provide the duration as 0 s to 1.0e9 s in the absence of any special considerations.

gasdef(1:16,2) = 1, 'im1', 1, 'jm1', 0, 1, 1, 1.013e6, 298.,2, 0, 1.0e9, 'air', 0.9, 'h2o', 0.1,

3) Does reducing Δt (by decreasing delt0 and/or deltmax) give the same unphysical results? For problems with strong shock wave or combustion, always start with small time step 1.0e-6 s or less.

4) Does tightening the pressure iteration convergence criterion (i.e., reducing epsi0) give the same unphysical results?

5) Are the values of the physical variables defined in incorrect units? For instance, for a pressure of 1 bar, the value should be given as 10^5 (Pa) instead of 10^6 dyn/cm^2. Being mindful of the correct units when defining physical variables is essential to ensure accuracy and consistency in the simulation. In this specific case, using the correct unit for pressure, such as 10^5 Pa (Pascal), rather than 10^6 dyn/cm^2 (dyne per square centimeter), is critical for obtaining meaningful and accurate results. Paying close attention to unit conversions and adhering to standard units throughout the input deck is a fundamental practice in numerical simulations, preventing potential errors and discrepancies in the output.

6) Does the turbulence dominant the calculation with very small time step? Try to change the initial conditions of the turbulent variables by using tkeamb0, epsamb0 or turbdef. A strong gradient of turbulent variables between the inflow and the initial ambient conditions may cause extremely small time step (controlled by 'DA', 'DD', or 'DN') after starting the calculation.

3.2.4. Steady-state Calculation

The user should note that GASFLOW-MPI always solves the time-dependent conservation equations. A steady-state calculation option is not available in the code. However, this should not prevent the user from solving steady-state (time-independent) problems with the code. The initial conditions in such a calculation will constitute an initial guess, and each time cycle will represent an iteration toward the steady solution. Time-history plots of the relevant solution quantities will indicate if and when steady-state is attained.