FlepiMoP "Vocabulary"

[pearsonca]

In terms of a non-insider user, what the concise set of verbs / nouns we want them to think in terms of? As "verbs", we currently have

• the python entry points:
  • gempyor-outcomes: translated latent states into observed outcomes
  • gempyor.cli: a meta-entry point, intended to provide overall flepimop context for commands, ala git and push, pull etc - however, only currently includes compartments
  • gempyor-seir: latent-state simulation only
  • gempyor-simulate: latent-state + observation / outcome process simulation
  • flepimop-calibrate: inference with emcee
• the R "entry points"
  • flepimop-inference-(main|slot): inference with R-based approach
  • create_seeding(_added)*: configuration / initial conditions creation
  • seir_init_immuneladder: configuration / initial conditions creation
  • post / preprocessing scripts: ...?
• meta entry points:
  • hpc_install.sh etc - tool setup and management
• notional verbs that we want, but don't really have:
  • validate: checking configuration files
  • parse / build / ...? translation of configuration files into models, pipelines, ...?
  • "sample" from conditions described in the config?
  • "sample" but, from model + parameter distributions

Our nouns also seem a bit murkier.

• config is obviously a thing, but it seems to encompass too many configuration definitions
• project? a collection of configs
• output is also obviously a thing, but again has too many definitions
• inputs, of various flavors

[pearsonca]

From in-office chat w/ @jcblemai : configs seem to be the noun, in the sense that most (all?) of our verbs require a config. Given that, seems reasonable to change -c (and friends) argument into the stdin slot for the relevant verbs. Longer term, this could enable chaining / piping of commands in a natural way.

[saraloo]

At present, we have a clear distinction between flepimop as the pipeline and gempyor, which can be used to forward simulate standalone.

Do we want to keep this modular, in terms of having flepiMoP refer to the piping of individual config sections and pre and post processing, and gempyor to remain related to simulating a model? If so, I think gempyor should relate to the actual seir and outcome simulating, and flepimop verbiage relating to calibration (by either method), and any tools for inputs (ie generating seeding etc? though i might also argue that these are too specific to the application and should be dealt with by the user instead in a separate repo. eg i think the create seeding and seir_init scripts should really be in the COVID repos...).

I don't necessarily have a strong opinion either way as I can see pros for both, but raising it for discussion.

[pearsonca]

as noted in the PR thread, I agree that we want flepimop as that pipeline. Forward simulation is definitely a part of any reasonable pipeline (as is inference, but forward simulation + inference are to me themselves only incremental parts of a pipeline), so we ought to be thinking about how to pass a use-gempyor-for-forward-simulation indicator to that pipeline + modularizing gempyor as a forward simulator.

[pearsonca]

rattling around some compositional verbs:

• project = given inputs, produce outputs (maybe latent state, maybe observed)
• observe = given (latent) outputs, produce observation results (for the case where observation outcomes have no effect on dynamics, can be done as post-processing)
• evaluate = compare outputs to target
• inference = iterative project, evaluate, project, ...
• validation = project + interference => check ability of inference to recover projection inputs
• scenario = project, given mix of shared and distinguishing parameters
• model selection = scenario + inference + some other kind of evaluation?
• score = project + evaluate