This class is used to initialize and launch simulations or optimization routines.
More...
|
void | declare_parameters (ParameterHandler ¶m) const |
| Declare all necessary parameters to read the input files The following parameters are set here:
|
|
void | initialize (ParameterHandler ¶m) |
| Initialize the local variables declared by the parameter handler.
|
|
void | open_logfile (const std::string &) |
|
void | run_optimization () |
| Set up the required optimization objects (i.e.
|
|
void | run_test () |
| This routine is mainly used for testing single member functions in classes.
|
|
void | random_number (double &val, double min, double max) |
| Returns a random number in val argument.
|
|
|
bool | dakota_use |
| Variable set in parse_inputs which determines whether the program is being called from DAKOTA.
|
|
bool | dakota_direct |
| Decision varible for using the direct dakota interface.
|
|
bool | run_tests |
| Decision varible for running tests.
|
|
std::string | input_file |
| Stores the name of the input file with the application selector data.
|
|
boost::shared_ptr< std::ofstream > | log_file |
| Stores the name of the log file.
|
|
std::string | simulator_parameter_file_name |
| Stores the name of the parameter file containing the physical data for the simulation.
|
|
std::vector< std::string > | simulator_parameter_file_names |
| This vector stores the names of the parameter files containing the physical data for the same simulation.
|
|
std::string | optimization_parameter_file_name |
| Stores the name of the parameter file containing the optimization data.
|
|
std::string | dakota_results |
| Variable set in parse_inputs which stores the name of the results (responses) file if the simulation is being called from DAKOTA.
|
|
std::string | dakota_parameters |
| Variable set in parse_inputs which stores the name of the parameter file if the simulation is being called from DAKOTA.
|
|
std::string | program_name |
| Local varible for the program name.
|
|
std::string | program_version |
| Local variable for the program version.
|
|
bool | save_transfer_files |
| Set to true if you want to keep the mesh and solution from the simulation.
|
|
ParameterHandler | param |
| Parameter handler object that will be used to store all input data for the application.
|
|
boost::shared_ptr
< AppFrame::OptimizationBlockMatrixApplication
< dim > > | app_lin |
| Pointer where linear application is stored.
|
|
boost::shared_ptr
< AppFrame::ApplicationCopy > | newton |
| Pointer to the non-linear solver.
|
|
boost::shared_ptr
< AppFrame::AdaptiveRefinement
< dim > > | solver |
| Pointer to a solver application which applies adaptive refinement to the grid.
|
|
boost::shared_ptr
< SimulationSelector< dim > > | sim_selector |
| Object which stores the name of the application and solver Allows the user to select the application and set objects to the empty pointers.
|
|
Timer | timer |
| Object used to calculate the CPU and Run time for the simulation.
|
|
template<int dim>
class SimulatorBuilder< dim >
This class is used to initialize and launch simulations or optimization routines.
- Author
- P. Dobson, M. Secanell, Ali M. Koupaei
and the concept of sequential applications by
- Author
- Valentin N. Zingan
$Header$ This class is used to read from the command line the input file and any other flags. Based on the flags it will print instructions to screen or setup a simulation.
This is the only class called in main and it manages the problem to be solved.
This vector stores the names of the parameter files containing the physical data for the same simulation.
Sometimes it might happen that you need to go through the sequential list of the parameter files containing the physical data for the same simulation.
The final solution for the previous run will form the initial guess for the next one.
For example, some fluid flow applications lack the good initial guess which heavily influences the iterative process itself. More often it occurs for high Re
numbers.
What we do in this case is:
- we form the parameter file for some fluid flow app that includes the relatively high dynamic viscosity and therefore relatively low
Re
number,
- we use, say, zero initial guess for all solution variables like pressure and velocity,
- we use the final solution for this problem as the initial guess for the next problem whose parameter file will have lower dynamic viscosity and therefore higher
Re
number,
- we repeat till we reach the desirable dynamic viscosity (
Re
number) of the fluid for which the simulation itself was designed.
Other examples are a steep gradient of membrane water content, high overpotential, and other.
In other words, it may be extremely useful for nonlinear problems to go through the list of conditions from light or moderate towards heavy smartly forming initial guesses for each of those conditions.