Release Cycle, June 2025

[TimothyWillard]

Description

This PR is a running accumulation of changes to merge from dev into main that will be merged at a to be decided release cycle.

News

New Features

• API reference documentation for gempyor produced with Sphinx, Gempyor sphinx documentation #550.
• Simplified installation, especially for local installs, with the bin/flepimop-install script, flepimop-install Script #546.
• Support for syncing the results of flepimop batch-calibrate on batch job finish with --sync-protocol, Add sync For Saving Model Outputs To batch-calibrate #554.
• Auto-generating (with GH workflow) markdown documentation for click interface, Click documentation #545

Bug Fixes

• flepimop-calibrate now works with --nwalkers=1, Address flepimop-calibrate error when --nwalkers = 1 #556.
• flepicommon has migrated away deprecated covidcast and to epidatr, Migrate flepicommon from deprecated covidcast to epidatr #571
• Identical config paths provided through CLI argument and option will be reconciled; error thrown if not. Add clause to reconcile config paths if they are the same #565

Notes

• Refactored gempyor.subpopulation_structure.SubpopulationStructure, Subpopulation Structure Refactor #549.

[anjalika-nande]

slight typo -- set to the branch 'you are' working with..

[TimothyWillard]

Good catch, corrected in bcd0ab1

[anjalika-nande]

Just found a minor typo in the documentation that I commented on but otherwise seems good

[saraloo]

Thanks! Not sure if I'm doing things wrong, but was trying to test the sync protocol thing following the instructions, but have reached this error...

ValueError: Exactly one config file source option must be provided; got {'config_files': (PosixPath('config_sample_2pop_inference.yml'), PosixPath('/scratch4/struelo1/flepimop-code/sloo2/flepiMoP/common/s3-idd-inference-runs.yml')), 'config_filepath': (PosixPath('/scratch4/struelo1/flepimop-code/sloo2/flepiMoP/examples/tutorials/config_sample_2pop_inference.yml'),)}.

I think maybe I had something like this before - in the step where I run
./batch/hpc_init rockfish
it asks for a config path so I provide one, but then when I then go to run the command in the documentation in line 272 in documentation/gitbook/how-to-run/advanced-run-guides/running-on-a-hpc-with-slurm.md
I get the above error. Am I doing something wrong here?

[TimothyWillard]

Thanks! Not sure if I'm doing things wrong, but was trying to test the sync protocol thing following the instructions, but have reached this error...

ValueError: Exactly one config file source option must be provided; got {'config_files': (PosixPath('config_sample_2pop_inference.yml'), PosixPath('/scratch4/struelo1/flepimop-code/sloo2/flepiMoP/common/s3-idd-inference-runs.yml')), 'config_filepath': (PosixPath('/scratch4/struelo1/flepimop-code/sloo2/flepiMoP/examples/tutorials/config_sample_2pop_inference.yml'),)}.

I think maybe I had something like this before - in the step where I run ./batch/hpc_init rockfish it asks for a config path so I provide one, but then when I then go to run the command in the documentation in line 272 in documentation/gitbook/how-to-run/advanced-run-guides/running-on-a-hpc-with-slurm.md I get the above error. Am I doing something wrong here?

What is the output of echo $CONFIG_PATH? If the output is non-empty then you likely need to run unset CONFIG_PATH. The issue is coming from the conflicting configuration files being provided to the patch functionality, the option pulls from the environment variable if set and a value is not provided and the arguments use what is given. The batch/hpc_init command has an option to skip setting this environment variable as well.

[saraloo]

Okay thanks. I don't think that's clear from the documentation, so if it's just made explicit, or some other work around determined later that would be helpful. If we are essentially always going to be patching during a batch run (in order to save things to S3 for records), but always setting a CONFIG_PATH in the initialisation step, then this seems redundant. Fine to approve this for now though, but just a thought for later.

[TimothyWillard]

Okay thanks. I don't think that's clear from the documentation, so if it's just made explicit, or some other work around determined later that would be helpful. If we are essentially always going to be patching during a batch run (in order to save things to S3 for records), but always setting a CONFIG_PATH in the initialisation step, then this seems redundant. Fine to approve this for now though, but just a thought for later.

Yeah, that makes since. To clarify, with the batch/hpc_init script, is the "press enter to skip" option not working as expected or do you want to remove setting $CONFIG_PATH all together?

[saraloo]

No, the press enter to skip is clear, and for our previous usage $CONFIG_PATH was a necessary variable. But it's not clear to me whether it's needed in the new setup or instructions with the patching capabilities and since in all the set up examples the config is explicitly written in the commands.

What would be easiest from an operational point of view is for all these to just be set up in an initialisation script, and then some line of command written somewhere that can be copy-pasted, for example, for all flu forecasts without having to edit etc. Fine to be instructed otherwise, just the instructions are unclear here I think (probably because we have not operationalised this use yet? and might also be missing something in the markdown documentation).

Something more akin to the workflow that we had before was to just set a config, and then it read all the other information from the config and we were able to just run the job launcher script and it would populate the equivalent batch-calibrate command for us. As far as I can tell this isn't how it would now work - it would require more tweaking and manual edits to the actual command? Again, i'm fine with this for now, and I probably just need to test it out more on some actual runs to have a more formed opinion, but just flagging that having instructions to initialise a config in the init, then needing to unset it in order to patch a config (which should become pretty standard practice if we want to enforce this sync system) seems odd.

[TimothyWillard]

No, the press enter to skip is clear, and for our previous usage $CONFIG_PATH was a necessary variable. But it's not clear to me whether it's needed in the new setup or instructions with the patching capabilities and since in all the set up examples the config is explicitly written in the commands.

What would be easiest from an operational point of view is for all these to just be set up in an initialisation script, and then some line of command written somewhere that can be copy-pasted, for example, for all flu forecasts without having to edit etc. Fine to be instructed otherwise, just the instructions are unclear here I think (probably because we have not operationalised this use yet? and might also be missing something in the markdown documentation).

Something more akin to the workflow that we had before was to just set a config, and then it read all the other information from the config and we were able to just run the job launcher script and it would populate the equivalent batch-calibrate command for us. As far as I can tell this isn't how it would now work - it would require more tweaking and manual edits to the actual command? Again, i'm fine with this for now, and I probably just need to test it out more on some actual runs to have a more formed opinion, but just flagging that having instructions to initialise a config in the init, then needing to unset it in order to patch a config (which should become pretty standard practice if we want to enforce this sync system) seems odd.

Ah, okay, I think I understand the pain point here now. I've created #576 to carry on this discussion & work. To clarify the confusion about $CONFIG_PATH directly though, it is not necessary to set it to use flepimop batch-calibrate. In fact, I would go as far as to recommend not setting it as setting that environment variable only allows for using one configuration file which inhibits patching as you demonstrated earlier. I added this note to the documentation in 9ac1bd3.

[pearsonca]

good work.