To align with how the global time barrier in HELICS operates, we need to have two time fields in the debug view:
"last executed"
"next granted"
The user will be able to define the "next granted" time as this is the time that the global time barrier stops at. The "last executed time" needs to be filled in by the web interface by making a query on the federation (broker - global_time) which returns a JSON with the last granted time for all federates. The maximum time found in this JSON is the time the federation just got done executing. This "last executed" field should not be editable by users.
A "advance to next granted time" button will allow users to advance to the indicated "next granted" time.
@phlptp and I discussed this and he's going to be working on two APIs for this: one will be a query that will return a JSON with the next time to be granted and the federate(s) that will be granted this time. The other will be an API to advance the co-simulation to the next granted time look for these in mid-August 2020.
To align with how the global time barrier in HELICS operates, we need to have two time fields in the debug view:
The user will be able to define the "next granted" time as this is the time that the global time barrier stops at. The "last executed time" needs to be filled in by the web interface by making a query on the federation (
broker-global_time) which returns a JSON with the last granted time for all federates. The maximum time found in this JSON is the time the federation just got done executing. This "last executed" field should not be editable by users.A "advance to next granted time" button will allow users to advance to the indicated "next granted" time.
@phlptp and I discussed this and he's going to be working on two APIs for this: one will be a query that will return a JSON with the next time to be granted and the federate(s) that will be granted this time. The other will be an API to advance the co-simulation to the next granted time look for these in mid-August 2020.