Question-and-Answer Resource for the Building Energy Modeling Community
Get s tarted with the Help page
Ask Your Question

Revision history [back]

Runtime API: issues with multiple runs and threading

Hi again,

I am having trouble using the new Runtime API (E+ version 9.4.0) in scenarios where multiple runs involving different threads are required such as training processes for reinforcement learning agents. My feeling is that there may be some issues with recent state manager features and its threading support. I will be providing a series of problematic usage scenarios to foster discussion and make issues visible - either in the API or in my understanding of it.

Scenario 1 - Concurrent runs using multiple threads using same API object

Using a single API instance to manage multiple runs can be problematic as executing a api.state_manager.reset_state while an execution is in progress causes an access violation - see eplus_test_threading_example1.py. Although this approach works well with sequential multiple runs, it is reasonable that it doesn't support multiple concurrent runs.

image description

However, I would have expected that the API supports creating multiple handles (api.state_manager.new_state) - one for each run. Unfortunately, when I try this I get a SetupTimePointers error (see example in eplus_test_threading_example1bis.py). Thus, my guess is that a single API instance cannot deal with multiple concurrent runs.

image description

Scenario 2 - Concurrent runs using multiple threads using different API objects

This scenario tries to overcome limitations by using different instances of the API - that is, one for each run. For this purpose I created a dictionary to associate the context (state) with the appropriate API object - see example in eplus_test_threading_example2.py), and some stuff to manage concurrency and locking. As in the case above, the approach doesn't work well with concurrency. I tried even to create different output folders in case there were some clashes processing outputs with little success. I also attach outputs for a 1 instance successful run vs output from a failed test with 2 instances. Errors also varied - let me attach a couple of examples. image description

image description

I am opening a ticket in E+ support website but any help and support are welcome.

Best regards,

Runtime API: issues with multiple runs and threading

Hi again,

I am having trouble using the new Runtime API (E+ version 9.4.0) in scenarios where multiple runs involving different threads are required such as training processes for reinforcement learning agents. My feeling is that there may be some issues with recent state manager features and its threading support. I will be providing a series of problematic usage scenarios to foster discussion and make issues visible - either in the API or in my understanding of it.

Scenario 1 - Concurrent runs using multiple threads using same API object

Using a single API instance to manage multiple runs can be problematic as executing a api.state_manager.reset_state while an execution is in progress causes an access violation - see eplus_test_threading_example1.py. Although this approach works well with sequential multiple runs, it is reasonable that it doesn't support multiple concurrent runs.

image description

However, I would have expected that the API supports creating multiple handles (api.state_manager.new_state) - one for each run. Unfortunately, when I try this I get a SetupTimePointers error (see example in eplus_test_threading_example1bis.py). Thus, my guess is that a single API instance cannot deal with multiple concurrent runs.

image description

Scenario 2 - Concurrent runs using multiple threads using different API objects

This scenario tries to overcome limitations by using different instances of the API - that is, one for each run. For this purpose I created a dictionary to associate the context (state) with the appropriate API object - see example in eplus_test_threading_example2.py), and some stuff to manage concurrency and locking. As in the case above, the approach doesn't work well with concurrency. I tried even to create different output folders in case there were some clashes processing outputs with little success. I also attach outputs for a 1 instance successful run vs output from a failed test with 2 instances. Errors also varied - let me attach a couple of examples. image description

image description

I am opening a ticket in E+ support website but any help and support are welcome.

Best regards,

Source code and logs can be obtained here: https://www.dropbox.com/s/ag4b1ocxxf7vgjm/Source-and-logs.zip?dl=0

Runtime API: issues with multiple runs and threading

Hi again,

I am having trouble using the new Runtime API (E+ version 9.4.0) in scenarios where multiple runs involving different threads are required such as training processes for reinforcement learning agents. My feeling is that there may be some issues with recent state manager features and its threading support. I will be providing a series of problematic usage scenarios to foster discussion and make issues visible - either in the API or in my understanding of it.

Scenario 1 - Concurrent runs using multiple threads using same API object

Using a single API instance to manage multiple runs can be problematic as executing a api.state_manager.reset_state while an execution is in progress causes an access violation - see eplus_test_threading_example1.py. Although this approach works well with sequential multiple runs, it is reasonable that it doesn't support multiple concurrent runs.

image description

However, I would have expected that the API supports creating multiple handles (api.state_manager.new_state) - one for each run. Unfortunately, when I try this I get a SetupTimePointers error (see example in eplus_test_threading_example1bis.py). Thus, my guess is that a single API instance cannot deal with multiple concurrent runs.

image description

Scenario 2 - Concurrent runs using multiple threads using different API objects

This scenario tries to overcome limitations by using different instances of the API - that is, one for each run. For this purpose I created a dictionary to associate the context (state) with the appropriate API object - see example in eplus_test_threading_example2.py), and some stuff to manage concurrency and locking. As in the case above, the approach doesn't work well with concurrency. I tried even to create different output folders in case there were some clashes processing outputs with little success. I also attach outputs for a 1 instance successful run vs output from a failed test with 2 instances. Errors also varied - let me attach a couple of examples. image description

image description

I am opening a ticket in E+ support website but any help and support are welcome.

Best regards,

Source code and logs can be obtained here: https://www.dropbox.com/s/ag4b1ocxxf7vgjm/Source-and-logs.zip?dl=0