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

Passing message back to user #142

Open
2 of 3 tasks
samvanderzwan opened this issue Jul 23, 2024 · 3 comments
Open
2 of 3 tasks

Passing message back to user #142

samvanderzwan opened this issue Jul 23, 2024 · 3 comments
Assignees

Comments

@samvanderzwan
Copy link
Contributor

samvanderzwan commented Jul 23, 2024

We need to pass the following back to the user:

  • message
  • percentage done
  • estimated remaining calculation time

@MichielTukker needs to define how we can pass messages back and in what format.

@MichielTukker MichielTukker self-assigned this Jul 24, 2024
@MichielTukker
Copy link
Contributor

This should currently be handled by the simulator-worker.

  • The messages are captured by the worker and passed to the front-end
  • the progress is monitored via a callback, I'll also add this to the simulation_manager

@MichielTukker
Copy link
Contributor

How often should we send progress back to the frontend?

Easiest (code-wise) is every timestep, but that may be a bit much.

@samvanderzwan @lfse-slafleur any opinions?

@lfse-slafleur
Copy link
Member

lfse-slafleur commented Jul 24, 2024

@MichielTukker I would say whenever it 'makes sense'. While with OMOTES in its current form we expect only human users to see the progress updates, that doesn't have to remain true. Human users will also interact with NWN-DTK through a frontend so I would argue that it is up to the frontend to make the output parseable for humans which provides the room for the simulator to send a progress update whenever it wants. However, a progress update is traffic that is handled by the orchestrator. Unless you are going to send multiple progress updates every second, I do not expect performance to become an issue.

Instead of timesteps, I would advise to think in percentages (a job is done when progress is 100%). Sending a progress update every .001% makes no sense of course, so I would expect that you should maximum send a progress update every 1%. Also sending a progress update every .1 second makes no sense. So I would argue sending a progress update max. every 1 second makes sense.

Assuming you are all agreeing so far, the logic could be something like:

timestamp_last_progress_update = 0
progress_updated = 0

for timestep in timesteps:
  if "duration since last progress update > 1 second" and (current_progress - progress_updated >= '1% since last progress update'):
    'do progress update'
    progress_updated = current_progress
    timestamp_last_progress_update = time.now()

The considerations here are OMOTES specific. So perhaps it makes sense to perform this logic in the simulator-worker and not in the core and let the core call progress_update_handler every timestep.

What do you all think?

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

No branches or pull requests

3 participants