Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not preparing for use before exodus output can leave the mesh incompatible with Paraview #27668

Open
GiudGiud opened this issue May 20, 2024 · 5 comments
Labels
C: Meshing MeshGenerator system, mesh loading P: minor A defect that does not affect the accuracy of results. T: defect An anomaly, which is anything that deviates from expectations.

Comments

@GiudGiud
Copy link
Contributor

Bug Description

I was modifying the AdvancedExtruderGenerator to handle Quad8 and it left a lot of issues in the boundary_info that could have been handled by a prepare_for_use before outputting the mesh

the problem is that in the process of mesh generator, more nodes are added to the mesh and the boundary_info than necessary.
I could see element deletion generators facing the same issues. If we delete elements but leave their nodes in the boundary info

note that this would be an issue also for intermediate post-each mesh generator outputs

Paraview crashes on having nodes in nodesets that are not present in the mesh
Exodiff reports cryptic diffs with seemingly some OOB indexes

Steps to Reproduce

Use the AdvancedExtruded with QUAD8, dont prepare for use

Impact

Not much now that we are aware of the problem
Preparing for use could be potentially expensive which is why we dont do it

[Optional] Diagnostics

No response

@GiudGiud GiudGiud added P: minor A defect that does not affect the accuracy of results. T: defect An anomaly, which is anything that deviates from expectations. C: Meshing MeshGenerator system, mesh loading labels May 20, 2024
@lindsayad
Copy link
Member

When are you outputting the mesh? We should be always preparing for use after the final mesh generator has run

@GiudGiud
Copy link
Contributor Author

GiudGiud commented May 20, 2024

Even in mesh-only mode?
I m looking at the mesh in mesh-only mode after the extrusion generator has ran on Quad8s

@lindsayad
Copy link
Member

Yes, this code should still get called

bool
MooseMesh::prepare(const MeshBase * const mesh_to_clone)
{
  TIME_SECTION("prepare", 2, "Preparing Mesh", true);

  bool called_prepare_for_use = false;

  mooseAssert(_mesh, "The MeshBase has not been constructed");

  if (!dynamic_cast<DistributedMesh *>(&getMesh()) || _is_nemesis)
    // For whatever reason we do not want to allow renumbering here nor ever in the future?
    getMesh().allow_renumbering(false);

  if (mesh_to_clone)
  {
    mooseAssert(mesh_to_clone->is_prepared(),
                "The mesh we wish to clone from must already be prepared");
    _mesh = mesh_to_clone->clone();
    _moose_mesh_prepared = false;
  }
  else if (!_mesh->is_prepared())
  {
    _mesh->prepare_for_use();
    _moose_mesh_prepared = false;
    called_prepare_for_use = true;
  }

  if (_moose_mesh_prepared)
    return called_prepare_for_use;

@GiudGiud
Copy link
Contributor Author

Weird.
Adding a prepare_for_use right after extrusion fixed my problem for sure.
and the mesh was definitely marked as not prepared at the end of that.

@GiudGiud
Copy link
Contributor Author

looking at #25345 this should have already been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Meshing MeshGenerator system, mesh loading P: minor A defect that does not affect the accuracy of results. T: defect An anomaly, which is anything that deviates from expectations.
Projects
None yet
Development

No branches or pull requests

2 participants