@eshemon @roystgnr FYI

Job Documentation on c27f819 wanted to post the following:

View the site here

This comment will be updated on new commits.

Job Coverage on c27f819 wanted to post the following:

Framework coverage

Diff coverage report

Full coverage report

Modules coverage

Reactor

Diff coverage report

Full coverage report

Full coverage reports

This comment will be updated on new commits.

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.

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.

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

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

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.

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

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.

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

Job Apptainer moose on 3f4bd39 : invalidated by @miaoyinb

@GiudGiud Just a friendly reminder. Your review would be greatly appreciated.

@GiudGiud will be on travel. If he wants to remove himself from assignment, then we might review this faster

@GiudGiud will be on travel. If he wants to remove himself from assignment, then we might review this faster

Thanks @lindsayad . It would be up to @GiudGiud. I just want to make sure this PR is not forgotten.

Let's assume I can't get to it before I come back in 2 weeks. Not sure yet

I'll review if @GiudGiud doesn't mind.

I will add more docs late today.

Let me kick those failing tests; looks to me like they just happened to coincide with some planned github.inl.gov downtime.