Dear Paras, I have faced a lot of similar issues in the past and maybe these suggestions can help (or maybe not).
1. Generally visual rendering software (at least paraview) renders data on quad/hex meshes using triangular polygons. Consequently, when you look at the color map within a square, paraview is actually rendering the square using two triangles. Consequently, the color map often appears wrong because visually you are not seing the bi-linear interpolation, but some sort of "cut in half quad" where each cut is rendered using a linear simplex element. Do you think there is another metric you can look at other than the visualisation? What you are seeing right now might in fact be an artifact of the GPU rendering of your solution. 2. One issue with sub-divided tets into hex is that the added node on the triangular face does not match the topology of your geometry. In CFD this can introduce very large errors, so I guess it does the same thing for solid mechanics. What you can do is generate that mesh in GMSH, then "inflate it" to match the manifold of the real geometry you want to simulate. This means displacing a few nodes. You can achieve this robustly by solving a linear elasticity equation with dirichlet boundary conditoin to ensure that your displacement deforms your mesh everywhere. I have found this to work very well when the objects are spherical. 3. If the two solutions above don't work, you can try alternative meshing software (like cubit). However, they are harder to automatize in a GMSH-like fashion. Feel free to reach out if you need any help! Best Bruno On Wednesday, September 9, 2020 at 2:31:49 p.m. UTC-4 Paras Kumar wrote: > Dear Prof. Bangerth, > > Thank you for your response. > > On Wed, Sep 9, 2020 at 1:08 AM Wolfgang Bangerth <bang...@colostate.edu> > wrote: > >> >> Paras, >> >> > I am working on homogenization of particulate nano-composites and thus >> have to >> > solve the finite deformation quasistatics problem on different >> > microstructures, such as one shown in the attachment pic-1.png. >> > >> > In order to automate the generation of (2D & 3D) meshes for >> microstructures >> > comprising of randomly distributed filler particles of arbitrary >> radius, we >> > employ a self-written python code using GMSH for mesh generation. The >> setup >> > works well for 2D but for 3D, the resulting mesh (left) culminates in >> > irregularities in the stress contour as compared to that obtained with >> a >> > structured mesh (right) as can be seen from the attachment pic-2.png. >> Due to >> > the random spatial distribution and arbitrary size of particles, >> unstructured >> > mesh appeared as the feasible option. >> > >> > In order to verify that the cause of such irregularities is the mesh >> and not >> > our solver (based on deal.ii), we tested the mesh in Abaqus and similar >> > irregularities were observed, cf. pic-3.png. Refining the mesh does not >> help >> > either. >> >> > That suggests that you are doing something wrong. I don't know what >> exactly >> the problem is, and in particular how you assign material properties to >> cells, >> but we know from theory that the finite element solution must converge to >> the >> exact solution if you just refine the mesh often enough. If it doesn't >> for >> you, then something is amiss. >> >> I also had this doubt that there was some bug in my code and thus I tried > with the Abaqus solver where not much could go wrong except the mesh. > With regards to material property assignment, it is done by means of > *material option within the .inp mesh file (as was also used for the PR > https://github.com/dealii/dealii/pull/9466.) and the material IDs appear > to be correct when we export the mesh as vtk using deal.II functions and > visualize it in Paraview. > > This does not say anything about the *absolute level of accuracy*. I would >> not >> be surprised if for a mesh like the one you show (in which pretty much >> every >> hexahedron is poorly shaped), the solution is less than for the >> corresponding >> tetrahedal mesh. But if you refine it a couple of times, you should get a >> more >> accurate solution. Is this not the case? >> >> We also tried with a refined mesh (resulting in 360K elements as compared > to 120K elements for the mesh in pic-2.png), but the irregularities still > remain as can be seen in pic-4.png.Considering that fact that we wish to > model multi-particle systems, such large number of elements would render > such a mehsing approach computationally infeasible. > > >> >> > Has anyone else working with unstructured Hex meshes, observed similar >> issues? >> > Any clues on how to deal with this issue or on other tools (preferably >> open >> > source) which one could use for generating better meshes in 3D would be >> of >> > great help. >> >> The quality of meshes matters for the absolute level of error. The hex >> meshes >> you get by subdividing tets are generally quite poor, though I know of >> people >> who are using these routinely and report that they nevertheless get good >> accuracy. A better approach is certainly to see if you can find ways to >> *directly* create hex meshes. gmsh can do this to some degree. For the >> sphere >> you show, deal.II can also generate a high-quality mesh itself. >> > We have already tried several options available in GMSH, but it did not > seem to work. Could you please suggest some tool for automatic "direct" Hex > mesh generation. > Is it not a good idea to use the tet-to-hex approach for generating Hex > meshes, since this appears to be the only feasible option with GMSH > considering the complexity of the geometry. > The actual geometry in the current case comprises a spherical particle of > material-2 embedded in a cube of material-1 (later, it could be 50 such > particles embedded in the matrix). I went through the grid generation > functions of deal.II but could not find any possibilities of doing an > "intersection" between triangulations as would be necessary for the matrix > material. Did I miss something? > > Best regards, > Paras Kumar > >> >> >> -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/beba9b54-181a-45bf-bf83-7e64eb9bc645n%40googlegroups.com.
