Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Shiyuan Gu <sgu@an...>  20130403 00:24:20

Hi all, In case of no hanging nodes contraint, and the boundary condition is only Dirichlet, should the asymmetric_constraint_rows always be set to true in the function of DofMap::heterogenously_constraint_element_matrix_and_vector? Thanks. I am looking at the libmesh examples introduction_ex4. Changing asymmetric_constraint_rows from true to false will give wrong solution. dof_map.heterogenously_constrain_element_matrix_and_vector (Ke, Fe, dof_indices,true); void DofMap::heterogenously_constrain_element_matrix_and_vector (DenseMatrix<Number>& matrix, DenseVector<Number>& rhs, std::vector<dof_id_type>& elem_dofs, bool asymmetric_constraint_rows) 
From: Roy Stogner <roystgnr@ic...>  20130403 03:21:36

On Tue, 2 Apr 2013, Shiyuan Gu wrote: > In case of no hanging nodes contraint, and the boundary condition is > only Dirichlet, should the asymmetric_constraint_rows always be set to true > in the function of > DofMap::heterogenously_constraint_element_matrix_and_vector? Thanks. > > I am looking at the libmesh examples introduction_ex4. Changing > asymmetric_constraint_rows from true to false will give wrong solution. > dof_map.heterogenously_constrain_element_matrix_and_vector (Ke, Fe, > dof_indices,true); > > void DofMap::heterogenously_constrain_element_matrix_and_vector > (DenseMatrix<Number>& matrix, > DenseVector<Number>& rhs, > std::vector<dof_id_type>& elem_dofs, > bool asymmetric_constraint_rows) One goal of the symmetric constraint rows option is to preserve the symmetry of an otherwise symmetric Jacobian, but the cost of that is we don't get to indirectly enforce the constraints by handing rows for them to the linear solver, and so when you want the constrained dof coefficients to take their correct values after a solve you need to either use a solver which calls enforce_constraints_exactly (generally our nonlinear solvers do this; our linear solvers don't) or you need to call enforce_constraints exactly yourself after the solve. If you add a call like: system.get_dof_map().enforce_constraints_exactly(system); after your solve, does that fix things? If not, then we've got a bug that needs to be fixed. If so, then we've merely got some misleading documentation that needs to be fixed.  Roy 
From: Shiyuan Gu <sgu@an...>  20130405 15:17:07

Yes system.get_dof_map().enforce_**constraints_exactly(system) after the solve fixes the problem. On Tue, Apr 2, 2013 at 10:21 PM, Roy Stogner <roystgnr@...>wrote: > > On Tue, 2 Apr 2013, Shiyuan Gu wrote: > > In case of no hanging nodes contraint, and the boundary condition is >> only Dirichlet, should the asymmetric_constraint_rows always be set to >> true >> in the function of >> DofMap::heterogenously_**constraint_element_matrix_and_**vector? Thanks. >> >> I am looking at the libmesh examples introduction_ex4. Changing >> asymmetric_constraint_rows from true to false will give wrong solution. >> dof_map.heterogenously_**constrain_element_matrix_and_**vector (Ke, Fe, >> dof_indices,true); >> >> void DofMap::heterogenously_**constrain_element_matrix_and_**vector >> (DenseMatrix<Number>& matrix, >> DenseVector<Number>& rhs, >> std::vector<dof_id_type>& elem_dofs, >> bool asymmetric_constraint_rows) >> > > One goal of the symmetric constraint rows option is to preserve the > symmetry of an otherwise symmetric Jacobian, but the cost of that is > we don't get to indirectly enforce the constraints by handing rows for > them to the linear solver, and so when you want the constrained dof > coefficients to take their correct values after a solve you need to > either use a solver which calls enforce_constraints_exactly (generally > our nonlinear solvers do this; our linear solvers don't) or you need > to call enforce_constraints exactly yourself after the solve. > > If you add a call like: > system.get_dof_map().enforce_**constraints_exactly(system); > after your solve, does that fix things? > > If not, then we've got a bug that needs to be fixed. > > If so, then we've merely got some misleading documentation that needs > to be fixed. >  > Roy > 
Sign up for the SourceForge newsletter:
No, thanks