Some parameters in SetupMeshAction can be moved in MeshGenerator

YaqiWang commented 4 years ago

Reason

Parameters like second_order, uniform_refine, etc. can be used by all mesh generators.

Design

If we move them into MeshGenerator, we can let the base class to do some change on the mesh returned by virtual function generate. Currently we will not delete these parameters in SetupMeshAction, until we remove the old mesh system all-together. I am currently converting Rattlesnake inputs and realized lots of inputs have Mesh/uniform_refine. I do not want to change tons of these files again if we decided to have this change in the future. If agreed, I can send in a PR. Thanks.

Impact

A new feature in mesh generators.

dschwen commented 4 years ago

Yaqi, I am sceptical about the feasibility of this. This puts a serious burden on all mesh generator implementations that create non trivial geometries, effectively doubling the effort to implement them.

If you only want to act this a s a post processing step in generate (which would create midnodes not conforming to the actual geometries) I think having a separate MakeSecondOrder generator would be the better design. It seems ill defined where the user should set second_order = true. Only the last generator? All of them? Some of them? A separate generator would be cleaner in this case IMO.

I'm all for having select generators support a second_order parameter iff they create geometry conforming second order elements. E.g. if a circle mesh generator puts the additional midpoints on the circle rather than just linearly interpolating them.

YaqiWang commented 4 years ago

My concern is that if we make mesh generators too fine-grained (i.e. each one of them finish a specific task), we might blow up the mesh block in the input quickly. For example, before we have

second_order = true

now we will have

  [tosecond]
    type = MakeSecondOrder
    input = nonsecondmesh
  []

Whether or not allowing overlapping of functionalities of generators or merging functionalities in generators is arguable. I tend to agree on it but I know it will add burdens on documentation. But on the other hand, I understand modular generators make things clear. @dschwen suggested using actions to add generators. I think we have to make a design decision here for future development: Do we want to combine functionalities in generators or want them fine-grained?

For a circle mesh generator, we can have two parameters make_second_order and second_order. The first will have non-op if the second is true.

Another question is: do we want to leave any parameters in Mesh root block with new generator system?

idaholab / moose