feat: Write the full NPresult to file

[mhovd]

For single-file parsing by Pmetrics and other software.

Work in progress.

[mhovd]

Note to self: consider using polars to write a .parquetfile, which is a binary format that can be read with R using arrow.

[Copilot]

Pull request overview

This PR adds functionality to serialize and write the complete NPResult structure to a JSON file for consumption by Pmetrics and other external tools. The PR is marked as "Work in progress."

Changes:

• Added a new write_json() method to NPResult that serializes the entire structure to a JSON file
• Updated the bimodal_ke example to demonstrate usage of the new method
• Added result.json to .gitignore to exclude generated output files

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/routines/output/mod.rs	Added write_json() method that serializes NPResult to JSON using serde_json
examples/bimodal_ke/main.rs	Added call to write_json() after writing standard outputs
.gitignore	Added result.json to ignored files list

---

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

[Copilot]

The method signature uses &mut self, but the method doesn't mutate any fields of the struct - it only serializes the current state. Based on the documentation comment stating this method will not calculate predictions automatically, and the pattern used by other non-mutating write methods like write_theta and write_covs, this should use &self instead of &mut self.

Suggested change

	pub fn write_json(&mut self) -> Result<()> {
	pub fn write_json(&self) -> Result<()> {

[mnneely]

Hi @mhovd , does this change how Pmetrics needs to parse the output from PMcore?

[mhovd]

Hi @mhovd , does this change how Pmetrics needs to parse the output from PMcore?

Possibly - for now it will be written in addition to the "regular" files.
There are some advantages of a single file:

• Only need to parse one file
• We can stuff more information into it, e.g. the support points for each cycle, metadata, all settings, etc. Maybe even the model if we can write it in a manner that can be read back in.

Disadvantages:

• Not human readable, so needs to be parsed from JSON.
• Possibly larger footprint, depending on what we include in it.

Open to suggestions and feedback!

[mnneely]

OK. Where’s the best place to grab/understand the schema? Reading json into R is easy enough. Lack of human readability isn’t a problem, as long as we provide an easy way for humans to read it, either through R or the GUI.

My motivation for it would be to increase speed, stability, and ease of extracting additional information in the future, although I have not heard any requests for more information from users. If it would help unify output from parametric vs. nonparametric algorithms into a single structure, that would be another advantage.