Minor bug with the UCD reader

[Edward-Eth]

Hi, been using UCD files in MOOSE recently and discovered a bug which I believe is in Libmesh. When loading a mesh from a UCD file, if the filename/path is invalid, instead of throwing an error like this:
*** ERROR *** Error opening ExodusII mesh file: /Users/me/projects/some_project/some_folder/singlehex.e
which occurs when reading an invalid exodus, the mesh reader simple "reads" and returns a mesh with zero nodes, zero elements and zero volume. It seems that ucd_io is missing a simple "is this a real file" check.

[Edward-Eth]

Additionally, this is less of a bug more of a feature request, but in the current implementation the ucd_io implementation immediately renumbers the nodes upon reading in, which means that, in the event your nodes are not in ascending order, or are not continuously numbered, the mesh will not read correctly, despite there being enough information in the input ucd file to correctly build the mesh if the given node ID's are used for mapping before a new zero based index is created. I appreciate this is very much an edge case, and it's something I can remedy on my end, so feel free to write this off as scope creep for your implementation.

[Edward-Eth]

Bump. This issue threw me off again today.

[jwpeterson]

There is a flag on the Mesh that you can set via:

mesh.allow_renumbering(false);

however I suspect the issue in this case is that the renumbering happens implicitly with the UCD reader, so it probably requires an update. Can you attach an example of a UCD mesh that currently gets renumbered? That would be helpful to use for developing the fix for that case.

[Edward-Eth]

There is a flag on the Mesh that you can set via:

mesh.allow_renumbering(false);

however I suspect the issue in this case is that the renumbering happens implicitly with the UCD reader, so it probably requires an update. Can you attach an example of a UCD mesh that currently gets renumbered? That would be helpful to use for developing the fix for that case.

You're right that it's performed within the UCD reader itself, the issue arises here:

{
    for (unsigned int i=0; i<nNodes; i++)
      {
        libmesh_assert (in.good());

        std::array<Real, 3> xyz;

        in >> dummy   // Point number
           >> xyz[0]  // x-coordinate value
           >> xyz[1]  // y-coordinate value
           >> xyz[2]; // z-coordinate value

        Point p(xyz[0]);
#if LIBMESH_DIM > 1
        p(1) = xyz[1];
#else
        libmesh_assert_equal_to(xyz[1], 0);
#endif
#if LIBMESH_DIM > 2
        p(2) = xyz[2];
#else
        libmesh_assert_equal_to(xyz[2], 0);
#endif

        // Build the node
        mesh.add_point (p, i);
      }
  }

By assigning the node the ID of i, instead of the first value of the line, which is currently just binned by sending it to a dummy variable, you lose the original node number.

The same thing happens with elements, on line 200, the element ID is sent to dummy, and then on line 229 the id is set to i.

As I said, I'm not sure if this is something easily fixable/worth fixing. I'm not sure how/if libmesh deals with non-continuous node and element numbering.

The thing that caused my issue today was the first point in this post, namely that non-existant ucd files/incorrect paths to UCD files are not raised as errors and are instead read as empty files.

[jwpeterson]

I'm not sure how/if libmesh deals with non-continuous node and element numbering.

The Mesh itself is intended to support non-contiguous Elem and Node numberings, albeit with some potential inefficiency if you are using ReplicatedMesh. The underlying data structure is a std::vector whose ith entry is a pointer to an Elem with id() == i, therefore if e.g. the Elem numbering contains a gap (say the first Elem is number 1000000) , we simply waste the storage associated with the missing entries.

The issue, however then becomes what one can do with meshes that have a non-contiguous numbering, and there are some parts of the code, such as the Xdr and Exodus writers that don't currently support this and will therefore implicitly renumber the Mesh if they are used.

[Edward-Eth]

I would say that this is something that is probably best not implemented in that case. I have figured out a work around for my mesh generation that avoids the issue.