Thanks, that did the trick! Though I used add_node instead of add_side, and
I used the nodal position to determine if the node should be flagged as
boundary node. The stitch_meshes function then worked perfectly fine.

One more question. If it is possible, how can I print out the nodal
positions in double precision? Right now I print these out to a file but I
only get 6 significant digits.

On Thu, Apr 28, 2016 at 2:43 PM, David Knezevic <david.kneze...@akselos.com>
wrote:

> As John said, the problem is presumably that your mesh doesn't have any
> boundary IDs in it. The mesh stitching uses the boundary IDs in order to
> figure out what needs to be stitched.
>
> You can try to add that data in yourself, if you like. You can do this
> within libMesh by looping over element boundaries and calling
> mesh.boundary_info->add_side() where appropriate. But I'm not sure if this
> is the easiest approach for you to use in this case. Normally you would
> want a mesh generator to provide this boundary ID data.
>
> David
>
>
>
> On Thu, Apr 28, 2016 at 5:23 AM, Pepijn Kessels <pepijnkess...@gmail.com>
> wrote:
>
>> Thanks for the suggestions. I did try to stitch the meshes together using
>> misc example 10, but it failed to find any boundary nodes. For the 2D mesh
>> I used boundary_id_type 0, 1, 2, 3 for bottom, right, top and left,
>> respectively. I note when loading the mesh it says "Mesh Dimension: 3"
>> though, which is odd.  Using:
>>
>>    SerialMesh mesh(init.comm());
>>    SerialMesh mesh2(init.comm());
>>    ExodusII_IO(mesh).read("bfstep1.e");
>>    mesh.prepare_for_use();
>>    ExodusII_IO(mesh2).read("bfstep2.e");
>>    mesh2.prepare_for_use();
>>    mesh.stitch_meshes(mesh2, 1, 3, TOLERANCE, true, true, false, false);
>>
>> I obtain for retrieving the mesh and the stitching:
>>
>>    Mesh Dimension: 3
>>    Number of Nodes: 1089
>>    Number of elements: 1024
>>    Number of elt blocks: 1
>>    Number of node sets: 0
>>    Number of side sets: 0
>>    Nodal data retrieved successfully.
>>    Nodal numbering map retrieved successfully.
>>    [0] node_num_map[i] = 1, 2, 35, 34, 3, 36, 4, 37, 5, 38, ... 1089
>>    All block IDs retrieved successfully.
>>    All block names retrieved successfully.
>>    Element numbering map retrieved successfully.
>>    [0] elem_num_map[i] = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ... 1024
>>    Reading a block of 1024 quad(s) having 4 nodes per element.
>>    Info retrieved successfully for block: 0.
>>    Connectivity retrieved successfully for block: 0.
>>    All side set names retrieved successfully.
>>    All node set names retrieved successfully.
>>
>>    Mesh Dimension: 3
>>    Number of Nodes: 429
>>    Number of elements: 384
>>    Number of elt blocks: 1
>>    Number of node sets: 0
>>    Number of side sets: 0
>>    Nodal data retrieved successfully.
>>    Nodal numbering map retrieved successfully.
>>    [0] node_num_map[i] = 1090, 1091, 1104, 1103, 1092, 1105, 1093, 1106,
>> 1094, 1107, ... 1518
>>    All block IDs retrieved successfully.
>>    All block names retrieved successfully.
>>    Element numbering map retrieved successfully.
>>    [0] elem_num_map[i] = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ... 384
>>    Reading a block of 384 quad(s) having 4 nodes per element.
>>    Info retrieved successfully for block: 0.
>>    Connectivity retrieved successfully for block: 0.
>>    All side set names retrieved successfully.
>>    All node set names retrieved successfully.
>>
>>    In SerialMesh::stitch_meshes:
>>    This mesh has 0 nodes on boundary 1.
>>    Other mesh has 0 nodes on boundary 3.
>>    No elements on specified surfaces.
>>    In SerialMesh::stitch_meshes:
>>    Found 0 matching nodes.
>>
>> If that helps.
>>
>> There's definitely overlapping nodes on the boundary between two adjacent
>> subdomains (the mesh is partly visualized on
>> http://turbmodels.larc.nasa.gov/backstep_grids.html), i.e., zone 1 & 2,
>> 2 &
>> 3, and 3 & 4 have overlapping nodes on their adjacent boundaries. The 2D
>> plot3d files do not come with so-called neutral map files, containing the
>> boundary info, so it's basically just a file with node positions.
>>
>> I'm a first timer on this topic so I'm not very familiar with what info is
>> needed for the mesh to be stitched together. Is it possible to set these
>> sidesets in libMesh such that stitching would work? Or would I need a
>> meshing software? I'd still like to use this test case for my Master's
>> thesis, but if too difficult I'll have to see if I can generate a simpler
>> mesh myself.
>>
>> Pepijn
>>
>> On Thu, Apr 28, 2016 at 12:07 AM, John Peterson <jwpeter...@gmail.com>
>> wrote:
>>
>> >
>> >
>> > On Wed, Apr 27, 2016 at 3:46 PM, Pepijn Kessels <
>> pepijnkess...@gmail.com>
>> > wrote:
>> >
>> >> Hi there,
>> >>
>> >> I'm trying to import a structured mesh for the 2D backward facing step
>> >> problem given on the nasa site. I transformed the original plot3d
>> format
>> >> into exodus format using paraview. I could import the mesh into libMesh
>> >> without problems, but I ran into some issues when trying to run a
>> >> simulation.
>> >>
>> >> The problem is that the mesh is comprised of 4 subdomains and they are
>> not
>> >> stitched together, but seen as seperate entities. I read somewhere on
>> the
>> >> forum that if the nodes on the boundary exactly overlap (which they do)
>> >> they should automatically be stitched together. I also tried to
>> manually
>> >> stitch the seperate subdomains together using "stitch_meshes" , but
>> this
>> >> did not work either as it did not find any nodes on the boundary. I
>> >> suppose
>> >> my problem is that boundary information is missing on this mesh. Is
>> there
>> >> a(n) (easy) way to fix this, such that the 4 subdomains are seen as one
>> >> domain?
>> >>
>> >
>> > This could be caused if there are duplicate nodes in the Exodus file...
>> > then find_neighbors() won't detect them as actually being neighbors
>> because
>> > there will be an infinitely thin "slit" between them.
>> >
>> > There's a utility [0] you can use to see if this is the case.
>> >
>> > [0]: https://gist.github.com/jwpeterson/7a36f9f794df67d51126
>> >
>> > As far as stitching the meshes together goes, I don't think this will
>> work
>> > if there are no sidesets in the Exodus mesh.  It's possible the
>> conversion
>> > from plot3d -> Exodus dropped these somehow.
>> >
>> > --
>> > John
>> >
>>
>> ------------------------------------------------------------------------------
>> Find and fix application performance issues faster with Applications
>> Manager
>> Applications Manager provides deep performance insights into multiple
>> tiers of
>> your business applications. It resolves application problems quickly and
>> reduces your MTTR. Get your free trial!
>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>> _______________________________________________
>> Libmesh-users mailing list
>> Libmesh-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to