Open IamAniket12 opened 2 months ago
I attempted to run the singlezone_commercial_hydronic
testcase using the quick start code on the server, but encountered the same error.
Code:
from boptestGymEnv import (BoptestGymEnv, NormalizedActionWrapper,
NormalizedObservationWrapper, SaveAndTestCallback,DiscretizedActionWrapper)
# url for the BOPTEST service.
url = 'https://api.boptest.net'
# Decide the state-action space of your test case
env = BoptestGymEnvCustomReward(
url=url,
testcase="singlezone_commercial_hydronic",
actions=["oveValCoi_u"],
observations={
"time": (0, 31536000),
"reaTZon_y": (280.0, 310.0),
"reaCO2Zon_y": (200.0, 2000.0),
"PriceElectricPowerHighlyDynamic": (-0.4, 0.4),
"LowerSetp[1]": (280.0, 310.0),
"UpperSetp[1]": (280.0, 310.0),
"UpperCO2[1]": (0, 10000),
},
scenario={"electricity_price": "highly_dynamic"},
predictive_period=24 * 3600,
random_start_time=True,
excluding_periods=[
(173*24*3600, 266*24*3600)
],
max_episode_length=14*24*3600,
step_period=3600,
warmup_period=7*24*3600
)
env = NormalizedObservationWrapper(env)
# Normalize observations and discretize action space
env = NormalizedObservationWrapper(env)
env = DiscretizedActionWrapper(env,n_bins_act=20)
# Instantiate an RL agent
model = DQN('MlpPolicy', env, verbose=1, gamma=0.99,
learning_rate=5e-4, batch_size=24,
buffer_size=365*24, learning_starts=24, train_freq=1)
# Main training loop
model.learn(total_timesteps=1000)
# Loop for one episode of experience (one day)
done = False
obs, _ = env.reset()
while not done:
action, _ = model.predict(obs, deterministic=True)
obs,reward,terminated,truncated,info = env.step(action)
done = (terminated or truncated)
# Obtain KPIs for evaluation
env.get_kpis()
Can you report the input you were overwriting and the value you overwrote at the step the simulation failed? Even better would be the sequence of values from the start of your simulation to the time the simulation stops.
Noting that there are a couple open issues in the boptest repo (https://github.com/ibpsa/project1-boptest/issues/432 and https://github.com/ibpsa/project1-boptest/issues/635) related to this test case which could cause issues in the simulation numerics in certain situations of control. Have not addressed those issues yet but still on the list. These may or may not be related to your issue.
I experimented with the variables ahu_oveFanSup_u
, oveValCoi_u
, and oveValRad_u
. I tried controlling them together and separately, as well as in continuous and discrete modes. The simulation runs for a variable number of iterations - sometimes it works for thousands of iterations before failing. However, it eventually encounters an error in all cases. Interestingly, in the single_commercial_hydronic
testcase, the code works fine when I attempt to control oveTSupSet_u
, oveTZonSet_u
, and oveCO2ZonSet_u
.
Here are the last four overwritten inputs.
{'ahu_oveFanSup_u': 1.0, 'ahu_oveFanSup_activate': 1.0, 'oveValCoi_u': 1.0, 'oveValCoi_activate': 1.0, 'oveValRad_u': 0.21339374780654907, 'oveValRad_activate': 1.0}
{'ahu_oveFanSup_u': 0.0, 'ahu_oveFanSup_activate': 1.0, 'oveValCoi_u': 0.07432644069194794, 'oveValCoi_activate': 1.0, 'oveValRad_u': 1.0, 'oveValRad_activate': 1.0}
{'ahu_oveFanSup_u': 0.2755994498729706, 'ahu_oveFanSup_activate': 1.0, 'oveValCoi_u': 0.0, 'oveValCoi_activate': 1.0, 'oveValRad_u': 0.0, 'oveValRad_activate': 1.0}
{'ahu_oveFanSup_u': 0.0, 'ahu_oveFanSup_activate': 1.0, 'oveValCoi_u': 0.0, 'oveValCoi_activate': 1.0, 'oveValRad_u': 0.0, 'oveValRad_activate': 1.0}
Thanks for those values. We'll consider this issue with the others regarding this test case.
Do you mean your code works fine for bestest_hydronic_heat_pump
? That is a different system representation with different model equations and numerics than this one, and is a bit simpler. So might simulate more robustly to different control inputs at the moment.
Thank you for your response. Yes, I have run the provided script from the examples folder for bestest_hydronic_heat_pump
on a local server, and it worked.
Oh I'm re-reading your comment. The code might work fine for controlling using oveTSupSet_u, oveTZonSet_u, and oveCO2ZonSet_u because those are set points, which serve embedded feedback controllers that are responsible for controlling actuators (valves and fans). But controlling the set of ahu_oveFanSup_u, oveValCoi_u, and oveValRad_u are controlling the actuators themselves and may bypass safety measures present in embedded feedback controllers. Would need to check exactly what's going on in this case. But generally, that's a risk in a real building too. You might have more controllability directly controlling actuators, but that could bypass safeties that prevent things like equipment cycling, turning on a pump when all valves are closed, freezing cooling coils due to low air flow, etc.
Thanks for clarifying, it makes sense.
I tried using oveTSupSet_u
, oveTZonSet_u
, and oveCO2ZonSet_u
, but the issue still persists. The server crashed with the same error after 400k time steps.
How long is each time step and what's your starting time? Better to think in terms of time since then we can diagnose with help from time of day (maybe related to schedules), time of year (maybe related to climate), etc.
Here are the environment details I tested.
env = BoptestGymEnvCustomReward(
url=url,
actions=["oveCO2ZonSet_u", "oveTSupSet_u", "oveTZonSet_u"],
observations={
"time": (0, 31536000),
"reaTZon_y": (280.0, 310.0),
"reaCO2Zon_y": (200.0, 2000.0),
"PriceElectricPowerHighlyDynamic": (-0.4, 0.4),
"LowerSetp[1]": (280.0, 310.0),
"UpperSetp[1]": (280.0, 310.0),
"UpperCO2[1]": (0, 10000),
"TDryBul": (280.0, 320.0),
},
scenario={"electricity_price": "highly_dynamic"},
predictive_period=24 * 3600,
random_start_time=True,
excluding_periods=[(173 * 24 * 3600, 266 * 24 * 3600)],
max_episode_length=14 * 24 * 3600,
step_period=3600
)```
@javiarrobas Is it true that step_period
is control step, which looks like is set to 3600s? Therefore, is it true that @IamAniket12's server crash at 400k steps is at 45.6 years of simulation time? If this is true, 1) that seems like an unreasonable amount of time and 2) we've never tried to run models that long and produce that much data - could this be a memory or hard disk error and not a numerical/simulation error?
400k isn't a consistent threshold; sometimes it crashes even before reaching 10k steps.
@dhblum you're right, step_period
is the control step. I agree these are unreasonable times, but that's what RL demands for training and I've used them in the past as well. As BOPTEST-Gym is configured it does not warn users of those extremely long training times. That is intentional so that we can investigate the performance of RL in its best-case scenario where we assume that a lot of data is available. Even then it's hard to compete against other controllers like MPC.
Regarding the error, I'm not sure whether it relates to a memory error or a simulation error. I think it could be both. We reset the test case at the end of every episode of experience (after a simulation of 14 days in this case). However, it's likely that there is a memory leak somewhere. This is probably not detected by the bestest_hydronic_heat_pump
because it's a simpler test case. @IamAniket12 you could detect whether it relates to a memory error by using some kind of memory profiler.
I'm running the run_vectorized.py script from the example folder on a different test case locally. The script executes successfully for a number of iterations, but then throws a 'simulation failed' error. I tested the same script on the bestest_hydronic_pump test case, which ran without errors. Please review the code and error message provided below.
Server log: