Skip to content

Lammps compatibility remove empty lines#278

Merged
jan-janssen merged 1 commit intomainfrom
EmptyDict
Nov 28, 2025
Merged

Lammps compatibility remove empty lines#278
jan-janssen merged 1 commit intomainfrom
EmptyDict

Conversation

@jan-janssen
Copy link
Copy Markdown
Member

@jan-janssen jan-janssen commented Nov 28, 2025

Summary by CodeRabbit

Bug Fixes

  • Enhanced input file processing to robustly handle files containing empty lines, preventing potential parsing errors during configuration setup while maintaining full backward compatibility with existing input files and configurations.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Nov 28, 2025

Walkthrough

The change refactors the _modify_input_dict function to robustly skip empty lines during processing, maintain existing behavior for recognized keys, and explicitly return the modified list when modifications occur, while preserving the original return path for None input.

Changes

Cohort / File(s) Summary
Input dictionary modification hardening
pyiron_lammps/compatibility/file.py
Modified _modify_input_dict to skip lines with no tokens (empty/malformed lines), ensure explicit return of the modified list from within the if block, and retain original return path when input_control_file is None

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

  • Single function refactoring with defensive guard clauses
  • Logic changes are localized and straightforward (empty line skipping, explicit return)
  • No new features or multi-component interactions

Possibly related PRs

  • Allow custom input #276 — Introduces the original _modify_input_dict functionality; this PR hardens empty-line handling and return logic for that function

Poem

A rabbit tends the input lines with care,
Skipping empties floating in the air,
Returns are made both swift and clear,
Each token checked, no errors here! 🐰✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: refactoring code to handle and remove empty lines in LAMMPS compatibility file processing.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch EmptyDict

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@codecov
Copy link
Copy Markdown

codecov bot commented Nov 28, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.58%. Comparing base (be2dfba) to head (f061a93).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #278      +/-   ##
==========================================
+ Coverage   92.56%   92.58%   +0.01%     
==========================================
  Files           8        8              
  Lines         955      957       +2     
==========================================
+ Hits          884      886       +2     
  Misses         71       71              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
pyiron_lammps/compatibility/file.py (1)

210-217: I'll verify the concerns in this review comment by examining the codebase and testing the claims made. Let me start by exploring the context around this change.
<function_calls>

fd -e py "file.py" | grep -i compat | head -5

</function_calls>

Let me search for the file directly:
<function_calls>

find . -name "file.py" -path "/compatibility/" 2>/dev/null

</function_calls>

Let me try a broader approach:
<function_calls>

git ls-files | grep -E "compatibility.*file.py"

</function_calls>

<function_calls>

git ls-files | grep file.py

</function_calls>

Now let me examine the file:
<function_calls>

cat -n pyiron_lammps/compatibility/file.py | head -230

</function_calls>

<function_calls>

sed -n '200,225p' pyiron_lammps/compatibility/file.py

</function_calls>

Now let me search for tests related to this function:
<function_calls>

find . -name "test.py" -type f | xargs grep -l "modify_input_dict|_modify_input_dict" 2>/dev/null

</function_calls>

Let me check for any tests in the tests directory:
<function_calls>

git ls-files | grep -i test

</function_calls>

Let me search for references to this function:
<function_calls>

rg "_modify_input_dict" -A 2 -B 2

</function_calls>

Now let me check for any documentation about LAMMPS input format:
<function_calls>

rg -i "empty.?line|blank.?line" pyiron_lammps/compatibility/ -A 2 -B 2

</function_calls>

Let me look at the full context of the function to understand what it does:
<function_calls>

sed -n '190,230p' pyiron_lammps/compatibility/file.py

</function_calls>

<function_calls>

rg -i "lammps.*input|input.*format" -A 3 -B 3 pyiron_lammps/ | head -50

</function_calls>

Let me check what calls this function:
<function_calls>

rg "lammps_file_interface|_modify_input_dict" -B 5 -A 5 pyiron_lammps/compatibility/file.py | head -60

</function_calls>

Let me examine the function more carefully:
<function_calls>

sed -n '195,250p' pyiron_lammps/compatibility/file.py

</function_calls>

Now let me search for any related test files or examples:
<function_calls>

find . -type f ( -name ".py" -o -name ".txt" -o -name "*.lmp" ) | xargs grep -l "lammps_file_interface" 2>/dev/null | head -10

</function_calls>

Let me check the git history for this file:
<function_calls>

git log --oneline pyiron_lammps/compatibility/file.py | head -20

</function_calls>

Let me check if there are test files for compatibility:
<function_calls>

find . -path "test" -name "*.py" -exec grep -l "file.py|compatibility" {} ; 2>/dev/null | head -10

</function_calls>

Let me try a different approach and look at the structure:
<function_calls>

git ls-files | grep -i test

</function_calls>

Let me check the entire file for context:
<function_calls>

wc -l pyiron_lammps/compatibility/file.py

