- error_resThe errors allowed in the snapshot reconstruction.
C++ Type:std::vector<double>
Unit:(no unit assumed)
Controllable:No
Description:The errors allowed in the snapshot reconstruction.
- tag_namesNames of tags for the reduced operators.
C++ Type:std::vector<std::string>
Unit:(no unit assumed)
Controllable:No
Description:Names of tags for the reduced operators.
- tag_typesList of keywords describing if the tags correspond to independent operators or not. (op/op_dir/src/src_dir)
C++ Type:std::vector<std::string>
Unit:(no unit assumed)
Controllable:No
Description:List of keywords describing if the tags correspond to independent operators or not. (op/op_dir/src/src_dir)
- var_namesNames of variables we want to extract from solution vectors.
C++ Type:std::vector<std::string>
Unit:(no unit assumed)
Controllable:No
Description:Names of variables we want to extract from solution vectors.
PODReducedBasisTrainer
Computes the reduced subspace plus the reduced operators for POD-RB surrogate.
Overview
In this trainer, an intrusive Proper Orthogonal Decomposition (POD) based Reduced Basis (RB) method (Pinnau (2008)) is implemented which, unlike non-intrusive surrogates such as Polynomial Regression or Polynomial Chaos Expansion, is capable of considering the physics of the full-order problem at surrogate level. Therefore, it is often referred to as a physics-based but still data-driven approach. The intrusiveness, however, decreases the range of problems which this method can be used for. In the current version, this surrogate model can deal with Parameterized scalar-valued linear steady-state PDEs with affine parameter dependence only. This class is responsible for two steps in the generation of the surrogate model:
It must be mentioned that in POD-RB literature, the training phase is often referred to as offline phase and in the upcoming sections the two expressions are used interchangeably.
A parameterized linear steady-state PDE
Before the details of the above-mentioned steps are discussed, a short overview is given about the problems considered. A scalar-valued linear steady-state PDE can be expressed in operator notation as:
(1)where is the solution, is a linear operator and is a source term. The linear operator and the source terms may depend on uncertain parameters which are denoted by and organized into a parameter vector . Therefore, Eq. (1) can be expressed as:
(2)This also means that the solution itself is the function of these parameters . To make an efficient surrogate, operator and source should have an affine parameter dependence:
or in other words, the operators have to be decomposable as the sums of products of parameter-dependent scalar functions and parameter-independent constituent operators. By plugging the decompositions back to Eq. (2), the problem takes the following form:
(3)Therefore, before starting the construction of a POD-RB surrogate model, the user must identify the these decompositions first. At input level, this can be done by utilizing the Tagging System
. For each constituent operator a separate vector tag has to be created and the tags need to be supplied to the trainer object through the "tag_names" input parameter. Furthermore, an indicator shall be added to each tag through the "tag_types" input to show if the tag corresponds to a source term () or an operator (). As a last step, this system is discretized in space using the finite element method to obtain:
where and are finite element matrices and vectors, while denotes the vector containing the values of the degrees of freedom. This model is referred to as Full-Order Model (FOM) in subsequent sections. Furthermore, let denote a solution vector which is obtained by solving Eq. (4) with .
Generation of reduced subspaces
Even though it is not explicitly stated in the previous sub-section, may contain solutions for multiple variables, hence it can be expressed as , where is the total number of variables. It is assumed that each variable has spatial degrees of freedom, thus the size of the full-order system is .
As a first step in this process, Eq. (4) is solved using different parameter samples and the solution vectors for each variable defined on the "var_names" input parameter are saved into snapshot matrices
(5)In this implementation, the solutions are obtained from a PODFullSolveMultiApp using a PODSamplerSolutionTransfer and the snapshot matrices are stored within the trainer object. The next step in this process is to use these snapshots to create reduced sub-spaces for each variable. This can be done by performing POD on the snapshot matrices, which consists of the following four steps for each variable:
Creation of correlation matrices: The correlation matrices () can be computed using the snapshot matrices as , where is a weighting matrix. At this moment only is supported, where is the identity matrix.
Eigenvalue decomposition of the correlation matrices: The eigenvalue decompositions of the correlation matrices is obtained as: , where matrix and matrix contain the eigenvectors and eigenvalues of , respectively.
Determining the dimension of the reduced subspace: Based on the magnitude of the eigenvalues () in , one can compute how many basis functions are needed to reconstruct the snapshots with a given accuracy. The rank of the subspace () can be determined as:
(12)where is a given parameter describing the allowed error in the reconstruction of the snapshots. This can be supplied to the trainer using the "error_res" input parameter. Of course, this rank can be determined manually as well. For more information about this option, see PODReducedBasisSurrogate.
The reconstruction of the basis vectors for each variable: For this, the eigenvalues and eigenvectors of the correlation matrices are used together with the snapshots as:
(13)where is the -th () basis function of the reduced subspace for variable . Moreover, denotes the -th element of the -th eigenvector of correlation matrix . It is important to remember that has a global support in space, and shall not be mistaken for the local basis functions () of the finite element approximation. The global basis vectors can be also referred to as POD modes and the two expressions are used interchangeably from here on.
It must be noted that these basis functions are also stored in the trainer object. Finally, the solutions of different variables in the full-order model can be approximated as the parameter-dependent linear combination of these basis functions:
(6)where is a matrix with the POD modes as columns and are the expansion coefficients. In essence, these coefficients describe the coordinates of the approximate solution in the reduced subspace. To approximate the full solution vector using its components (-s), a segregated approach is used as follows:
(7)It is important to mention that in this approximation the unknowns are the elements of vector. In most of the cases, the size of this vector () is considerably smaller than the size of the original solution vector ().
Generation of reduced operators
To generate reduced opertors, Eq. (7) is plugged into Eq. (4) first:
(8)Since the size of \textbf{c} is smaller than the size of \textbf{u}, this equation is underdetermined. To solve this problem, a Galerkin projection is used on the system:
(9)By pulling the basis matrices into the summation, the following form is obtained.
(10)where the reduced operators and source terms can be precomputed once the basis functions are available. Therefore, the reduced equation system that is solved to obtain is
(11)It is important to note that this equation system is of size , therefore it can be solved much faster than the original full-order system which is of size . The trainer object only assembles the reduced operators and source terms, which are then transferred to PODReducedBasisSurrogate that is responsible for assembling and solving Eq. (11) and reconstructing the approximate solutions using Eq. (7) if needed.
The computation of the reduced operators consists of two step in the current implementation:
Computing the effect of the full-order operator on the global basis functions: this step includes the creation of . In practice, this is done by plugging in the basis function into a PODFullSolveMultiApp object which evaluates the residual for a given vector tag (defined using the "tag_names" input argument). The tagged residual is then transferred back to the trainer using a PODResidualTransfer object. In case when the residual from a kernel contains contributions to both the system matrix and the source term (e.g. Dirichlet BC or time derivative), certain input-level tricks can be used to separate these.
Projection of the residual vectors: this step consists of computing the inner products.
As a final note, it must emphasized that even though obtaining snapshots and creating reduced operators is a computationally expensive procedure, it has to be carried out only once. After this initial investment every new evaluation for a new parameter sample involves the summation and scaling of small dense matrices, which is of low computational cost.
Note on parallelism
As of now, the training phase is implemented in a semi-parallel manner. This means that the snapshot generation, correlation matrix generation, base generation and the computation of the reduced operators are all executed in parallel. However, the eigenvalues and eigenvectors of the correlation matrices are obtained in serial. Therefore, this phase may experience considerable slowdown when the number of snapshots is large (above ~2000).
Example Input File Syntax
To get the snapshots, four essential blocks have to be added the main input file. First, a sampler has to be defined in Samplers
to generate realizations for . These samples are then fed into a PODFullSolveMultiApp (defined in the MultiApps
block) which is capable of running simulations for each parameter. The solution vectors (snapshots) for each run are added to the trainer by a PODSamplerSolutionTransfer defined in the Transfers
block. It is important to mention that the multiapp and transfer objects need to know about the trainer. This can be ensured using the "trainer_name" input argument. The number of collected snapshots is defined in the sampler object using the "num_rows" parameter.
The global basis functions are then plugged back into the same PODFullSolveMultiApp by a new PODSamplerSolutionTransfer and the residuals are evaluated. The residuals are transferred back to the trainer using a PODResidualTransfer.
(contrib/moose/modules/stochastic_tools/test/tests/surrogates/pod_rb/internal/trainer.i)Finally, the PODReducedBasisTrainer is defined in the Trainers
block. It requires the names of the variables ("var_names") one wishes to create reduced basis for and the names of the tags ("tag_names") associated with the affine components of the full-order operator. Additionally, a vector specifying which tag corresponds to a linear operator and which to a source term needs to be added as well ("tag_types"). The available tag types are:
Tag type | Description |
---|---|
op | Operator that acts on the solution vector (i.e. a matrix). |
src | Operator that does not act on the solution vector (i.e. a source vector). |
op_dir | Dirichlet operator that acts on the solution vector (i.e. Dirichlet penalty matrix). |
src_dir | Dirichlet operator that does not act on the solution vector (i.e. Dirichlet penalty source vector). |
To specify the allowed error in the snapshot reconstruction for reach variable (), one needs to specify "error_res". In the following example the "execute_on" parameter is set to 'timestep_begin final
' which means that at the beginning of the training it will create the basis functions while at the end it will create the reduced operators.
Input Parameters
- execute_onTIMESTEP_ENDThe list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html.
Default:TIMESTEP_END
C++ Type:ExecFlagEnum
Unit:(no unit assumed)
Controllable:No
Description:The list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html.
- filenameThe name of the file which will be associated with the saved/loaded data.
C++ Type:FileName
Unit:(no unit assumed)
Controllable:No
Description:The name of the file which will be associated with the saved/loaded data.
- filenamesFiles where the eigenvalues are printed for each variable (if given).
C++ Type:std::vector<std::string>
Unit:(no unit assumed)
Controllable:No
Description:Files where the eigenvalues are printed for each variable (if given).
- prop_getter_suffixAn optional suffix parameter that can be appended to any attempt to retrieve/get material properties. The suffix will be prepended with a '_' character.
C++ Type:MaterialPropertyName
Unit:(no unit assumed)
Controllable:No
Description:An optional suffix parameter that can be appended to any attempt to retrieve/get material properties. The suffix will be prepended with a '_' character.
- use_interpolated_stateFalseFor the old and older state use projected material properties interpolated at the quadrature points. To set up projection use the ProjectedStatefulMaterialStorageAction.
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:For the old and older state use projected material properties interpolated at the quadrature points. To set up projection use the ProjectedStatefulMaterialStorageAction.
Optional Parameters
- allow_duplicate_execution_on_initialFalseIn the case where this UserObject is depended upon by an initial condition, allow it to be executed twice during the initial setup (once before the IC and again after mesh adaptivity (if applicable).
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:In the case where this UserObject is depended upon by an initial condition, allow it to be executed twice during the initial setup (once before the IC and again after mesh adaptivity (if applicable).
- control_tagsAdds user-defined labels for accessing object parameters via control logic.
C++ Type:std::vector<std::string>
Unit:(no unit assumed)
Controllable:No
Description:Adds user-defined labels for accessing object parameters via control logic.
- enableTrueSet the enabled status of the MooseObject.
Default:True
C++ Type:bool
Unit:(no unit assumed)
Controllable:Yes
Description:Set the enabled status of the MooseObject.
- execution_order_group0Execution order groups are executed in increasing order (e.g., the lowest number is executed first). Note that negative group numbers may be used to execute groups before the default (0) group. Please refer to the user object documentation for ordering of user object execution within a group.
Default:0
C++ Type:int
Unit:(no unit assumed)
Controllable:No
Description:Execution order groups are executed in increasing order (e.g., the lowest number is executed first). Note that negative group numbers may be used to execute groups before the default (0) group. Please refer to the user object documentation for ordering of user object execution within a group.
- force_postauxFalseForces the UserObject to be executed in POSTAUX
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Forces the UserObject to be executed in POSTAUX
- force_preauxFalseForces the UserObject to be executed in PREAUX
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Forces the UserObject to be executed in PREAUX
- force_preicFalseForces the UserObject to be executed in PREIC during initial setup
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Forces the UserObject to be executed in PREIC during initial setup
- use_displaced_meshFalseWhether or not this object should use the displaced mesh for computation. Note that in the case this is true but no displacements are provided in the Mesh block the undisplaced mesh will still be used.
Default:False
C++ Type:bool
Unit:(no unit assumed)
Controllable:No
Description:Whether or not this object should use the displaced mesh for computation. Note that in the case this is true but no displacements are provided in the Mesh block the undisplaced mesh will still be used.
Advanced Parameters
References
- René Pinnau.
Model Reduction via Proper Orthogonal Decomposition, chapter 5, pages 95–109.
Springer Berlin Heidelberg, Berlin, Heidelberg, 2008.
doi:10.1007/978-3-540-78841-6_5.[BibTeX]