Help to develop DiscreteEvents

[pbayer]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[pbayer]

DiscreteEvents now has been moved into JuliaDynamics and I hope this will mean more collaboration and contributions to its development.

Some of you, in particular @hdavid16, @filch, @dfish have shown interest in development and/or contributed in the past. So please join the discussion.

Questions

• What feature would you like to see implemented?
• What would improve its usability?
• What in your opinion should be done to improve DiscreteEvents?
• What could be an Ideal Final Result for DiscreteEvents?
• What are problems, contradictions, limitations that have to be solved and overcome?
• What can be done to improve the interaction with other Julia packages, especially those in JuliaDynamics?
• …

[hdavid16]

@pbayer, thank you for putting this together. I think a good suite of examples will really help adopting this package. I think it makes sense to move explanations and examples from DiscreteEventsCompanion over to this repository. What are your thoughts?

[pbayer]

@hdavid16, yes, that makes sense. Examples can also be used to illustrate different modelling approaches, as a test suite and for benchmarks.

[hdavid16]

Ideas of features to implement:

• preemption: Preempting jobs in a queue #53. Should DataStructures.jl or a different package be used to define a priority queue?
• remove scheduled events: Feature request: remove events from priority queue #34
• improve support for resources: Resource handling #21
• improve documentation: add examples showing how to use the different features in the documentation, rather than just docstrings and high level descriptions
  ...

[hdavid16]

Another idea, which would be breaking is to use syntax that is more intuitive to users: schedule instead of sc, conditional_events instead of cev. This goes for functions as well (Prc, tau, etc.).

It would also be valuable to have an API to view for instance the processes registered to a clock's schedule. This would depend on how much of the internals should be exposed to users.

[pbayer]

I may be a little biased on this point. I would imagine that verbose names make it easier for new users to work with DiscreteEvents, but more cumbersome for experienced users.

But since most examples are slim, they would gain from verbose names and then be more reminiscent of natural language than mathematics.

Do you think it would be worth moving to a more intuitive syntax? For a transitional period, we could work with alias names and then gradually abandon the old syntax.

Perhaps other readers could also comment on this.

[pbayer]

The second point (Viewer API) reminds me of Erlang. They have something like a process monitor. It would be quite an effort to write something like that. But it could be useful for debugging. Maybe that would be a key for more extensive simulations (eg. plants and supply chains).

[hdavid16]

Regarding the viewer API, I mean having helper functions to access the internals of say a clock. Something like get_process(clk, id) instead of having to do clk.sc.processes[id]. This way, changes to the internals do not concern users because there is an API to access the information that is relevant.

I find that Julia packages tend to have more verbose syntax that is more intuitive. This helps avoid having to look at the source code frequently to check what the field acronyms mean.