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

Enhance format_precice_config.py (pre-commit hook script) #3

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

Toddelismyname
Copy link

@Toddelismyname Toddelismyname commented Feb 5, 2025

The goal is to organize and enhance the structure of the elements for improved readability.

Top-Level Elements

Top-level elements are now sorted in the order:

  1. data
  2. meshes
  3. participants
  4. m2n
  5. coupling scheme

Unknown elements will appear last.

Participant Elements

Participant elements are reordered as follows:

  • First:
    • provide-mesh
    • receive-mesh
  • Then:
    • write-data
    • read-data
  • Finally:
    • mapping:

A newline is added after read/write mesh elements.

Coupling Scheme

In the coupling scheme, the following elements are paired together:
- relative-convergence-measure

  • all 3 valid ...-convergence-measure (As long as i didn't forget one)
  • exchange

Changes Before and After Calling the Script

Ran the script on the generated (unformatted) Precice Config of https://github.com/precice-forschungsprojekt/PreCICE-Genesis. before
and the result was: after


Note: This editing is not 100% finished yet and requires further testing. For now, it stays as a draft. However, if any changes are requested, they will be considered for implementation.

Questions

  • Are the initial elements inside coupling-scheme fine as they are, or do you want them changed up a bit ? It is also possible to print all other elements in 1 go without adding the empty line after those 3: 'participants', 'max-time', 'time-window-size' link to line

  • Does it matter for this hook to check for some kind of correctness. What I mean by that is that if for example no exchanges exist. The current logic has an if exchange_elements so it only prints the new line when they exist, so there are no multiple empty lines spammed.

Top-level elements are now sorted in the order: data, meshes, participants, m2n, and coupling scheme
Unknown elements will appear last
Participant elements are reordered:
- First: provide-mesh and receive-mesh
- Then: write-data and read-data
- Finally: mapping:nearest-neighbor
A newline is added after read/write mesh elements
In coupling-scheme, relative-convergence-measure and exchange are paired together
@fsimonis fsimonis self-requested a review February 6, 2025 16:27
@Toddelismyname Toddelismyname marked this pull request as ready for review February 6, 2025 16:35
Comment on lines 125 to 131
order = {
'data:': 1, # Matches data:vector, data:scalar, etc.
'mesh': 2,
'participant': 3,
'm2n:': 4,
'coupling-scheme:': 5
}
Copy link
Member

Choose a reason for hiding this comment

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

Can you define the orders as global constants and write both key functions outside the big loop?

This should make them more compact and call sites will be more readable.

Copy link
Author

Choose a reason for hiding this comment

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

Hope i fixed it with this commit: ad3a35d .

if i < last:
self.print()

continue
Copy link
Member

Choose a reason for hiding this comment

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

Why is this necessary?

Copy link
Author

@Toddelismyname Toddelismyname Feb 15, 2025

Choose a reason for hiding this comment

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

Regarding if:
This code adds an extra newline between participants to improve readability of the XML output.

The code if i < last: means "if this is not the last participant", and self.print() adds an empty line. This creates visual separation between different participant elements.

For example, without this, the XML might look like:

<participant name="Fluid">
   ...
</participant>
<participant name="Solid">
   ...
</participant>

With the extra newline, it becomes:

<participant name="Fluid">
   ...
</participant>

<participant name="Solid">
   ...
</participant>

=> So if you want no new lines between participants this needs to be removed


Regarding continue:
The continue statement is used in the context of a loop to skip the rest of the current iteration and move to the next item in the loop.

In this specific case, the continue is used because the code has a special handling block for participant elements. After processing a participant element completely (including its children, closing tag, and optional newline), the continue statement ensures that the loop moves to the next element without executing the subsequent code blocks for other element types.

Without the continue, the code would fall through to the next sections of the loop, which might handle other types of elements like coupling-scheme. By using continue, it ensures that only the participant-specific processing is applied to participant elements.

Here's a simplified example to illustrate:

for group in sorted_children:
    if 'participant' in str(group.tag):
        # Special participant processing
        process_participant(group)
        continue  # Skip the rest of the loop for this iteration
    
    # These would only be processed for non-participant elements
    if 'coupling-scheme' in str(group.tag):
        process_coupling_scheme(group)
    else:
        process_other_element(group)

=> So skipping the loop seems to be the safer bet to prevent unwanted behavior ?


So to summarize:

  • The if is only needed if new lines between participants are wanted.
  • The continue is not really needed but seems like the safer bet

Please tell me on how you want me proceed regarding these points.

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