Skip to content

Rename multiple-perpendicular-flaps mesh names#303

Merged
uekerman merged 9 commits intodevelopfrom
fix-302
Nov 14, 2022
Merged

Rename multiple-perpendicular-flaps mesh names#303
uekerman merged 9 commits intodevelopfrom
fix-302

Conversation

@MakisH
Copy link
Copy Markdown
Member

@MakisH MakisH commented Oct 24, 2022

Fixes #302.

@uekerman how do you like this change? Does it fit our naming scheme?

@MakisH MakisH requested a review from uekerman October 24, 2022 19:02
@MakisH MakisH self-assigned this Oct 24, 2022
Copy link
Copy Markdown
Member

@uekerman uekerman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The suggested change makes things clearer, yes, but I don't particularly like to use other participants names.
An alternative could be to use geometric names: Fluid-Upstream-Mesh-Centers and Fluid-Downstream-Mesh-Centers. Then, probably Solid1 should also become Solid-Upstream etc.
We have no conventions yet for such multi-coupling setups.

@MakisH
Copy link
Copy Markdown
Member Author

MakisH commented Oct 30, 2022

One rule could be ParticipantName-InterfaceName-Mesh-Modifier, where InterfaceName the name of the interface/patch for the participant that defines that mesh. We don't always name these, but we do name them in OpenFOAM.

In this case, that would be Fluid-Interface1-Mesh-Centers.

In #301, where the defining participant is CalculiX, we can take the patch: name from the YAML file. This would lead to the not so elegant Solid-flux_interface1-Mesh-Faces. Which probably means we should cleanup the CalculiX patch names everywhere, if we want to follow this rule.

@uekerman
Copy link
Copy Markdown
Member

Yes, sounds good. But then we could also rename Interface1 to something meaningful, right? Or is this name fixed?

@MakisH
Copy link
Copy Markdown
Member Author

MakisH commented Oct 31, 2022

Yes, sounds good. But then we could also rename Interface1 to something meaningful, right? Or is this name fixed?

These names are currently arbitrary and not used anywhere. We just need a name for each list in this dictionary format.

@MakisH
Copy link
Copy Markdown
Member Author

MakisH commented Nov 13, 2022

I renamed the participants, meshes, and data fields:

  • Solid1 becomes Solid-Left and Solid2 becomes Solid-Right, following the directory names. We could further rename these, together with the directory names. Do we even worry about such "breaking" changes in the tutorials?
  • For the Fluid meshes, I just used Upstream and Downstream as indicators.
  • For the Solid meshes, I followed the usual Participant-Mesh name.
  • The data fields are named based on the Upstream/Downstream indicator.

Should I further rename the solid participants to Solid-Upstream and Solid-Downstream? I have mixed feelings about this. On the one hand, it is not well motivated why we are using left/right and upstream/downstream. On the other hand, it helps one understand that the other participant's name is not part of the name. I tend towards renaming.

@MakisH
Copy link
Copy Markdown
Member Author

MakisH commented Nov 13, 2022

I documented the conventions in precice/precice.github.io#216.

MakisH and others added 4 commits November 13, 2022 17:42
Solid1 becomes Solid-Left, and Solid2 becomes Solid-Right following the directory names.
We could further rename these, together with the directory names.

For the Fluid meshes, we just use Upstream and Downstream as indicators.

For the Solid meshes, we follow the usual Participant-Mesh name.

The data fields are named based on the Upstream/Downstream.
@uekerman
Copy link
Copy Markdown
Member

Should I further rename the solid participants to Solid-Upstream and Solid-Downstream? I have mixed feelings about this. On the one hand, it is not well motivated why we are using left/right and upstream/downstream. On the other hand, it helps one understand that the other participant's name is not part of the name. I tend towards renaming.

me too -> Solid-Upstream / Solid-Downstream

@uekerman uekerman merged commit 9fab7e0 into develop Nov 14, 2022
@uekerman uekerman deleted the fix-302 branch November 14, 2022 17:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants