Custom starting temperature and outside data schedule

[fremk]

Hello!
I hope you're all doing well 😄

I was wondering if it's possible to initialize the simulator with a specific inside temperature instead of it being random (depending on the hash of the output path). I saw that you ran the simulation for a small period of time (initialization time) before you start the actual simulation.

Also, I would like to experiment with custom .csvs that contain the outside data for each timestep, instead of reading the data from an .epw or a specific .csv format from which you deduce the outside data at each timestep.

Just wanted to check if you have any insights on how to accomplish these tasks.
Thank you!
Karim

[mnblonsky]

Hi, yes, these should both be doable.

You can use the initial_temp_setpoint argument within the Envelope dictionary to set the initial temperature. See here for details. If you want to directly set the temperature for other zones, you'd have to set dwelling.envelope.states directly, which may be difficult, but possible.

It shouldn't be too hard to modify the data in the weather files before initialization. Would that work for your use case? If not, you can modify the weather schedules in a similar way that you would modify equipment controls:

• You can update "Ambient Dry Bulb (C)" in the envelope.schedule and then call envelope.schedule.reset_time(). Note that there's a few weather variables to update in the envelope, and you may need to update schedules for HVAC, water heaters, PV, etc. too.
• You can send new weather data at each time step, for example dwelling.update(schedule_inputs={"Ambient Dry Bulb (C)": 20}). Note that schedule_inputs may change in a future release, but this should work for now.

[fremk]

Hello again, thank you for your response!
Just got to it, did not have time to experiment with it before and I ran into a small problem.
Let's suppose I want to modify most of the external values that were used by OCHRE (not only the outside temperature), such as Ambient Relative Humidity, GHI, DNI, DHI etc... from the full list of variables in the schedule below

[Ambient Dry Bulb (C), Ambient Relative Humidity (-), Ambient Pressure (kPa), 
GHI (W/m^2), DNI (W/m^2), DHI (W/m^2), Wind Speed (m/s), Sky Temperature (C), 
Mains Temperature (C), Ground Temperature (C), Ambient Humidity Ratio (-), 
Ambient Wet Bulb (-), apparent_zenith, zenith, apparent_elevation, elevation, 
azimuth, equation_of_time, dni_extraterrestrial, airmass, Exterior Wall Irradiance (W),
Window Irradiance (W), Door Irradiance (W),Occupancy (Persons),MELs (kW),TV (kW),
HVAC Heating Setpoint (C)]   

I don't think that it's easily doable with the methods you've provided since I saw that the schedule_inputs modifies the self.current_schedule in the Simulator class which do not modify these values directly.
Would a better approach be to modify the schedule before the launch of the simulation? Right after you load the schedule from the .epw file?

I think as you mentioned the best would be to create a custom .epw but honestly I am not quite familiar with that file format nor with the template of data that it takes, so that's why I am searching for a workaround.

As for the initial temperature, it works wonders 👌
Thank you!

[mnblonsky]

The .epw format isn't too hard to learn, it might be the easiest option. Another is to use NSRDB weather files. I think those may be a bit easier, but the data is essentially the same.

Modifying the schedule will also work, but keep in mind that each equipment (and the envelope) has their own schedule. So you'll have to modify each one, and check which inputs are required for each equipment. Could be tedious, so editing the file seems like the better option to me.

Sending data through schedule_inputs should work too. OCHRE will pass those inputs to any submodules that require them. This isn't commonly done, so there may be some bugs to work out. It's really meant for modifications that have to be done during runtime, I think the other options are better if you know the input data in advance.

You should be able to tell if any of the approaches work based on the output time series file, or by debugging.

[fremk]

Just wanted to let you know that I found my fix!
When going through the code I noticed that the load_schedule function in ochre/utils/schedule.py takes a schedule argument that modifies the weather and occupancy data before passing them to the simulator which is exactly what I wanted.
May I suggest a small change though, in my fork, I modified the weather and occupancy schedules before the use of the calculate_solar_irradiance function, that way all the changes that were made to the weather data would be applied to the rest of the schedule variables (instead of changing the final concatenated schedule directly).
For example, when we change the GHI, DNI, DHI (irradiances) in the weather schedule, the calculate_solar_irradiance function calculates the wall, window and ceiling/attic irradiances, so by changing the weather data before passing it to that function we guarantee that the final calculated wall, window and ceiling/attic irradiances took into consideration the changes made in the weather data.

Let me know what you think!
Thanks again 😄