Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logging / reporting processes #16

Open
kris-brown opened this issue May 16, 2024 · 1 comment
Open

Logging / reporting processes #16

kris-brown opened this issue May 16, 2024 · 1 comment

Comments

@kris-brown
Copy link
Collaborator

AKA epiphenomena: we presently store almost all the data of the run, expecting it to be processed after the fact. This approach will eventually not be able to scale, so we should consider offering the user a syntax for saying what should get logged in real time as the model runs.

One approach for logging for specific rewrite rules is to embed the pattern in some larger context $L \hookrightarrow Ctx$, and we pick out a subset $Log \hookrightarrow Ctx$ which is the relevant values to log (this latter mono might preferably be a map in $C$-Par, since it may not be a proper subobject) whenever the rewrite fires (the $Log$ subset of data of all maps $Ctx\rightarrow World$ that make the triangle (with a match $L \rightarrow World$) commute.

One approach for general logging after any step is to give patterns and report the counts (or the data of all matches) of that pattern in each resulting state of the world.

The partial maps induced by rewrites give us the ability to have the full trajectory, but we should come up with means of getting longitudinal data that may be smaller than the entire trajectory.

@wwaites
Copy link

wwaites commented May 17, 2024

Reporting at every simulation step might well be too frequent. Often you want coarse reporting time (e.g. one simulation day) and there are many thousands of events between reporting times.

Computing the counts to report can be costly so even though you might be able recompute all the observables after every step and only save them periodically, in practice that can be wasteful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants