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 mailto:griff...@cims.nyu.edu>> wrote: On Apr 28, 2017, at 11:40 AM, Roy Stogner 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 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 0.080.00
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 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 mailto:sro...@email.unc.edu>> wrote: Dear Vikram, as in the examples, I am using the libmesh::KellyErrorEstimator. I’m compiling libmesh with the --enable-perflog option. Does it automatically give all the details you have l
Re: [Libmesh-users] AMR speed
arsity() 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 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
Re: [Libmesh-users] Reading ParallelMesh
Dear Roy,
thanks for your reply and for your work.
I’ll send you the mesh I’m using in a separate email.
Let me know,
Thanks,
Simone
On Mar 6, 2017, at 12:33, Roy Stogner wrote:
>
> On Sun, 5 Mar 2017, Rossi, Simone wrote:
>
>> I would like to partition and read a mesh in parallel.
>> After reading the discussion on the mailing list on “pre-partitioning a big
>> mesh"
>> I used the splitter to partition the mesh. The partitioner just worked (that
>> was great! Thanks!).
>>
>> I set up a simple test to check if I could read the mesh.
>> Partitioning with one processor and then reading it works fine.
>> On the other hand when I try with 2 processors I get the following error.
>>
>> Assertion `mesh.comm().semiverify(p_my_neighbor)' failed.
>> /not_backed_up/srossi/TPL/libmesh/libmesh-git/src/mesh/mesh_tools.C, line
>> 1726
>>
>> My simple test looks like this:
>>
>> #include "libmesh/parallel_mesh.h"
>>
>> int main(int argc, char** argv)
>> {
>> using namespace libMesh;
>> LibMeshInit init (argc, argv, MPI_COMM_WORLD);
>> ParallelMesh mesh(init.comm());
>> mesh.read("LA_T4_new_m1.cpr");
>> mesh.print_info(std::cout);
>> return 0;
>> }
>>
>> Do you have any suggestions?
>
> Can you send me the original mesh? The Checkpoint I/O is currently in
> a fragile state, and I'm working to fix that, but I've been chasing
> down other red herrings (well, other significant issues that turn out
> to be MOOSE- or libMesh-but-not-Checkpoint- related), and having such
> a simple test case to work with would be a big help.
> ---
> Roy
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
[Libmesh-users] Reading ParallelMesh
Hello,
I would like to partition and read a mesh in parallel.
After reading the discussion on the mailing list on “pre-partitioning a big
mesh"
I used the splitter to partition the mesh. The partitioner just worked (that
was great! Thanks!).
I set up a simple test to check if I could read the mesh.
Partitioning with one processor and then reading it works fine.
On the other hand when I try with 2 processors I get the following error.
Assertion `mesh.comm().semiverify(p_my_neighbor)' failed.
/not_backed_up/srossi/TPL/libmesh/libmesh-git/src/mesh/mesh_tools.C, line 1726
My simple test looks like this:
#include "libmesh/parallel_mesh.h"
int main(int argc, char** argv)
{
using namespace libMesh;
LibMeshInit init (argc, argv, MPI_COMM_WORLD);
ParallelMesh mesh(init.comm());
mesh.read("LA_T4_new_m1.cpr");
mesh.print_info(std::cout);
return 0;
}
Do you have any suggestions?
Thank you very much.
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] DG implementation
Dear John, thanks for your reply. I’m attaching a simple test with 2 elements in which I define a system with a single variable using first order elements of l2_lagrange family. I initialize the variable so that each degree of freedom stores its own ID. If I use write_discontinuous _exodusII(), the solution is exported correctly. If after that I export another timestep, I get some wrong values. I should also mention that I’m using Paraview to visualize the data. Thank you very much, 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] DG implementation
Dear Roy, thanks for your reply. I was worried about the ordering because the exported solution did not make sense. It seemed to apply the boundary conditions to the wrong elements. I learned that the global ordering is general different for different fefamilies, but everything is consistent. I just was not expecting a different ordering, as I always used the continuous elements in libmesh. In my simple test I had a mesh like this. Using both monomials and l2_lagrange ,I was getting 6 dof for each component of the system (2 in 2D, so the 12 entries). X X | / | | / | |/| | / | | / | X X Eventually I found out that the way I’m using the exodus exporter with discontinuous data is not correct. So if I do exo_exporter->write_discontinuous_exodusII( … ) exo_exporter->append(true) and then exo_exporter->write_timestep( … ) the exported file is messed up. Is there any other way to do that with exodus? I ended up using GMV, but I loose the time information. Thanks a lot, All the best, Simone On Feb 10, 2017, at 10:01, Roy Stogner wrote: > > > On Thu, 9 Feb 2017, Rossi, Simone wrote: > >> 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 > > DoF ordering isn't "right" or "wrong", it's a design decision. With > libMesh the local vector ordering is fixed (that's what lets us use > DenseSubMatrix which has only an offset and not a stride to worry > about); the global vector ordering should be either (processor, node, > variable) or (processor, variable, node) depending on whether you use > --node_major_dofs or not. > >> Does this still happen with other fefamilies? > > With more interesting FE types, and adaptive p refinement, and > adaptive h refinement with hanging nodes (which may conjoin vertex > with side/edge degrees of freedom or may only couple them via > constraint equations, depending on FE type), global DoF ordering can > do much more complicated things, and trying to second-guess it at the > application level will just leave you with incompatibilities at best > or bugs at worst. Just use the local vectors, with submatrices and > subvectors to index into them. > >> My routine for assembly of traction boundary conditions works with >> LAGRANGE fefamily. For a 2D square with 2 elements > > Two elements, each with 4 degrees of freedom, but not actually sharing > any nodes so that's you end up with 8 degrees of freedom in the full > system? > > But then you'd have 6 degrees of freedom with MONOMIAL or 8 with > L2_LAGRANGE elements, not 12. I need more detailed description here. > --- > Roy -- 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 mailto:jwpeter...@gmail.com>> wrote: On Mon, Nov 7, 2016 at 9:28 AM, Rossi, Simone 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
Great, I’ll upgrade to 3.7.4. Thanks for the help. Simone On Nov 4, 2016, at 10:37, John Peterson mailto:jwpeter...@gmail.com>> wrote: On Thu, Nov 3, 2016 at 8:53 PM, Roy Stogner mailto:royst...@ices.utexas.edu>> wrote: On Thu, 3 Nov 2016, John Peterson wrote: On Thu, Nov 3, 2016 at 4:21 PM, Rossi, Simone mailto:sro...@email.unc.edu>> wrote: I’m using PETSc 3.7.2. I’ll install a another version to check if that’s the problem. OK, it could be a bug on the libmesh side, I have not tested with 3.7.2 extensively yet... As luck would have it I just did a PETSc 3.7.2 build earlier today. Running LIBMESH_OPTIONS='-ksp_monitor' make check -C examples/transient/transient_ex1/ replicates the problem for me. I get to: Solving time step 4, time=0.1250... [0]PETSC ERROR: - Error Message -- [0]PETSC ERROR: Argument out of range [0]PETSC ERROR: Too many KSP monitors set Just talked to Fande Kong. This is apparently a known regression in PETSc that has been fixed as of 3.7.4. He has this version built on his machine and it runs this example with -ksp_monitor just 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] 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 mailto:jwpeter...@gmail.com>> wrote: On Thu, Nov 3, 2016 at 2:45 PM, Rossi, Simone 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
[Libmesh-users] Reading and compying solution from exodus
Dear all,
I’m trying to restart a simulation from an exodus file.
I can read the exodus file, but when I call copy_nodal_solution I get the error
message:
“We’ll never get here”.
The message comes from DofObject::var_to_vg.
{
936 const unsigned int
937 nvg = this->n_var_groups(s);
938
939 for (unsigned int vg=0, vg_end=0; vgn_vars(s,vg);
942 if (var < vg_end) return vg;
943 }
944
945 libmesh_error_msg("We'll never get here!");
946 return 0;
947
}
It happens that nvg = 0, so it does not even enter in the for loop.
Do you have any suggestions?
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
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 mailto:david.kneze...@akselos.com>> wrote: On Thu, Oct 13, 2016 at 12:34 PM, Rossi, Simone 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 mailto:david.kneze...@akselos.com>> wrote: On Thu, Oct 13, 2016 at 11:57 AM, Rossi, Simone 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 mailto:david.kneze...@akselos.com>> wrote: On Thu, Oct 13, 2016 at 11:57 AM, Rossi, Simone 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 mailto:ptbau...@gmail.com>> wrote: On Fri, Oct 7, 2016 at 12:36 PM, Rossi, Simone 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
