## Re: [Libmesh-users] Error Estimates in Axisymmetric Domain

 Re: [Libmesh-users] Error Estimates in Axisymmetric Domain From: Yusuke Sakamoto - 2012-05-16 05:06:35 ```Just reply to myself, I realized that as long as vr, vz, and p values are the same for two different equation systems, the error should be zero, whether the domain is normal 2D or axisymmetric 2D. The source of the error is that the quadrature order used in ExactSolution to compute the reference values is different from the quadrature order used in MeshFunction to compute the coarse values. I am not sure how ExactSolution and MeshFunction determine the quadrature rule. Am I doing something wrong here, or is this a bug in Libmesh? Yusuke On 05/14/2012 05:53 PM, Yusuke Sakamoto wrote: > Dear all, > > I am trying to carry out the convergence analysis on the 2D axisymmetric > mesh. The problem is a simple Stokes flow. Before comparing the result > to the reference mesh, I compared the solution to itself. > > // Compare the computed solution to the reference solution > ExactSolution ExSol(equation_systems); > ExSol.attach_reference_solution(&equation_systems); > > string sys_name("Cell"); > string var_name; > > var_name = "vr"; > ExSol.compute_error(sys_name, var_name); > Real h1_vr = ExSol.h1_error(sys_name, var_name); > > var_name = "vz"; > ExSol.compute_error(sys_name, var_name); > Real h1_vz = ExSol.h1_error(sys_name, var_name); > > var_name = "p"; > ExSol.compute_error(sys_name, var_name); > Real L2_p = ExSol.l2_error(sys_name, var_name); > > The error should be zero, but the result is not very good... > > H1 vr: 0.0189777 > H1 vz: 1.74623e-09 > L2 p: 2.2159e-08 > > Is this because internally, libmesh differentiate and integrate the > error over normal 2D domain? If so, which part should I modify? > > Thanks, > > Yusuke > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ```

 [Libmesh-users] Error Estimates in Axisymmetric Domain From: Yusuke Sakamoto - 2012-05-14 22:53:15 ```Dear all, I am trying to carry out the convergence analysis on the 2D axisymmetric mesh. The problem is a simple Stokes flow. Before comparing the result to the reference mesh, I compared the solution to itself. // Compare the computed solution to the reference solution ExactSolution ExSol(equation_systems); ExSol.attach_reference_solution(&equation_systems); string sys_name("Cell"); string var_name; var_name = "vr"; ExSol.compute_error(sys_name, var_name); Real h1_vr = ExSol.h1_error(sys_name, var_name); var_name = "vz"; ExSol.compute_error(sys_name, var_name); Real h1_vz = ExSol.h1_error(sys_name, var_name); var_name = "p"; ExSol.compute_error(sys_name, var_name); Real L2_p = ExSol.l2_error(sys_name, var_name); The error should be zero, but the result is not very good... H1 vr: 0.0189777 H1 vz: 1.74623e-09 L2 p: 2.2159e-08 Is this because internally, libmesh differentiate and integrate the error over normal 2D domain? If so, which part should I modify? Thanks, Yusuke ```
 Re: [Libmesh-users] Error Estimates in Axisymmetric Domain From: Yusuke Sakamoto - 2012-05-16 05:06:35 ```Just reply to myself, I realized that as long as vr, vz, and p values are the same for two different equation systems, the error should be zero, whether the domain is normal 2D or axisymmetric 2D. The source of the error is that the quadrature order used in ExactSolution to compute the reference values is different from the quadrature order used in MeshFunction to compute the coarse values. I am not sure how ExactSolution and MeshFunction determine the quadrature rule. Am I doing something wrong here, or is this a bug in Libmesh? Yusuke On 05/14/2012 05:53 PM, Yusuke Sakamoto wrote: > Dear all, > > I am trying to carry out the convergence analysis on the 2D axisymmetric > mesh. The problem is a simple Stokes flow. Before comparing the result > to the reference mesh, I compared the solution to itself. > > // Compare the computed solution to the reference solution > ExactSolution ExSol(equation_systems); > ExSol.attach_reference_solution(&equation_systems); > > string sys_name("Cell"); > string var_name; > > var_name = "vr"; > ExSol.compute_error(sys_name, var_name); > Real h1_vr = ExSol.h1_error(sys_name, var_name); > > var_name = "vz"; > ExSol.compute_error(sys_name, var_name); > Real h1_vz = ExSol.h1_error(sys_name, var_name); > > var_name = "p"; > ExSol.compute_error(sys_name, var_name); > Real L2_p = ExSol.l2_error(sys_name, var_name); > > The error should be zero, but the result is not very good... > > H1 vr: 0.0189777 > H1 vz: 1.74623e-09 > L2 p: 2.2159e-08 > > Is this because internally, libmesh differentiate and integrate the > error over normal 2D domain? If so, which part should I modify? > > Thanks, > > Yusuke > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ```
 Re: [Libmesh-users] Error Estimates in Axisymmetric Domain From: Derek Gaston - 2012-05-16 15:06:49 ```Quadrature rule should really have nothing to do with it. If you are really passing in the _exact_ same solution as the one you are computing it should compute zero error (to within machine precision). Can you create a small example solving something simple that demonstrates the problem? Derek On May 15, 2012, at 11:06 PM, Yusuke Sakamoto wrote: > Just reply to myself, I realized that as long as vr, vz, and p values > are the same for two different equation systems, the error should be > zero, whether the domain is normal 2D or axisymmetric 2D. The source of > the error is that the quadrature order used in ExactSolution to compute > the reference values is different from the quadrature order used in > MeshFunction to compute the coarse values. I am not sure how > ExactSolution and MeshFunction determine the quadrature rule. Am I doing > something wrong here, or is this a bug in Libmesh? > > Yusuke > > On 05/14/2012 05:53 PM, Yusuke Sakamoto wrote: >> Dear all, >> >> I am trying to carry out the convergence analysis on the 2D axisymmetric >> mesh. The problem is a simple Stokes flow. Before comparing the result >> to the reference mesh, I compared the solution to itself. >> >> // Compare the computed solution to the reference solution >> ExactSolution ExSol(equation_systems); >> ExSol.attach_reference_solution(&equation_systems); >> >> string sys_name("Cell"); >> string var_name; >> >> var_name = "vr"; >> ExSol.compute_error(sys_name, var_name); >> Real h1_vr = ExSol.h1_error(sys_name, var_name); >> >> var_name = "vz"; >> ExSol.compute_error(sys_name, var_name); >> Real h1_vz = ExSol.h1_error(sys_name, var_name); >> >> var_name = "p"; >> ExSol.compute_error(sys_name, var_name); >> Real L2_p = ExSol.l2_error(sys_name, var_name); >> >> The error should be zero, but the result is not very good... >> >> H1 vr: 0.0189777 >> H1 vz: 1.74623e-09 >> L2 p: 2.2159e-08 >> >> Is this because internally, libmesh differentiate and integrate the >> error over normal 2D domain? If so, which part should I modify? >> >> Thanks, >> >> Yusuke >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Libmesh-users mailing list >> Libmesh-users@... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@... > https://lists.sourceforge.net/lists/listinfo/libmesh-users ```
 Re: [Libmesh-users] Error Estimates in Axisymmetric Domain From: Yusuke Sakamoto - 2012-05-16 16:47:03 ```I looked for the source of the error, and found that it is due to the fact that I call Mesh::all_second_order() after refining the mesh by, MeshRefinement::uniformly_refine (n_refinements). It corrupts the internal data structure or something in EquationSystems object. It doesn't even save the right solution when I call EquationSystems.write(...). When I call all_second_order before refining the mesh, everything works perfectly. I will implement a new function for integration over cylindrical domain for error estimate. Thanks for your help, Yusuke On 05/16/2012 10:06 AM, Derek Gaston wrote: > Quadrature rule should really have nothing to do with it. If you are really passing in the _exact_ same solution as the one you are computing it should compute zero error (to within machine precision). > > Can you create a small example solving something simple that demonstrates the problem? > > Derek > > On May 15, 2012, at 11:06 PM, Yusuke Sakamoto wrote: > >> Just reply to myself, I realized that as long as vr, vz, and p values >> are the same for two different equation systems, the error should be >> zero, whether the domain is normal 2D or axisymmetric 2D. The source of >> the error is that the quadrature order used in ExactSolution to compute >> the reference values is different from the quadrature order used in >> MeshFunction to compute the coarse values. I am not sure how >> ExactSolution and MeshFunction determine the quadrature rule. Am I doing >> something wrong here, or is this a bug in Libmesh? >> >> Yusuke >> >> On 05/14/2012 05:53 PM, Yusuke Sakamoto wrote: >>> Dear all, >>> >>> I am trying to carry out the convergence analysis on the 2D axisymmetric >>> mesh. The problem is a simple Stokes flow. Before comparing the result >>> to the reference mesh, I compared the solution to itself. >>> >>> // Compare the computed solution to the reference solution >>> ExactSolution ExSol(equation_systems); >>> ExSol.attach_reference_solution(&equation_systems); >>> >>> string sys_name("Cell"); >>> string var_name; >>> >>> var_name = "vr"; >>> ExSol.compute_error(sys_name, var_name); >>> Real h1_vr = ExSol.h1_error(sys_name, var_name); >>> >>> var_name = "vz"; >>> ExSol.compute_error(sys_name, var_name); >>> Real h1_vz = ExSol.h1_error(sys_name, var_name); >>> >>> var_name = "p"; >>> ExSol.compute_error(sys_name, var_name); >>> Real L2_p = ExSol.l2_error(sys_name, var_name); >>> >>> The error should be zero, but the result is not very good... >>> >>> H1 vr: 0.0189777 >>> H1 vz: 1.74623e-09 >>> L2 p: 2.2159e-08 >>> >>> Is this because internally, libmesh differentiate and integrate the >>> error over normal 2D domain? If so, which part should I modify? >>> >>> Thanks, >>> >>> Yusuke >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Libmesh-users mailing list >>> Libmesh-users@... >>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Libmesh-users mailing list >> Libmesh-users@... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users ```
 Re: [Libmesh-users] Error Estimates in Axisymmetric Domain From: Roy Stogner - 2012-05-16 16:56:52 ```On Wed, 16 May 2012, Yusuke Sakamoto wrote: > I looked for the source of the error, and found that it is due to the > fact that I call Mesh::all_second_order() after refining the mesh by, > MeshRefinement::uniformly_refine (n_refinements). It corrupts the > internal data structure or something in EquationSystems object. It > doesn't even save the right solution when I call > EquationSystems.write(...). When I call all_second_order before refining > the mesh, everything works perfectly. Hmm... indeed, it looks like all_second_order() is only implemented for "flat" meshes but doesn't even contain a libmesh_assert() testing for refinement. I don't have time to implement a refinement-compatible all_second_order() right now, but I can at least add that assert(). Thanks for looking into this. > I will implement a new function for integration over cylindrical domain > for error estimate. One thing I might suggest: although you can't use higher-order finite element types on a mesh of first-order Elems, you can use first-order finite elements on a mesh of second-order Elems, and the added cost should only be moderate in RAM and trivial in CPU time. You might try that if you're planning to run a mix of first-order and second-order problems on the same mesh. --- Roy ```
 Re: [Libmesh-users] Error Estimates in Axisymmetric Domain From: Roy Stogner - 2012-05-16 17:00:26 ```On Wed, 16 May 2012, Roy Stogner wrote: > Hmm... indeed, it looks like all_second_order() is only implemented > for "flat" meshes but doesn't even contain a libmesh_assert() testing > for refinement. I don't have time to implement a > refinement-compatible all_second_order() right now, but I can at least > add that assert(). No, wait, there already is such an assert, at mesh_modification.C:513. In that case I can add a second bit of advice: when running a libMesh program and seeing something unexpected (or just when running a new program for the first time), use a METHOD=devel or METHOD=dbg configuration to make sure all those asserts get tested. An assertion failure is usually easier to debug than a questionably large error estimator result. --- Roy ```
 Re: [Libmesh-users] Error Estimates in Axisymmetric Domain From: Derek Gaston - 2012-05-16 17:03:33 ```Might want to make this a real error and not an assert…. this isn't in a performance critical section…. Derek On May 16, 2012, at 11:00 AM, Roy Stogner wrote: > > On Wed, 16 May 2012, Roy Stogner wrote: > >> Hmm... indeed, it looks like all_second_order() is only implemented >> for "flat" meshes but doesn't even contain a libmesh_assert() testing >> for refinement. I don't have time to implement a >> refinement-compatible all_second_order() right now, but I can at least >> add that assert(). > > No, wait, there already is such an assert, at mesh_modification.C:513. > > In that case I can add a second bit of advice: when running a libMesh > program and seeing something unexpected (or just when running a new > program for the first time), use a METHOD=devel or METHOD=dbg > configuration to make sure all those asserts get tested. An assertion > failure is usually easier to debug than a questionably large error > estimator result. > --- > Roy > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@... > https://lists.sourceforge.net/lists/listinfo/libmesh-users ```

JavaScript is required for this form.

No, thanks