Add FTIR analysis

[Trenton-Wells]

Describe your changes

Added FTIR Analysis python file and notebook tutorial file.

Issue ticket number and link

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist before requesting a review

• I have performed a self-review of my code
• Code changes are covered by tests.
• Code changes have been evaluated for compatibility/integration with Scenario analysis (for future PRs)
• Code changes have been evaluated for compatibility/integration with geospatial autotemplating (for future PRs)
• New functions added to init.py
• API.rst is up to date, along with other sphinx docs pages
• Example notebooks are rerun and differences in results scrutinized
• What's new changelog has been updated in the docs

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 19.87%. Comparing base (51172fd) to head (e0413d7).
⚠️ Report is 428 commits behind head on development.

Additional details and impacted files

@@               Coverage Diff                @@
##           development     #308       +/-   ##
================================================
- Coverage        71.66%   19.87%   -51.79%     
================================================
  Files               40       42        +2     
  Lines             4524    18084    +13560     
================================================
+ Hits              3242     3594      +352     
- Misses            1282    14490    +13208     

☔ 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.

[RDaxini]

@martin-springer not urgent but do you have any idea why your commit 25fa88a shows up in this PR, and why codecov thinks the branch is out of sync with development? #308 (comment)
This branch is (as far as I can tell) up to date with development

[martin-springer]

@martin-springer not urgent but do you have any idea why your commit 25fa88a shows up in this PR, and why codecov thinks the branch is out of sync with development? #308 (comment) This branch is (as far as I can tell) up to date with development

@RDaxini - I'm not sure why this commit shows up. Doesn't look like there's anything in the files changed.

[RDaxini]

@martin-springer not urgent but do you have any idea why your commit 25fa88a shows up in this PR, and why codecov thinks the branch is out of sync with development? #308 (comment) This branch is (as far as I can tell) up to date with development

@RDaxini - I'm not sure why this commit shows up. Doesn't look like there's anything in the files changed.

@martin-springer it looks like development is one commit behind main—the commit that pushed development into main via #306 is the missing commit.

Run: git log development..main --oneline
You will see: 25fa88ae (origin/main, origin/HEAD, main) Merge pull request #306 from NREL/development

So I think we need to do a back-merge and update development with main. I have tried with #309 by creating a branch based on development, and updating it from main. If we merge this PR (back) into development, I think it will fix the issue.

[RDaxini]

@Trenton-Wells check #310, is there anything else we should add to the checklist?

[RDaxini]

Question/suggestion:
Is it practical to have a single file of 20,000+ lines? This could be difficult to maintain. Perhaps we should create an pvdeg\ftir folder, inside of which we can break up this file into multiple files.
I'm not super familiar with all of this code but maybe restructuring in the following way would be a start:

pvdeg/
├── ftir/
│   ├── __init__.py          # required
│   ├── core.py              # Core utilities/helpers
│   ├── io.py                # File I/O operations (rename_files, extract_file_info, etc.)
│   ├── baseline.py          # Baseline correction functionality
│   ├── normalization.py     # Normalization operations
│   ├── peak_analysis.py     # Peak finding and deconvolution
│   ├── fitting.py           # Material fitting operations
│   ├── visualization.py     # Plotting functions
│   ├── ui.py                # UI widgets and helpers (quality controls, etc.)
│   └── materials.py         # materials.json handling

[martin-springer]

Question/suggestion: Is it practical to have a single file of 20,000+ lines? This could be difficult to maintain. Perhaps we should create an pvdeg\ftir folder, inside of which we can break up this file into multiple files. I'm not super familiar with all of this code but maybe restructuring in the following way would be a start:

pvdeg/
├── ftir/
│   ├── __init__.py          # required
│   ├── core.py              # Core utilities/helpers
│   ├── io.py                # File I/O operations (rename_files, extract_file_info, etc.)
│   ├── baseline.py          # Baseline correction functionality
│   ├── normalization.py     # Normalization operations
│   ├── peak_analysis.py     # Peak finding and deconvolution
│   ├── fitting.py           # Material fitting operations
│   ├── visualization.py     # Plotting functions
│   ├── ui.py                # UI widgets and helpers (quality controls, etc.)
│   └── materials.py         # materials.json handling

Agreed, 20,000 lines in a single file is too much. A submodule structure seems like an appropriate strategy.

A good rule of thumb is to keep files under 1000 lines. Nowadays, some people argue even less with AI agents: https://medium.com/@eamonn.faherty_58176/right-sizing-your-python-files-the-150-500-line-sweet-spot-for-ai-code-editors-340d550dcea4

It seems like there are also some individual functions that have more than 1000 lines of code by themselves. Those should be broken up as well. This will be hard to maintain.

This is what Gemini suggests:

Common Developer Averages | 5–15 lines
"Clean Code" recommendations | ~20 lines
Static Analysis Tools (e.g., Datadog) | Maximum of 200 lines (often configurable)

I'm not saying we need to bring it down to 15 lines as small functions have downsides as well (https://copyconstruct.medium.com/small-functions-considered-harmful-91035d316c29) but more than a 1000 lines is simply too long.