Re: [Libmesh-users] AMR speed
Dear Roy, thanks for your answer. If I understand you correctly, performing more than one AMR step at every timestep is “inefficient”. The strategy should be to run with a fixed locally refined mesh for N timestep, before running a new adaptive step. So if I want to compare with a uniform grid I guess that (depending on how long the adaptive step takes) I can increase the “number of timestep” per adaptive step to make it more efficient. I’ll update my code with your suggestions. I’ll keep you posted on the outcome. Alternatively, could a possible strategy be to estimate the error at every time step, and take the adaptive step only if the error is larger than a given tolerance? Thanks again for the help, Best, Simone On Apr 28, 2017, at 15:26, Boyce Griffith <griff...@cims.nyu.edu<mailto:griff...@cims.nyu.edu>> wrote: On Apr 28, 2017, at 11:40 AM, Roy Stogner <royst...@ices.utexas.edu<mailto:royst...@ices.utexas.edu>> wrote: On Thu, 27 Apr 2017, Rossi, Simone wrote: The run times for 100 timesteps using AMR can be more than 10 times slower than when using a fine uniform grid. For example, with a 16 x 16 x 16 uniform grid, 100 iterations take about 18 seconds with a single processor. With AMR, using a 2 x 2 x 2 grid and 3 levels of refinement, 100 iterations take about 800 seconds. I didn't really understand this sentence until I started to run your code to test possible libMesh optimizations - you're running 3 levels of refinement *per timestep*!? That's pretty much guaranteed to be inefficient; for nearly any transient PDE solve, the solution is never going to change so much within a single time step that you'll want to use more than one AMR step. We probably violate this rule of thumb in the examples, which we should fix to avoid misleading others, but in most cases you want to think "time steps per adaptive step", not the other way around. (there are exceptions, but in those cases you have to also be exceptionally careful about how you do AMR; e.g. saving your previous time step's error indicator so you don't accidentally coarsen too soon) I think what Simone wants is a "three level AMR grid", so that he is getting the same effective fine grid resolution with a 2x2x2 base grid as in the uniformly fine case. What is the correct way to initialize such a mesh and maintain it in a time-dependent model? Thanks, -- Boyce I'm not complaining, though; your code really hammers the AMR code in libMesh, which is exactly what we need for optimization purposes. --- Roy -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://slashdot.org/>! http://sdm.link/slashdot ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net<mailto:Libmesh-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/libmesh-users -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] AMR speed
(old,new) 9095.3573 0.005894 157.50950.1732783.20 93.99| | | | TopologyMap | | init() 6060.7440 0.0012280.7440 0.0012280.44 0.44 | - | Totals:5.857e+07 167.5848 100.00| - On Apr 27, 2017, at 14:29, Rossi, Simone <sro...@email.unc.edu<mailto:sro...@email.unc.edu>> wrote: Ok, I ran again the tests with different max_h_levels with the perflog enabled. Let me know if you see anything here. Thanks, Simone NO AMR - | libMesh Performance: Alive time=77.5482, Active time=40.2976 | - | Event nCalls Total Time Avg TimeTotal Time Avg Time% of Active Time | | w/o Sub w/o Sub With SubWith Subw/o SWith S | |-| | | | | | DefaultCoupling | | operator() 98306 0.1609 0.020.1609 0.020.40 0.40 | | | | DofMap | | add_neighbors_to_send_list() 1 0.0959 0.0959300.3744 0.3743690.24 0.93 | | build_sparsity() 1 0.4701 0.4700551.1433 1.1432971.17 2.84 | | create_dof_constraints() 1 0.0137 0.0136730.0137 0.0136730.03 0.03 | | distribute_dofs()1 0.0126 0.0125780.4376 0.4376470.03 1.09 | | dof_indices()11010048 9.9728 0.019.9728 0.0124.7524.75| | prepare_send_list() 2 0. 0.020. 0.020.00 0.00 | | reinit() 1 0.0507 0.0506920.0507 0.0506920.13 0.13 | | | | EquationSystems | | build_parallel_solution_vector() 5 1.4241 0.2848112.4934 0.4986733.53 6.19 | | build_solution_vector() 5 0.0002 0.502.4936 0.4987240.00 6.19 | | | | ExodusII_IO | | write_nodal_data() 3 0.0774 0.0258160.0774 0.0258160.19 0.19 | | | | FE | | compute_shape_functions()10027008 11.7027 0.0111.7027 0.0129.0429.04| | init_shape_functions() 1020.0007 0.070.0007 0.070.00 0.00 | | | | FEMap | | compute_affine_map() 10027008 9.9328 0.019.9328 0.0124.6524.65| | init_reference_to_physical_map() 1020.0008 0.080.0008
Re: [Libmesh-users] AMR speed
() 6061.6498 0.0027224.9647 0.0081930.54 1.61 | | add_node() 15424321.3647 0.011.3647 0.010.44 0.44 | | make_coarsening_compatible() 8091.4420 0.0017821.4420 0.0017820.47 0.47 | | make_flags_parallel_consistent() 9090.2881 0.0003170.2881 0.0003170.09 0.09 | | make_refinement_compatible() 8090.0552 0.680.0552 0.680.02 0.02 | | | | MeshTools::Generation | | build_cube() 1 0.0002 0.0002300.0002 0.0002300.00 0.00 | | | | OldSolutionValue | | Number eval_at_node()51965645.4931 0.0163.1554 0.121.78 20.50| | check_old_context(c) 21575616.2716 0.0315.8724 0.072.04 5.15 | | check_old_context(c,p) 13434843.6784 0.038.6255 0.061.19 2.80 | | eval_at_point() 134348418.1202 0.1355.9662 0.425.88 18.16| | eval_old_dofs() 21575613.8284 0.0222.3994 0.101.24 7.27 | | | | Parallel | | allgather() 3040.0003 0.010.0003 0.010.00 0.00 | | | | Partitioner | | single_partition() 3040.0450 0.0001480.0450 0.0001480.01 0.01 | | | | PetscLinearSolver | | solve() 4041.5022 0.0037181.5022 0.0037180.49 0.49 | | | | StatisticsVector | | maximum()3030.0019 0.060.0019 0.060.00 0.00 | | | | System | | assemble() 4047.4765 0.01850618.1484 0.0449222.43 5.89 | | project_fem_vector() 1 0.0001 0.0001090.0045 0.0044740.00 0.00 | | project_vector(FunctionBase) 1 0. 0.100.0045 0.0044850.00 0.00 | | project_vector(old,new) 9096.4352 0.007079 174.81060.1923112.09 56.73| | | | TopologyMap | | init() 6060.9755 0.0016100.9755 0.0016100.32 0.32 | - | Totals:1.162e+08 308.1230 100.00| - On Apr 27, 2017, at 12:14, Vikram Garg <vikram.v.g...@gmail.com<mailto:vikram.v.g...@gmail.com>> wrote: Rossi, yes compiling with perflog should give you all the details as in the example. On Thu, Apr 27, 2017 at 10:54 AM, Rossi, Simone <sro...@email.unc.edu<mailto:sro...@email.unc.edu>> wrote: Dear Vikram, as in the examples, I am using the libmesh::KellyErrorEstimator. I’m compiling libmesh with the --ena
Re: [Libmesh-users] AMR speed
.01 1.01 | | build_sparsity() 6 0.0002 0.330.0011 0.0001872.78 15.84| | create_dof_constraints() 6 0. 0.010. 0.010.07 0.07 | | distribute_dofs()6 0.0001 0.250.0004 0.662.09 5.57 | | dof_indices()6880.0010 0.010.0010 0.0114.3614.36| | old_dof_indices()3000.0001 0.000.0001 0.000.96 0.96 | | prepare_send_list() 7 0. 0.000. 0.000.01 0.01 | | reinit() 6 0.0002 0.410.0002 0.413.48 3.48 | | | | EquationSystems | | build_solution_vector() 1 0.0001 0.560.0001 0.640.79 0.90 | Thanks. On Wed, Apr 26, 2017 at 10:09 PM, Rossi, Simone <sro...@email.unc.edu<mailto:sro...@email.unc.edu>> wrote: Dear Roy, dear Paul, dear all, I am testing AMR in libmesh using simple linear elements. My test case is a propagating front described by a reaction-diffusion equation with a cubic bistable reaction term. I followed the adaptivity examples to create this test case. The run times for 100 timesteps using AMR can be more than 10 times slower than when using a fine uniform grid. For example, with a 16 x 16 x 16 uniform grid, 100 iterations take about 18 seconds with a single processor. With AMR, using a 2 x 2 x 2 grid and 3 levels of refinement, 100 iterations take about 800 seconds. I’m attaching the code I’m using. Without AMR, I build the matrix ( mass + dt * stiffness ) once and I update the rhs at every timestep. Conversely, with AMR I am building the matrix and the rhs at every timestep for all the refinement levels. Do you have any suggestions? Thanks a lot for your help, All the best, Simone -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://slashdot.org/>! http://sdm.link/slashdot ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net<mailto:Libmesh-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/libmesh-users -- Vikram Garg Postdoctoral Associate The University of Texas at Austin http://vikramvgarg.wordpress.com/ http://www.runforindia.org/runners/vikramg -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] AMR speed
Dear Roy, dear Paul, dear all, I am testing AMR in libmesh using simple linear elements. My test case is a propagating front described by a reaction-diffusion equation with a cubic bistable reaction term. I followed the adaptivity examples to create this test case. The run times for 100 timesteps using AMR can be more than 10 times slower than when using a fine uniform grid. For example, with a 16 x 16 x 16 uniform grid, 100 iterations take about 18 seconds with a single processor. With AMR, using a 2 x 2 x 2 grid and 3 levels of refinement, 100 iterations take about 800 seconds. I’m attaching the code I’m using. Without AMR, I build the matrix ( mass + dt * stiffness ) once and I update the rhs at every timestep. Conversely, with AMR I am building the matrix and the rhs at every timestep for all the refinement levels. Do you have any suggestions? Thanks a lot for your help, All the best, Simone elX = 16 elY = 16 elZ = 16 num_steps = 101 dt = 0.01 D = 3e-3 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] DG implementation
Dear all, I’m trying to implement a DG formulation for solid mechanics using linear elements. I’m currently using the following strategy: I define my variables as MONOMIALS but in the assembly I pretend my FEType is LAGRANGE. This gives me the correct values of the shape functions on the edges. I was also able to use the L2_LAGRANGE family to achieve the same results. Do you have any suggestions on which family I should use? Additionally I noticed something wrong in the assembly. When I use LAGRANGE fefamily my global rhs vector (for a 2D elasticity problem) looks like this u_x_point0 u_y_point0 u_x_point1 u_y_point1 . . . u_x_pointN u_y_pointN and the local vector is organized in the following manner u_x_point0 u_x_point1 u_x_point2 u_y_point0 u_y_point1 u_y_point2 Does this still happen with other fefamilies? My routine for assembly of traction boundary conditions works with LAGRANGE fefamily. For a 2D square with 2 elements and a shear traction condition my rhs is RHS! Sizeglobal = 8 local = 8 # Value 0 0 1 0 2 0 3 3.125 4 0 5 3.125 6 0 7 0 When using MONOMIALS or L2_LAGRANGE , I think the contributions are in the wrong places RHS! Sizeglobal = 12local = 12 # Value 0 0 1 0 2 0 3 0 4 3.125 5 3.125 6 0 7 0 8 0 9 0 10 0 11 0 Does anyone have any suggestion? Thank you very much for your help, All the best, Simone -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] compilation error
I have the --disable-unique-ptr option in my configuration script since it is required by another library I’m using on top of libMesh. Thanks, Simone On Nov 7, 2016, at 11:49, John Peterson <jwpeter...@gmail.com<mailto:jwpeter...@gmail.com>> wrote: On Mon, Nov 7, 2016 at 9:28 AM, Rossi, Simone <sro...@email.unc.edu<mailto:sro...@email.unc.edu>> wrote: Dear all, I’m upgrading to PETSc 3.7.4 and I am now compiling the git version of libMesh. On my workstation (using gcc 5.4 and openmpi 2.0.0) I get a compilation error /not_backed_up/srossi/TPL/libmesh/libmesh-git/src/reduced_basis/rb_eim_assembly.C: In member function ‘virtual void libMesh::RBEIMAssembly::evaluate_basis_function(unsigned int, const libMesh::Elem&, const libMesh::QBase&, std::vector&)’: /not_backed_up/srossi/TPL/libmesh/libmesh-git/src/reduced_basis/rb_eim_assembly.C:72:14: error: no match for ‘operator!=’ (operand types are ‘libMesh::AutoPtr’ and ‘const libmesh_nullptr_t’) if (_qrule != libmesh_nullptr) I solved the error just by changing if (_qrule != libmesh_nullptr) =>if (_qrule.get() != libmesh_nullptr) With this change it compiles fine, but I since ’m not using the rb classes and I cannot say if this is the best way to solve this problem. Thanks, the fix looks OK to me, but I'm wondering how you ended up with a libMesh::AutoPtr here. Did you explicitly configure with --disable-unique-ptr perhaps? -- John -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] compilation error
Dear all, I’m upgrading to PETSc 3.7.4 and I am now compiling the git version of libMesh. On my workstation (using gcc 5.4 and openmpi 2.0.0) I get a compilation error /not_backed_up/srossi/TPL/libmesh/libmesh-git/src/reduced_basis/rb_eim_assembly.C: In member function ‘virtual void libMesh::RBEIMAssembly::evaluate_basis_function(unsigned int, const libMesh::Elem&, const libMesh::QBase&, std::vector&)’: /not_backed_up/srossi/TPL/libmesh/libmesh-git/src/reduced_basis/rb_eim_assembly.C:72:14: error: no match for ‘operator!=’ (operand types are ‘libMesh::AutoPtr’ and ‘const libmesh_nullptr_t’) if (_qrule != libmesh_nullptr) I solved the error just by changing if (_qrule != libmesh_nullptr) =>if (_qrule.get() != libmesh_nullptr) With this change it compiles fine, but I since ’m not using the rb classes and I cannot say if this is the best way to solve this problem. Thanks, Simone -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] ksp monitor
Hey John, I’m using PETSc 3.7.2. I’ll install a another version to check if that’s the problem. Thanks, Simone On Nov 3, 2016, at 17:36, John Peterson <jwpeter...@gmail.com<mailto:jwpeter...@gmail.com>> wrote: On Thu, Nov 3, 2016 at 2:45 PM, Rossi, Simone <sro...@email.unc.edu<mailto:sro...@email.unc.edu>> wrote: Dear all, I have been trying to run some of the time dependent examples. Every time I use the -ksp_monitor command line option (with PETSc) to see the output of the linear system, after 4 iterations the simulation crashes saying that there are too many kip_monitors. The same thing happen when running a nonlinear problem where the number of newton iterations is greater than 4. Do you have any suggestion? What version of PETSc are you using and which examples exactly? I am using PETSc 3.6.4 and I ran transient_ex1 with -ksp_monitor, and it worked fine. -- John -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] Systems of Equations, Ex4 -- Ex5
I solved the P2 problem in Ex4 and Ex5. Everything was fine, but for nu = 0.49995, the linear solver was not converging. I did not realize that as I was not printing the output of the linear solver on screen. Changing the preconditioner, I was able to solve the nearly-incompressible P2 elasticity problem, getting finally some instabilities in the pressure. Thanks for the help, Simone On Oct 13, 2016, at 13:12, David Knezevic <david.kneze...@akselos.com<mailto:david.kneze...@akselos.com>> wrote: On Thu, Oct 13, 2016 at 12:34 PM, Rossi, Simone <sro...@email.unc.edu<mailto:sro...@email.unc.edu>> wrote: Dear David, thanks for your answer. In this case (nu=0.49995), first order elements typically lock, but second order elements typically do not lock. In fact many use second order lagrangian elements for nearly incompressible materials. I wanted to use this example just to show that second order elements are not inf-sup stable. But the results I get running Ex4 are not "bad": in my opinion, they are nonsense. I wonder if the differences come from a different way of handling the boundary conditions or from a bug in the assembly. Let me know if you have any insight. Thanks, Simone Not sure why that would be the case, I guess you'll need to do more tests to figure out what's happening. Feel free to reach out if you have any specific questions. I doubt there's an issue with the BCs since they use DirichletBoundary code which is widely used, but it wouldn't hurt to check the assembly (I normally use 3D elasticity, and I'd say that this 2D elasticity example has not been widely used so a bug is possible, or alternatively maybe it's a plane strain vs. plane stress issue). David On Oct 13, 2016, at 12:00, David Knezevic <david.kneze...@akselos.com<mailto:david.kneze...@akselos.com>> wrote: On Thu, Oct 13, 2016 at 11:57 AM, Rossi, Simone <sro...@email.unc.edu<mailto:sro...@email.unc.edu>> wrote: Dear all, I’m playing around with the elasticity tests in the system of equations examples (more specifically Ex4 and Ex5). In particular I’m trying to set the poisson ratio to nu = 0.49995. With this choice the solution I get using second order lagrangian elements does not make any sense. For first order elements the solution looks more reasonable, but still different from what I get from FreeFEM++. Does it depend on the enforcement of the Dirichlet boundary conditions? Thanks, Simone nu=0.49995 is almost incompressible. Normally people use special formulations for that type of problem, e.g. a mixed method to enforce almost incompressibility (similar to Stokes in fluids). That probably explains why you get bad results by naively using the simple formulation from ex4 and ex5. David -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] ksp monitor
Dear all, I have been trying to run some of the time dependent examples. Every time I use the -ksp_monitor command line option (with PETSc) to see the output of the linear system, after 4 iterations the simulation crashes saying that there are too many kip_monitors. The same thing happen when running a nonlinear problem where the number of newton iterations is greater than 4. Do you have any suggestion? Thanks, Simone -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] Systems of Equations, Ex4 -- Ex5
Dear David, thanks for your answer. In this case (nu=0.49995), first order elements typically lock, but second order elements typically do not lock. In fact many use second order lagrangian elements for nearly incompressible materials. I wanted to use this example just to show that second order elements are not inf-sup stable. But the results I get running Ex4 are not "bad": in my opinion, they are nonsense. I wonder if the differences come from a different way of handling the boundary conditions or from a bug in the assembly. Let me know if you have any insight. Thanks, Simone On Oct 13, 2016, at 12:00, David Knezevic <david.kneze...@akselos.com<mailto:david.kneze...@akselos.com>> wrote: On Thu, Oct 13, 2016 at 11:57 AM, Rossi, Simone <sro...@email.unc.edu<mailto:sro...@email.unc.edu>> wrote: Dear all, I’m playing around with the elasticity tests in the system of equations examples (more specifically Ex4 and Ex5). In particular I’m trying to set the poisson ratio to nu = 0.49995. With this choice the solution I get using second order lagrangian elements does not make any sense. For first order elements the solution looks more reasonable, but still different from what I get from FreeFEM++. Does it depend on the enforcement of the Dirichlet boundary conditions? Thanks, Simone nu=0.49995 is almost incompressible. Normally people use special formulations for that type of problem, e.g. a mixed method to enforce almost incompressibility (similar to Stokes in fluids). That probably explains why you get bad results by naively using the simple formulation from ex4 and ex5. David -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] Systems of Equations, Ex4 -- Ex5
Dear all, I’m playing around with the elasticity tests in the system of equations examples (more specifically Ex4 and Ex5). In particular I’m trying to set the poisson ratio to nu = 0.49995. With this choice the solution I get using second order lagrangian elements does not make any sense. For first order elements the solution looks more reasonable, but still different from what I get from FreeFEM++. Does it depend on the enforcement of the Dirichlet boundary conditions? Thanks, Simone -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
Re: [Libmesh-users] Surface PDEs
Thanks Paul, so it is already implemented. It sounds awesome. Thanks again, Best Simone On Oct 7, 2016, at 13:34, Paul T. Bauman <ptbau...@gmail.com<mailto:ptbau...@gmail.com>> wrote: On Fri, Oct 7, 2016 at 12:36 PM, Rossi, Simone <sro...@email.unc.edu<mailto:sro...@email.unc.edu>> wrote: I’d like to extend my libmesh-based reaction-diffusion solver to a surface solver, taking the trace of the 3D shape functions on the surface mesh. Before I start implementing a new element, do you have any suggestion on how to approach it? If you're only solving on the surface, you can create a two-dimensional manifold mesh and pose the PDE on that. libMesh computes the correct element Jacobians in this case and you have access to both reference and physical element coordinate derivatives during assembly. This is what I do for things like membrane problems. HTH, Paul -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] Surface PDEs
Dear all, I’d like to extend my libmesh-based reaction-diffusion solver to a surface solver, taking the trace of the 3D shape functions on the surface mesh. Before I start implementing a new element, do you have any suggestion on how to approach it? Thanks, Simone -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] IO runtime error
Hello,
I’m experiencing a runtime error when export the equation systems if I use more
than one EquationSystems with different variables in each system.
In particular, I created 2 EquationSystems: systems1 with one P1 variable and
systems2 with two P1 variables. After initializing, I write the
EquationSystems on two separate exodus files
and here it breaks at runtime.
If I initialize the systems with the same number of variables , everything
works fine.
Do you have any suggestions?
I attaching the output error and the simple code I used.
Thanks,
Simone
// Output
Creating Systems1:
Initializing s1
Creating Systems2:
Initializing s2
Exporting s1
[0]PETSC ERROR:
[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably
memory access out of range
[0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
[0]PETSC ERROR: or see
http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
[0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to
find memory corruption errors
[0]PETSC ERROR: likely location of problem given in stack below
[0]PETSC ERROR: - Stack Frames
[0]PETSC ERROR: Note: The EXACT line numbers in the stack are not available,
[0]PETSC ERROR: INSTEAD the line number of the start of the function
[0]PETSC ERROR: is given.
[0]PETSC ERROR: - Error Message
--
[0]PETSC ERROR: Signal received
[0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for
trouble shooting.
[0]PETSC ERROR: Petsc Release Version 3.7.2, Jun, 05, 2016
[0]PETSC ERROR: ./test_libmesh_example on a linux-opt named aorta by srossi Fri
Aug 19 22:48:40 2016
[0]PETSC ERROR: Configure options
--prefix=/not_backed_up/srossi/TPL/petsc/3.7.2 --PETSC_ARCH=linux-opt
--with-default-arch=0 --with-c++-support --with-hypre=1 --download-hypre=1
--with-x=0
[0]PETSC ERROR: #1 User provided function() line 0 in unknown file
// main.cpp
#include "libmesh/libmesh.h"
#include "libmesh/mesh.h"
#include "libmesh/mesh_generation.h"
#include "libmesh/equation_systems.h"
#include "libmesh/explicit_system.h"
#include "libmesh/exodusII_io.h"
int main (int argc, char ** argv)
{
using namespace libMesh;
LibMeshInit init (argc, argv);
Mesh mesh(init.comm());
std::cout << "Creating Mesh ..." << std::endl;
MeshTools::Generation::build_cube (mesh,
2 , 2 , 2,
0., 1.,
0., 1.,
0., 1.,
TET4);
std::cout << "Creating Systems1: " << std::endl;
EquationSystems systems1(mesh);
ExplicitSystem& s1 = systems1.add_system("s1");
s1.add_variable("s1", FIRST);
std::cout << "Initializing s1" << std::endl;
systems1.init();
std::cout << "Creating Systems2: " << std::endl;
EquationSystems systems2(mesh);
ExplicitSystem& s2 = systems2.add_system("s2");
s2.add_variable("s2a", FIRST);
s2.add_variable("s2b", FIRST); // Commenting this line below it runs ok
std::cout << "Initializing s2" << std::endl;
systems2.init();
std::cout << "Exporting s1" << std::endl;
ExodusII_IO(systems1.get_mesh()).write_equation_systems("s1.e", systems1);
std::cout << "Exporting s2" << std::endl;
ExodusII_IO(systems2.get_mesh()).write_equation_systems("s2.e", systems2);
return 0;
}
--
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