</function_calls>

<function_calls>

sed -n '1,50p' pyiron_lammps/compatibility/file.py

</function_calls>

<function_calls>

sed -n '203,224p' pyiron_lammps/compatibility/file.py

</function_calls>

Now let me look for documentation about LAMMPS input format requirements:
<function_calls>

find . -type f ( -name "README*" -o -name ".md" -o -name ".rst" ) | xargs grep -i "empty|blank|line" 2>/dev/null | grep -i lammps | head -20

</function_calls>

Let me check if there are any input file examples in the repository:
<function_calls>

find . -type f ( -name ".lmp" -o -name ".in" ) 2>/dev/null | head -10

</function_calls>

Let me search for any LAMMPS documentation or comments about line handling:
<function_calls>

rg "split|empty.*line|whitespace" pyiron_lammps/compatibility/file.py -B 2 -A 2

</function_calls>

Now let me understand the actual issue better by looking at git diff:
<function_calls>

git log -1 --stat

</function_calls>

<function_calls>

git show --stat

</function_calls>

Let me try to see the actual diff:
<function_calls>

git diff HEAD^ HEAD -- pyiron_lammps/compatibility/file.py 2>/dev/null | head -80

</function_calls>

<function_calls>

sed -n '180,230p' pyiron_lammps/compatibility/file.py

</function_calls>

Let me look for the docstring and full context:
<function_calls>

sed -n '170,240p' pyiron_lammps/compatibility/file.py

</function_calls>

Now let me search for any reference to how LAMMPS handles input:
<function_calls>

rg "def.*lammps|LAMMPS" pyiron_lammps/compatibility/file.py -B 2 -A 5 | head -40

</function_calls>

Let me check what the actual usage context is:
<function_calls>

sed -n '225,280p' pyiron_lammps/compatibility/file.py

</function_calls>

Let me look at all function definitions in this file:
<function_calls>

grep -n "^def " pyiron_lammps/compatibility/file.py

</function_calls>

<function_calls>

sed -n '1,100p' pyiron_lammps/compatibility/file.py

</function_calls>

Now let me search for external documentation about LAMMPS and empty lines:
<function_calls>

LAMMPS input file format empty lines whitespace requirements
</web_search>

Now let me check if there are any comments or documentation in the broader codebase about this:
<function_calls>

rg "input.*file|lmp.*file" pyiron_lammps/compatibility/file.py -B 3 -A 3 | head -60

</function_calls>

Let me check the function signature and its purpose:
<function_calls>

sed -n '195,225p' pyiron_lammps/compatibility/file.py

</function_calls>

Let me verify the Python idiom suggestion is correct:
<function_calls>

python3 << 'EOF'

Test the idiom suggestion

ls_empty = []
ls_nonempty = ["key"]

Old way

print(f"len(ls_empty) >= 1: {len(ls_empty) >= 1}")
print(f"len(ls_nonempty) >= 1: {len(ls_nonempty) >= 1}")

New way (more idiomatic)

print(f"if ls_empty: {bool(ls_empty)}")
print(f"if ls_nonempty: {bool(ls_nonempty)}")

They are equivalent for non-None cases

print(f"\nEquivalent: {(len(ls_empty) >= 1) == bool(ls_empty)}")
print(f"Equivalent: {(len(ls_nonempty) >= 1) == bool(ls_nonempty)}")
EOF


</function_calls>

Based on my verification, I can now provide the rewritten review comment. Let me compile my findings:

Good fix for handling empty lines.

The guard correctly prevents potential IndexError when processing empty or whitespace-only lines, and the logic properly preserves non-empty lines while applying overrides from input_control_file.

Optional refactor for Python idiom and readability:

         for l in lmp_str_lst:
-            ls = l.split()
-            if len(ls) >= 1:  # Remove empty lines
-                key = ls[0]
+            tokens = l.split()
+            if tokens:  # Remove empty lines
+                key = tokens[0]
                 if key in input_control_file.keys():
                     lmp_tmp_lst.append(key + " " + input_control_file[key])
                     keys_used.append(key)
                 else:
                     lmp_tmp_lst.append(l)

The idiomatic if tokens: is equivalent and more Pythonic than len(ls) >= 1. The variable name tokens also clarifies intent better than ls.

Note on behavioral change: The function now silently removes empty lines from the input file. LAMMPS input format generally treats empty/blank lines as ignorable whitespace, so this should not impact LAMMPS parsing or execution. If preservation of empty lines was intentional for formatting, this behavior should be documented or reconsidered.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between be2dfba and f061a93.

📒 Files selected for processing (1)
  • pyiron_lammps/compatibility/file.py (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: unittest_matrix (windows-latest, 3.14)

@jan-janssen jan-janssen merged commit 153d6c6 into main Nov 28, 2025
21 checks passed
@jan-janssen jan-janssen deleted the EmptyDict branch November 28, 2025 20:59
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.

1 participant