Added section describing repository audience

[Subhransu37]

Description

Added a new section in the README titled “Who is this repository for?”.

This section helps new users quickly understand the target audience of Neural-LAM and how beginners can get started with the project.

Type of change

📖 Documentation improvement

Type of change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📖 Documentation (Addition or improvements to documentation)

Checklist before requesting a review

• My branch is up-to-date with the target branch - if not update your fork with the changes from the target branch (use pull with --rebase option if possible).
• I have performed a self-review of my code
• For any new/modified functions/classes I have added docstrings that clearly describe its purpose, expected inputs and returned values
• I have placed in-line comments to clarify the intent of any hard-to-understand passages of my code
• I have updated the README to cover introduced code changes
• I have added tests that prove my fix is effective or that my feature works
• I have given the PR a name that clearly describes the change, written in imperative form (context).
• I have requested a reviewer and an assignee (assignee is responsible for merging). This applies only if you have write access to the repo, otherwise feel free to tag a maintainer to add a reviewer and assignee.

Checklist for reviewers

Each PR comes with its own improvements and flaws. The reviewer should check the following:

• the code is readable
• the code is well tested
• the code is documented (including return types and parameters)
• the code is easy to maintain

Author checklist after completed review

• I have added a line to the CHANGELOG describing this change, in a section
  reflecting type of change (add section where missing):
  • added: when you have added new functionality
  • changed: when default behaviour of the code has been changed
  • fixes: when your contribution fixes a bug
  • maintenance: when your contribution is relates to repo maintenance, e.g. CI/CD or documentation

Checklist for assignee

• PR is up to date with the base branch
• the tests pass
• (if the PR is not just maintenance/bugfix) the PR is assigned to the next milestone. If it is not, propose it for a future milestone.
• author has added an entry to the changelog (and designated the change as added, changed, fixed or maintenance)
• Once the PR is ready to be merged, squash commits and merge the PR.

[kshirajahere]

@Subhransu37 The PR description still contains some of the template placeholder text, and there is no linked issue/task yet. It would help reviewers if the final body only kept the actual motivation/scope for this README change.

[Subhransu37]

@Subhransu37 The PR description still contains some of the template placeholder text, and there is no linked issue/task yet. It would help reviewers if the final body only kept the actual motivation/scope for this README change.

Thank you for the feedback. I have cleaned up the PR description.

[sadamov]

@Subhransu37 I am a bit conflicted about this suggestion, because mllam has evolved a lot over time. It has been used for ocean and space modeling, as well as high res simulation of eddies and more. I think I prefer having a clear and well strucured docs #252 / #61 instead of defining a target audience. Then everyone can decide for themselves if mllam is useful to them. Leaving this open as a draft for discussion with @joeloskarsson and @observingClouds.

[observingClouds]

I agree with you @sadamov. We could rather add a Publication section, where we can list work done with neural-lam, so that new users see what the repo has been used for.

[observingClouds]

Thanks for this PR. Based on the comments, we would rather like to have a section about publications that used neutral-lam than describing the audience explicitly.

[HetaviM29]

Hi, I’ve been following this discussion.
Based on the suggestion to replace the audience section with a Publications section, I’d like to work on adding a structured Publications & Applications section in the README. I’m planning to organize it by application domains and include short descriptions for clarity.Does this approach align with your expectations?

[observingClouds]

Just a publication section is all we need. Let's give @Subhransu37 a chance to adjust their PR though.