Expose generate_velocity_model_parameters so that you do not have to write to realisation

[lispandfound]

Simple change. Currently the only way to generate a domain is first write a realisation file and then execute the generate velocity model parameters script. This small refactor changes this so that domain generation can be invoked with simple realisation objects and without JSON serialisation.

[gemini-code-assist]

Summary of Changes

Hello @lispandfound, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the process of generating velocity model parameters by decoupling the core computation logic from file input/output operations. The primary function responsible for this generation now directly accepts necessary configuration objects and returns the computed domain parameters, promoting a more modular and testable design. A new command-line entrypoint has been added to maintain the existing file-based workflow, which now orchestrates the data loading, calls the refactored core function, and handles the result persistence. This enhancement streamlines the parameter generation process, making it more flexible for integration into various workflows.

Highlights

• Refactored Function Signature: The generate_velocity_model_parameters function has been refactored to accept configuration objects directly as arguments (e.g., SourceConfig, VelocityModelParameters, RupturePropagationConfig, Rakes, Magnitudes) instead of a file path.
• Decoupled File I/O: The refactored generate_velocity_model_parameters function no longer handles file reading or writing, making it a pure computation function that returns a DomainParameters object.
• New CLI Entrypoint: A new main function has been introduced as the command-line interface entrypoint. This function now handles reading from and writing to the realisation file, acting as a wrapper around the refactored core logic.
• Improved Reusability: This change allows for programmatic invocation of domain generation without requiring intermediate JSON serialization to a file, enhancing the reusability of the core logic.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors generate_velocity_model_parameters.py to separate the core logic from file I/O. The generate_velocity_model_parameters function is now a pure function, taking configuration objects as arguments and returning DomainParameters. This is a great improvement for testability and reusability. A new main function handles the command-line interface aspects, including reading from and writing to the realisation file. The changes are well-structured and clear. I've identified a couple of areas for improvement: an inefficiency in how the realisation file is read multiple times, and a minor inaccuracy in a docstring. Addressing these would make the implementation even more robust.

[Copilot]

Pull request overview

This PR refactors the generate_velocity_model_parameters module to separate the core domain generation logic from file I/O operations. The refactoring enables programmatic use of domain generation with in-memory configuration objects, removing the requirement to serialize realisation data to JSON files before invoking domain computation.

Key Changes:

• Extracted core domain computation logic into a library function generate_velocity_model_parameters that accepts configuration objects as parameters and returns DomainParameters
• Created a new main function that preserves the original CLI behavior by reading from realisation files, calling the refactored function, and writing results back
• Removed duplicate code that was redundantly reading rakes configuration from the realisation file

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[claudio525]

I think it would be a good idea to put this into a module instead of leaving it as part of the script?

[lispandfound]

Closed in favour of #83 which also includes the rrup simplification.