Enable Quadratic Elems in XYDelaunay and Related MGs

miaoyinb commented 2 weeks ago

closes #27545

Reason

Design

Impact

miaoyinb commented 2 weeks ago

@eshemon @roystgnr FYI

moosebuild commented 2 weeks ago

Job Documentation on 3f4bd39 wanted to post the following:

View the site here

This comment will be updated on new commits.

moosebuild commented 2 weeks ago

Job Coverage on 3f4bd39 wanted to post the following:

Framework coverage

No coverage report(s) were found for the base commit 24e6ae5253. Full coverage report

Modules coverage

No coverage report(s) were found for the base commit 24e6ae5253.

Full coverage reports

Reports

- [`framework`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/framework) - [`chemical_reactions`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/chemical_reactions) - [`combined`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/combined) - [`contact`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/contact) - [`electromagnetics`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/electromagnetics) - [`external_petsc_solver`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/external_petsc_solver) - [`fluid_properties`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/fluid_properties) - [`fsi`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/fsi) - [`functional_expansion_tools`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/functional_expansion_tools) - [`geochemistry`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/geochemistry) - [`heat_transfer`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/heat_transfer) - [`level_set`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/level_set) - [`misc`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/misc) - [`navier_stokes`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/navier_stokes) - [`optimization`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/optimization) - [`peridynamics`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/peridynamics) - [`phase_field`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/phase_field) - [`porous_flow`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/porous_flow) - [`ray_tracing`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/ray_tracing) - [`rdg`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/rdg) - [`reactor`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/reactor) - [`richards`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/richards) - [`scalar_transport`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/scalar_transport) - [`solid_mechanics`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/solid_mechanics) - [`solid_properties`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/solid_properties) - [`stochastic_tools`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/stochastic_tools) - [`thermal_hydraulics`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/thermal_hydraulics) - [`xfem`](https://mooseframework.inl.gov/docs/PRs/27546/coverage/xfem)

This comment will be updated on new commits.

miaoyinb commented 1 week ago

This PR is expected to have conflicts with #27434 so I will fix after that one is merged.

@roystgnr Currently, four manual options (TRI3, TRI6, TRI7 and DEFAULT) are provided as you directed. If the generated elements and input elements do not have the same orders, it should be "okay" if we do not stitch the holes. But if holes are stitched:

If quadratic elements are set to be generated for linear input meshes. We can potentially convert all input meshes to second order.
If linear elements are set to be generated for quadratic input meshes. We can also potential convert all the input meshes to first order (may lose some information if the edges are curvy).
For mixed types of input meshes, we can also convert the incompatible part.
OR, we just throw error messages without conversion.

Any ideas/preferences would be appreciated.

roystgnr commented 1 week ago

We definitely don't want to automatically convert any higher-order inputs to first-order if they're going to be used for stitching; that's a good place to throw an error. It looks like we don't currently have any MOOSE MeshGenerator shim to libMesh::UnstructuredMesh::all_first_order(), but we could add one if someone really has a source mesh that's only higher-order and they want the first-order equivalent.

If higher-order meshes are only going to be used for boundary/hole definition ... that's the situation where I think we want to explicitly require users to specify TRI3 explicitly if they really want lower-order outputs.

And if we have mixed order between different inputs? My first instinct is that we should have a MeshGenerator shim to libMesh all_second_order() and all_complete_order(), but it wouldn't be completely crazy to add those as optional parameters in the base class instead, to be run following any generate(). I'd like to hear other opinions here.

miaoyinb commented 1 week ago

Thanks, @roystgnr

I will add the error messages accordingly.

For all_first_order()/all_second_order()/all_complete_order(), do we prefer a separate MG (like ElementOrderConversionGenerator), or implementing them into the Mesh base class as options? @GiudGiud @loganharbour @lindsayad

lindsayad commented 1 week ago

We already have second_order parameter in the mesh class. But I think I would personally prefer one ElementOrderConversionGenerator or multiple mesh generators (AllSecondOrderMeshGenerator, AllCompleteOrderMeshGenerator) as opposed to parameters on the MooseMesh class

roystgnr commented 6 days ago

My vote would be for a single ConversionGenerator, with parameters to select the new order; that's just more flexible than the current mesh class parameter. We may have a mix of quadratic-capable and quadratic-incapable generators in an input, and in that case it might be useful to be able to select exactly where in the mesh generator tree we bump up the order - too early and the incapable generators can't handle it; too late and the capable generators need to all be mixed-order-input-capable too, which is a bit of an ask.

GiudGiud commented 6 days ago

Same vote. An ElementOrderConversionGenetor with block-restriction will cover all our needs

miaoyinb commented 5 days ago

Same vote. An ElementOrderConversionGenetor with block-restriction will cover all our needs

I am not sure if we want to do block restriction here. I guess a mixed-order mesh would be an issue in most cases.

moosebuild commented 4 days ago

Job Precheck on 5cceb02 wanted to post the following:

Your code requires style changes.

A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:

curl -s https://mooseframework.inl.gov/docs/PRs/27546/clang_format/style.patch | git apply -v

Alternatively, with your repository up to date and in the top level of your repository:

git clang-format 24e6ae5253b7318392e26426668de5fa1cee5f75

moosebuild commented 4 days ago

Job Apptainer moose on 3f4bd39 : invalidated by @miaoyinb

idaholab / moose