Right now we are using Case objects to define commands and symbols. Instead, convert the Command trait into a class. This way we can dynamically create event sets. This should also make it easier to save and reload models.

Should we remove all the forbidden states as done here: https://github.com/ashfaqfarooqui/ModelBuilding/blob/67f7e8cd4b148aaaeedf2f7c8acb9d6b41f78e7c/src/main/scala/modelbuilding/solvers/FrehageModularSupSynthesis.scala#L263

This "might" cause an issue when we reuse the modules to calculate the other supervisors?

To decrease the workload of the learning algorithm we can:

• Write only required (changing) values instead of all values;
• Do not execute a whole reset but only reset certain variables.

currently, a state is marked forbidden only if it is uncontrollable. We should also mark all states the spec marks as forbidden, just like we do for accepting.

New solver to speed up things

Usecase: Caching on membership queries is currently cached. But this will break for dynamic membership queries. It would be good to have a switch to enable/disable caching.

It then becomes important to correctly configure the switch.

To be able to use supremica automata to simulate behavior of models.

Use case, to run large models. Eg Cascaded transferline.

Right now findCE method in CEGenerator takes observation table as input. Make this more general to allow other algorithms to implement CEGenerator. https://github.com/ashfaqfarooqui/ModelBuilding/blob/78956d7a7885b2cbf2d082f537b3887b682d0c32/src/main/scala/modelbuilding/algorithms/EquivalenceOracle/CEGenerator.scala#L12

Clean up files so merging branches no longer cause issue. Atlease as it is now....plus add some documentation on each of the method available

It should be possible to save the current state of learning and then continue from there later...It seems to be trickier than thought. Need some kind of pickling and to create case objects...

Separate out the core models from the modeling part. the core can then be provided as a library in itself.

References to directories like in https://github.com/ashfaqfarooqui/ModelBuilding/blob/178a261ec4b427af926ab82aa7d1fa31abe6c61e/src/main/scala/modelbuilding/models/CatAndMouseModular/CatAndMouseModularSpecification.scala#L6 need to be handled in a way that it works on windows as well as linux.

If selfloops are added in specifications, the supervisor does not contain all states and transitions. This probably has to deal something with the maximum number of states in LStarSuprSolver or the number of counterexamples in Wmethod.

The updated Wmethod https://github.com/ashfaqfarooqui/ModelBuilding/blob/e71cf16486fed10064e6dafe3aaa54add18c56ff/src/main/scala/modelbuilding/solvers/LStarPlantSolver.scala#L15
is not needed. We can revert back to the old way of doing it.

Duplicate of #23.

Right now we write the complete state to the opc, instead write only what values changed to make it more efficient.

As pointed out by @ramontijsseclaase
Finaltable.txt

I already noticed this weekend, but forgot to mention: The final observation table has the wrong order of sets E (columns). In the result this order is:

Tau – load1,tau – unload2,load2-tau – unload2,tau – load2,tau

But the corresponding values show that this order should be:

Unload2,load2,tau – load1,tau – load2,tau – unload2,tau – tau.

I attached the observation table to this email.

We need to think about how we reset the simulator. Right now, before a new sequence, we reset it. Instead, do it, maybe, as part of the sequence.

Include visualization as part of the package.
Viz can be used for Automata and also other data structures like DT if needed.

Right now we generate DOT and rely on external software. It would be good to be self-contained in some way. Maybe a visualization server?