|
|
| Line 1: |
Line 1: |
| − | ==<font color = darkblue><b> Parameters </b></font>==
| |
| − | ===<font color = royalblue> Makefile </font>===
| |
| | | | |
| − |
| |
| − | The makefile allows to compile routines and subroutines. In order to compile, the command "make" will be typped in the terminal.
| |
| − |
| |
| − | The default target of this file is "all : :".
| |
| − |
| |
| − | Since various computers can be used, the compilation has to be conditional. That is to say that several configurations of compilation are available in function of the considered cluster (Antares, Jade, ...) :
| |
| − | *FC indicates what is the used compiler. For instance : if the language is fortran90 and MPI, it will be written FC = mpif90.
| |
| − | *A part of the code is written in C, it is about the file Vtk_bin_write.c. So the compiler for the C language has to be defined thanks to CFLAGS.
| |
| − | *FFLAGS defines the optimization options for the Fortran compiler. For instance :
| |
| − | FFLAGS = -O3 -ipo -p.
| |
| − | "O3" is an optimization option of level 3. From this level, semantics of the routine can be modified. The optimization will be more aggressive concerning the memory access and the buckles management. The compilation time will be more important than for a lower level and the code size will be also bigger.
| |
| − |
| |
| − | "ipo" is an interprocedural optimization option. It authorizes the inlining of present subroutines in seperated source files.
| |
| − |
| |
| − | "p" is a profiling option.
| |
| − |
| |
| − | The common files of the executable for calculation and the common files of the executable for postprocessing have to be defined.
| |
| − |
| |
| − | For example :
| |
| − | all : : Mezo3D df6_pospro
| |
| − | COMMON_OBJS += communs.o
| |
| − | COMMON_OBJS += lectus.o
| |
| − |
| |
| − | Then Allegro files are compiled and an executable is created :
| |
| − |
| |
| − | Mezo3D : $(ALLEGRO_OBJS)
| |
| − | $(QUIET_LINK)$(FC) $(FFLAGS) -o $@ $(filter %.o,$ ˆ)
| |
| − |
| |
| − | The same thing is done for the postprocessing files :
| |
| − |
| |
| − | df6_pospro : $(POSTPRO_OBJS)
| |
| − | $(QUIET_LINK)$(FC) $(FFLAGS) -o $@ $(filter %.o,$ˆ)
| |
| − |
| |
| − | An option named clean is available. This one allows to erase files with extensions .o, .mod, .d. The executable files, the solution files and the gmon.out files are also deleted.
| |
| − |
| |
| − | It is possible to change this option if necessary.
| |
| − |
| |
| − | ===<font color = royalblue> Fort.10 </font>===
| |
| − |
| |
| − | This file is the one where the parameters of the mesh, the chemistry... are set.
| |
| − |
| |
| − | <u>GRID</u>
| |
| − |
| |
| − | This part is dedicated to the parameters of the mesh.
| |
| − | * Ndim : spatial dimension of the simulation (1 for a 1D simulation, 2 for a 2D one, 3 for a 3D one).
| |
| − | * Nx, Ny, Nz : number of points respectively in the directions <math>\vec{x}</math>, <math>\vec{y}</math> and <math>\vec{z}</math>.
| |
| − | * Npx, Npy, Npz : number of processors allocated to the resolution, respectively in the directions <math>\vec{x}</math>, <math>\vec{y}</math> and <math>\vec{z}</math>. The total number of points in the i direction is <math>Ni.Npi</math>, and the total number of processors used for the calculation is <math>Npx.Npy.Npz</math>.
| |
| − |
| |
| − | Then the geometry of the box where the simulation will take place is defined.
| |
| − | * Xmax, Ymax, Zmax : maximal lenghts of the area, respectively in the directions <math>\vec{x}</math>, <math>\vec{y}</math> and <math>\vec{z}</math>.
| |
| − | * IGridx, IGridy, IGridz : 1 if the grid is uniform in the considered direction, 0 otherwise.
| |
| − | * Alphax, Alphy, Alphaz : stretching ratios. (NO MORE AVAILABLE IN THE STAGGERED VERSION OF THE CODE)
| |
| − | * Betax, Betay, Betaz : stretching rates. (NO MORE AVAILABLE IN THE STAGGERED VERSION OF THE CODE)
| |
| − | * XP0, YP0, ZP0 : stretching positions. (NO MORE AVAILABLE IN THE STAGGERED VERSION OF THE CODE)
| |
| − |
| |
| − | Finally, the kind of boundary conditions is defined with IType. 3 choices are given :
| |
| − | * Periodic (0),
| |
| − | * General (1),
| |
| − | * Symmetrical (2).
| |
| − | (NO MORE AVAILABLE IN THE STAGGERED VERSION OF THE CODE)
| |
| − |
| |
| − |
| |
| − |
| |
| − | <u>NSCBC</u>
| |
| − |
| |
| − | NSCBC means Navier-Stokes Characteristic Boundary Conditions. With these boundary conditions, the different types of input and output are taken into account. They have to be defined on each face of the box.
| |
| − | * Periodic (0)
| |
| − | * Non-reflecting outflow (1)
| |
| − | * Non-reflecting inflow (2)
| |
| − | * Hard inflow (3)
| |
| − | * Wall (4)
| |
| − |
| |
| − |
| |
| − |
| |
| − | <u>PARAM</u>
| |
| − |
| |
| − | The needed constants are defined here.
| |
| − | * Nsc : number of scalar, defined by the equations. For example, Nsc = 3 if the scalars are <math>\rho</math>, <math>\rho{E}</math> and <math>\rho{Y}</math>.
| |
| − | Remark: If we considere a reactive case, Nsc=1 will refer to the fuel, Nsc=2 will refer to the oxydizer.
| |
| − | * Re_ac : acoustic Reynolds of the flow.
| |
| − | <center><math>Re_{ac}=\dfrac{\rho{cL}}{\mu}</math></center>
| |
| − | c : sound speed ; L : characteristic length.
| |
| − | At this stage the user should be clear in which unity he defines his geometry (1 mm, 1 cm ?), the density and the viscosity of the fluid at the reference temperature, as well as the sound speed.
| |
| − | exemple: </math> c=340 m/s </math>, </math>L=1mm=0.001 m</math>, </math>\rho=1,2 kg/m^{3}</math>, </math>\mu=1,85. 10^{-5} kg/m/s</math> lead to <math>Re_{ac}=22050</math>
| |
| − | * Gamma : ratio between heat capacity at constant pressure and heat capacity at constant volume.
| |
| − | <center><math>\gamma=\dfrac{C_{p}}{C_{v}}</math></center>
| |
| − | * Pr : Prandtl number of the flow.
| |
| − | <center><math>Pr=\dfrac{\nu}{D_{th}}</math></center>
| |
| − | Where <math>D_{th}</math> is thermal difffusivity ratio.
| |
| − | * Sc : Schmidt number of each species. Species 1 is the fuel, species 2 air and species 3 a neutral one.
| |
| − |
| |
| − |
| |
| − |
| |
| − | <u>REACTION</u>
| |
| − |
| |
| − | In this part, the parameters affecting the chemistry are defined.
| |
| − | * I_react : if 1, the chemistry will be resolve, if 0, it won't.
| |
| − | * CFL_react : CFL (Courant-Friedrichs-Lewy condition) of the reaction.
| |
| − | <center><math>CFL=\dfrac{u\Delta{t}}{\Delta{x}}</math></center>
| |
| − | * Alpha : thermal expansion ratio.
| |
| − | <center><math>\alpha=\dfrac{T_{b}-T_{u}}{T_{b}}</math></center>
| |
| − |
| |
| − | <math>T_{b}</math> : temperature of the burnt gases ; <math>T_{u}</math> : temperature of the unburnt gases.
| |
| − | * Beta : Zeldovitch number.
| |
| − | <center><math>\beta=\alpha\dfrac{T_{a}}{T_{b}}</math></center>
| |
| − | <math>T_{a}</math> : temperature of the activation barrier so that the reaction can happen.
| |
| − | * Damla_factor : Damköhler factor which defines the operational conditions of a reaction.
| |
| − | <center><math>Da=Kt1\beta.exp\left(-\dfrac{\beta}{\alpha}\right)</math></center>
| |
| − | * NuF*MF and NuO*MO : stoichiometric coefficient respectively for the fuel and the oxidant.
| |
| − | <center><math>\displaystyle Y=\nu{M}</math></center>
| |
| − | M : molar mass of the species.
| |
| − | * YF_O and YO_O : Mass fraction of fuel and oxidizer the reference flows of fuel and of oxydizer.
| |
| − | Exemple: Air and fuel are injected separately: so YF_O=1 and YO_O=0.23 .
| |
| − |
| |
| − |
| |
| − |
| |
| − | <u>FILES</u>
| |
| − |
| |
| − | In this section, the back-up files are managed (name, creation frequency...). These files are storing raw data.
| |
| − | * PREFIX : prefix of the filenames.
| |
| − | * I_fresh_run : if 1, a new calculation is started. If 0, the code restarts a calculation at a specified point.
| |
| − | * I_read_unit : the code will continue the calculations starting from the file with this number.
| |
| − | * I_save_unit : number of the first file while calculating.
| |
| − | * I_print : number of iterations that have to be done to print a message.
| |
| − | * CFL_no : settles the equation CFL.
| |
| − | * I_iter_save : number of iterations that have to be done to create a data file.
| |
| − | * Time_save : time to save the elapsed time.
| |
| − | * N_iter_stop : maximal number of iterations to stop the calculation.
| |
| − | * Time_end : maximal time to stop the calculation.
| |
| − |
| |
| − |
| |
| − |
| |
| − | <u>POST</u>
| |
| − |
| |
| − | This section deals with the post-treatment parameters.
| |
| − | * PREFIXpost : prefix of the files that will be subjected to the post-treatment.
| |
| − | * Ichoice : format of the output data. 1 to use Paraview, 2 to use Gnuplot.
| |
| − | * Xstart : first read data file that will be post-treated.
| |
| − | * Xend : last read data file.
| |
| − | * Xinc : increment to jump files.
| |
| − | * Ystart : first output file to be written.
| |
| − | At this stage some cleaning of the code would be useful for futur users.
| |
| − | * NormDir : plane normal direction (1,2,3). (WARNING in all_post NormDir may be read as REDIM in all_post.f90, it is a bug that hasn't been fixed yet, the best is to let all the following value at 0)
| |
| − | * PlaneCoord : position of the plane on XP2(NormDir), between 1 and <math>Ni.Npi</math> for the direction i.
| |
| − | * REDIM : if 0, the results will be adimensional, if 1 they will be dimensional.
| |
| − | * Lo* : reference length (1m).
| |
| − | * Co* : reference sound speed (1m/s).
| |
| − | * Rho_o* : reference density (<math>1kg/m^{3}</math>).
| |
| − | * To* : reference temperature (1K).
| |
| − |
| |
| − |
| |
| − |
| |
| − | <u>SCALAR</u>
| |
| − | This part is made to let the user customize the code, by entering parameter that he could refer to using the subroutine LECTUS with the tag scalar as it is made for exemple in the file all_post.f90.
| |
| − | The value of the scalars are given here.
| |
| − | * Uo : speed of the flow.
| |
| − | * Cv : heat capacity at constant volume.
| |
| − | * Rv, Xo, Yo : parameters for particular cases.
| |
| − |
| |
| − | ===<font color = royalblue> Fort.10.sh </font>===
| |
| − |
| |
| − | Fort.10.sh is a file written in shell language in purpose to ease the creation of initial directories for the submission of new jobs.
| |
| − |
| |
| − | As it has been first thought, it works with the file launch-run.sh. In launch-run.sh the variables NX, NY, NZ (that define the mesh size per processor) and the variables NPX, NPY, NPZ (that define the number of processors in each direction) are defined to be exported in fort.10.sh. In this way, several calculations can be launched by changing only a few parameters.
| |
| − |
| |
| − | Initialization example :
| |
| − | sh launch-run.sh -g
| |
| − |
| |
| − | The option -g calls the subroutine generate(). This subroutine creates a directory named by the variable "dir". In this directory, two other directories will be created. A directory "IN" will contain the input files while a directory "OUT" will contain the output files. Then the template of the executable "NAME" is redirected towards a file named fort.10. The file fort.10 will be located in the directory "IN". This step is realized like this :
| |
| − | sh $Name.template > $dir/IN/fort.10.
| |
| − |
| |
| − | When the file fort.10 is created, the subroutine copies the executable calculating the case, the executable dealing the results as well as the file fort.11 in the directory "IN". Then the template of the job is redirected towards the file named "job".
| |
| − |
| |
| − | ===<font color = royalblue> Vtk_bin_write </font>===
| |
| − |
| |
| − | This file concerns the writting of output files on several processors. The users may have to change flags in the file depending on the cluster he wish to use. Two configurations are available and cover all the clusters used with the code.
| |
| − | For exemple: it is possible to launch calculations either on ATON, or on VARGAS. In that case, it is necessary to put the value 1 for the computer which is going to be used. For instance, if the used computer is ATON, then the value entered will be 1 and so, it will be 0 for the computer VARGAS :
| |
| − | #define ATON 1
| |
| − | #define VARGAS 0
| |
| − | Otherwise, if the used computer is VARGAS, then the value entered will be 1 and it will be 0 for the computer ATON :
| |
| − | #define ATON 0
| |
| − | #define VARGAS 1
| |
| − | Be careful, some options will be possibly modified in function of the cluster.
| |
| − |
| |
| − | The distribution of processors can be defined in function of :
| |
| − | * Coordinates.
| |
| − | * Vectors : in that case it will depend on the dimension of the problem, NDIM.
| |
| − | * Scalar : this function will define the id number of the processor.
| |
| − |
| |
| − | ===<font color = royalblue> Job </font>===
| |
| − |
| |
| − | The job file is used if the calculation of the problem is made on a computer which is not local.
| |
| − |
| |
| − | The extension of this file is .ll because it is a LoadLeveler file.
| |
| − |
| |
| − | A job for Antares has to be created like this :
| |
| − | *Working name : locating more easily the calculations.
| |
| − | @ job_name = NAME
| |
| − | *Standard exit file :
| |
| − | @ output = \(job_name).o\(jobid)
| |
| − | *Error exit file :
| |
| − | @ error = \(job_name).e\(jobid)
| |
| − | *Working type :
| |
| − | @ job_type = MPICH
| |
| − | *Total number of wanted processus :
| |
| − | @ total_tasks = NP
| |
| − | *Maximal elapsed time for the job :
| |
| − | @ wall_clock_limit = 24 :00 :00
| |
| − | *Maximal memory by MPI process : if a process exceeds the specified limit, then the calculation is killed. Conversely, if this parameter is overestimated, the waiting time will be longer. It is preferable to execute calculations with a data limit subordinate or equal in 3gb. The really necessary memory by process has to get closer as much as possible to the wanted memory.
| |
| − | @ data_limit = 550mb
| |
| − | *Initial directory to send : this directory contains all the data for the calculation.
| |
| − | @ cri_initialdir = PWD/dir/IN
| |
| − | *Final directory for the results : the computer has to send the results to this directory.
| |
| − | @ cri_finaldir = PWD/dir/OUT
| |
| − | *User mail : an e-mail will be send in case of overtaking of elapsed time.
| |
| − | @ notify_user = name@adress.fr
| |
| − | *Buffering working directory :
| |
| − | cd $LOCAL_WORK_DIR
| |
| − | The arborescence of the file must be defined below this line. Generally, it corresponds to the arborescence of the final directory.
| |
| − |
| |
| − | The result files are moved in a directory named Spool before being copied in the final directory.
| |
| − |
| |
| − | ===<font color = royalblue> Launch-run.sh </font>===
| |
| − |
| |
| − | This file is a tool and is not essential to run the code, but can save a lot of time in case of a parameters study. For exemple it may be interesting to have a way to change the parameters automatically in order to reduce the possibility of mistakes.
| |
| − |
| |
| − | This file automates the changes to be done on the quantities of mesh points or processors in each direction. Instead of giving the value for Nx, Ny, Nz, Npx, Npy and Npz in the control file, a new file (template) is created from the original one. In this template, the value are replaced by a notation : in the direction i, the number of points is $NI and the number of processors is $NPI. The whole text is inserted in the command echo" ". The beginning of the file is shown below.
| |
| − |
| |
| − | echo"
| |
| − | ====================================================
| |
| − | ALLEGRO1-2-3D CONTROL FILE
| |
| − | ====================================================
| |
| − | # GRID #
| |
| − |
| |
| − | $NDIM Ndim
| |
| − | $NX Nx
| |
| − | $NY Ny
| |
| − | $NZ Nz
| |
| − | $NPX Npx
| |
| − | $NPY Npy
| |
| − | $NPZ Npz
| |
| − |
| |
| − | ...
| |
| − | "
| |
| − |
| |
| − | The value that will be used are then written in the launch-run.sh. This file has to begin with #!/bin/sh in order to be executable for the shell. Each case of calculation is written on a sole line.
| |
| − |
| |
| − | #!/bin/sh
| |
| − |
| |
| − | NDIM=3 NX=40 NY=40 NZ=40 NPX=1 NPY=1 NPZ=1 ./fort.10.sh $@
| |
| − | NDIM=3 NX=40 NY=40 NZ=40 NPX=2 NPY=1 NPZ=1 ./fort.10.sh $@
| |
| − |
| |
| − | The template will pass on the data to the fort.10.sh, which in turn will create the fort.10 file according the value given by the launch_run.sh.
| |
| − |
| |
| − | In this example, the first calculation is in 3D, uses a 40x40x40 mesh and works on one processor. The second one is also in 3D, but the size of the mesh is 80x40x40 and works on 2 processors.
| |
| − |
| |
| − | When doing a list of cases, there are 2 possibilities to run it :
| |
| − | * the code runs once each case one after the other (as shown above)
| |
| − | * or the code runs only one case by one. In this case, only one line is not a comment, and the calculation has to be launched manually after every change.
| |
| − |
| |
| − | ===<font color = royalblue> All_init.f90 </font>===
| |
| − | This file allows the user to initialize the problem, that is to say to give the initial conditions. For example a pressure peak can be defined, the density or the temperature can be fixed or not and so on.
| |
| − |
| |
| − | In order to describe a function (for instance a pressure function) on all the points of the scalar grid S, 2 buckles are necessary to make vary the indexes I and J in the directions x and y (if it is a 2D case, otherwise for a 3D case, 3 buckles will be used by adding the index K). These indexes give knot coordinates. Since the indexes are appropriate for processors and not for physical problem, they cannot be used to code a case. That is why variables XP2(I,1) and XP2(J,2) are used. I indicates the position in the direction x, J indicates the position in the direction y, 1 indicates the first direction and 2, the second one.
| |
| − |
| |
| − | The speed is described by WK1 and WK2 if the case is two-dimensional, adding WK3 if the case is 3D. In our test case with a pressure peak, we consider these components as null.
| |
| − |
| |
| − | The conservative variable Q(I,J,K,5) which corresponds to the energy (the number 5 indicates that is energy), is always defined as :
| |
| − |
| |
| − | <math>Q(I,J,K,5) = \dfrac{P_{atm}}{\gamma - 1}+\dfrac{1}{2}\dfrac{WK1^2+WK2^2+WK3^2}{Q(I,J,K,4)}</math>
| |
| − | The conservative variable Q(I,J,K,4) corresponds to the density.
| |
| − |
| |
| − | The routine interpolate1 is called in order to pass a scalar from the grid S to the grid of one momentum component. Thanks to this routine, speeds are expressed on V1, V2 and V3 grids.
| |
