First time here? Check out the Help page!
1 | initial version |
@Aaron Boranian Thanks again for your hints. There is, however, a big difference between this case and my other question as my other question posted inquiring about switchable glazing through EMS in E+. Basically, here, I'm not looking for any ruleset to put as the EMS Program rather than just having the window properties variable per timestep (and save that template as a new IDF file and running it). However, in my other post, I was inquiring about adding a (temperature-based) rule-set for window properties.
I'm so sorry if I couldn't mean myself clearly, but in this problem. To explain in a better way, all I need to do for this case is defining a template including an EMS Program, where my window value would be stored into a parameter (e.x., called as a P1). In this case, I'm not asking to change those variables at all, and all I should do is storing some new values (generated by GA) to such a parameter.
I truly appreciate your suggested approach. It seems your approach should work for me, in this way: I'll save the generated values by GA as P1, and then will proceed with Schedule:File object and eventually the EMS setup as a sensor. (inside my IDF template file).
As far as that Parallel simulation, I'm pretty sure this is not the case for this problem. In this approach, GA would optimize the building model after EP Lunch simulates the model, while the order would be as follows:
1) GA generates values for the window property. 2) Such values would be stored into the IDF file as new values for window properties. 3) EP lunch would simulate the model simply as an IDF file.
Thanks again for all your continued support.
2 | No.2 Revision |
@Aaron Boranian Thanks again for all your hints. There is, however, a big difference between this case and my other question as my other question posted inquiring about switchable glazing through EMS in E+. Basically, here, I'm not looking for any ruleset to put as the EMS Program rather than just having the window properties variable per timestep (and save that template as a new IDF file and running it). However, in my other post, I was inquiring about adding a (temperature-based) rule-set for window properties.
I'm so sorry if I couldn't mean myself clearly, but in this problem. To explain in a better way, all I need to do for this case is defining a template including an EMS Program, where my window value would be stored into a parameter (e.x., called as a P1). In this case, I'm not asking to change those variables at all, and all I should do is storing some new values (generated by GA) to such a parameter.
I truly appreciate your suggested approach. It seems your approach should work for me, in this way: I'll save the generated values by GA as P1, and then will proceed with Schedule:File object and eventually the EMS setup as a sensor. (inside my IDF template file).
As far as that Parallel simulation, I'm pretty sure this is not the case for this problem. In this approach, GA would optimize the building model after EP Lunch simulates the model, while the order would be as follows:
1) GA generates values for the window property. 2) Such values would be stored into the IDF file as new values for window properties. 3) EP lunch would simulate the model simply as an IDF file.
Thanks again for all your continued support.
3 | No.3 Revision |
@Aaron Boranian Thanks again for all your hints. There is, however, a big difference between this case and my other question as my other question posted inquiring about switchable glazing through EMS in E+. Basically, here, I'm not looking for any ruleset to put as the EMS Program rather than just having the window properties variable per timestep (and save that template as a new IDF file and running it). However, in my other post, I was inquiring about adding a (temperature-based) rule-set for window properties.
I'm so sorry if I couldn't mean myself clearly, but in this problem. To explain in a better way, all I need to do for this case is defining a template including an EMS Program, where my window value would be stored into a parameter (e.x., called as a P1). In this case, I'm not asking to change those variables at all, and all I should do is storing some new values (generated by GA) to such a parameter.
I truly appreciate your suggested approach. It seems your approach should work for me, in this way: I'll save the generated values by GA as P1, and then will proceed with Schedule:File object and eventually the EMS setup as a sensor. (inside my IDF template file).
As far as that Parallel simulation, I'm pretty sure this is not the case for this problem. In this approach, GA would optimize the building model after EP Lunch simulates the model, while the order would be as follows:
1) GA generates values for the window property. 2) Such values would be stored into the IDF file as new values for window properties. 3) EP lunch would simulate the model simply as an IDF file.
Thanks again for all your continued support.
4 | No.4 Revision |
@Aaron Boranian Thanks again for all your hints. There is, however, a big difference between this case and my other posted question as while posted inquiring about switchable glazing through EMS in E+. Basically, here, I'm not looking for any ruleset to put as the EMS Program rather than just having the window properties variable per timestep (and save that template as a new IDF file and running it). However, in my other post, I was inquiring about adding a (temperature-based) rule-set for window properties.
I'm so sorry if I couldn't mean myself clearly, but in this problem. To explain in a better way, all I need to do for this case is defining a template including an EMS Program, where my window value would be stored into a parameter (e.x., called as a P1). In this case, I'm not asking to change those variables at all, and all I should do is storing some new values (generated by GA) to such a parameter.
I truly appreciate your suggested approach. It seems your approach should work for me, in this way: I'll save the generated values by GA as P1, and then will proceed with Schedule:File object and eventually the EMS setup as a sensor. (inside my IDF template file).
As far as that Parallel simulation, I'm pretty sure this is not the case for this problem. In this approach, GA would optimize the building model after EP Lunch simulates the model, while the order would be as follows:
1) GA generates values for the window property. 2) Such values would be stored into the IDF file as new values for window properties. 3) EP lunch would simulate the model simply as an IDF file.
Thanks again for all your continued support.
5 | No.5 Revision |
@Aaron Boranian Thanks again for all your hints. There is, however, a big difference between this case and my other posted question while inquiring about switchable glazing through EMS in E+. Basically, here, I'm not looking for any ruleset to put as the EMS Program rather than just having the window properties variable per timestep (and save that template as a new IDF file and running it). However, in my other post, I was inquiring about adding a (temperature-based) rule-set for window properties.
I'm so sorry if I couldn't mean myself clearly, but in this problem. clearly. To explain in a better way, all I need to do for this case is defining a template including an EMS Program, where my window value would be stored into a parameter (e.x., called as a P1). In this case, I'm not asking to change those variables at all, and all I should do is storing some new values (generated by GA) to such a parameter.
I truly appreciate your suggested approach. It seems your approach should work for me, in this way: I'll save the generated values by GA as P1, and then will proceed with Schedule:File object and eventually the EMS setup as a sensor. (inside my IDF template file).
As far as that Parallel simulation, I'm pretty sure this is not the case for this problem. In this approach, GA would optimize the building model after EP Lunch simulates the model, while the order would be as follows:
1) GA generates values for the window property. 2) Such values would be stored into the IDF file as new values for window properties. 3) EP lunch would simulate the model simply as an IDF file.
Thanks again for all your continued support.
6 | No.6 Revision |
@Aaron Boranian Thanks again for all your hints. There is, however, a big difference between this case and my other posted question while inquiring about switchable glazing through EMS in E+. Basically, here, I'm not looking for any ruleset to put as the EMS Program rather than just having the window properties variable per timestep (and save that template as a new IDF file and running it). However, in my other post, I was inquiring about adding a (temperature-based) rule-set for window properties.
I'm so sorry if I couldn't mean myself clearly. To explain in a better way, all I need to do for this case is defining a template including an EMS Program, where my window value would be stored into a parameter (e.x., called as a P1). In this case, I'm not asking EMS to change those variables at all, and all I should do is storing some new values (generated by GA) to such a parameter.
I truly appreciate your suggested approach. It seems your approach should work for me, in this way: I'll save the generated values by GA as P1, and then will proceed with Schedule:File object and eventually the EMS setup as a sensor. (inside my IDF template file).
As far as that Parallel simulation, I'm pretty sure this is not the case for this problem. In this approach, GA would optimize the building model after EP Lunch simulates the model, while the order would be as follows:
1) GA generates values for the window property. 2) Such values would be stored into the IDF file as new values for window properties. 3) EP lunch would simulate the model simply as an IDF file.
Thanks again for all your continued support.
7 | No.7 Revision |
@Aaron Boranian Thanks again for all your hints. There is, however, a big difference between this case and my other posted question while inquiring about switchable glazing through EMS in E+. Basically, here, I'm not looking for any ruleset to put as the EMS Program rather than just having the window properties variable per timestep (and save that template as a new IDF file and running it). However, in my other post, I was inquiring about adding a (temperature-based) rule-set for window properties.
I'm so sorry if I couldn't mean myself clearly. To explain in a better way, all I need to do for this case is defining a template including an EMS Program, where my window value would be stored into a parameter (e.x., called as a P1). In this case, I'm not asking EMS Program to change those variables at all, and all I should do is storing some new values (generated by GA) to such a parameter.
I truly appreciate your suggested approach. It seems your approach should work for me, in this way: I'll save the generated values by GA as P1, and then will proceed with Schedule:File object and eventually the EMS setup as a sensor. (inside my IDF template file).
As far as that Parallel simulation, I'm pretty sure this is not the case for this problem. In this approach, GA would optimize the building model after EP Lunch simulates the model, while the order would be as follows:
1) GA generates values for the window property. 2) Such values would be stored into the IDF file as new values for window properties. 3) EP lunch would simulate the model simply as an IDF file.
Thanks again for all your continued support.
8 | No.8 Revision |
@Aaron Boranian Thanks again for all your hints. There is, however, a big difference between this case and my other posted question while inquiring about switchable glazing through EMS in E+. Basically, here, I'm not looking for any ruleset to put as the EMS Program rather than just having the window properties variable per timestep (and save that template as a new IDF file and running it). However, in my other post, I was inquiring about adding a (temperature-based) rule-set for window properties.
I'm so sorry if I couldn't mean myself clearly. To explain in a better way, all I need to do for this case is defining a template including an EMS Program, where my window value would be stored into a parameter (e.x., called as a P1). In this case, I'm not asking EMS Program to change those variables at all, and all I should do is storing some new values (generated by GA) to such a parameter.
I truly appreciate your suggested approach. It seems your approach should work for me, in this way: by following your approach: I'll save the generated values by GA as P1, and then will proceed with Schedule:File object and eventually the EMS setup as a sensor. (inside my IDF template file).
As far as that Parallel simulation, I'm pretty sure this is not the case for this problem. In this approach, GA would optimize the building model after EP Lunch simulates the model, while the order would be as follows:
1) GA generates values for the window property. 2) Such values would be stored into the IDF file as new values for window properties. 3) EP lunch would simulate the model simply as an IDF file.
Thanks again for all your continued support.
9 | No.9 Revision |
@Aaron Boranian Thanks again for all your hints. There is, however, a big difference between this case and my other posted question while inquiring about switchable glazing through EMS in E+. Basically, here, I'm not looking for any ruleset to put as the EMS Program rather than just having the window properties variable per timestep (and save that template as a new IDF file and running it). However, in my other post, I was inquiring about adding a (temperature-based) rule-set for window properties.
I'm so sorry if I couldn't mean myself clearly. To explain in a better way, all I need to do for this case is defining a template including an EMS Program, where my window value would be stored into a parameter (e.x., called as a P1). In this case, I'm not asking EMS Program to change those variables at all, and all I should do is storing some new values (generated by GA) to such a parameter.
I truly appreciate your suggested approach. It seems your approach should work for me, by following your approach: I'll save the generated values by GA as P1, and then will proceed with Schedule:File object and eventually the EMS setup as a sensor. Sensor and Program (inside my IDF template file).
As far as that Parallel simulation, I'm pretty sure this is not the case for this problem. In this approach, GA would optimize the building model after EP Lunch simulates the model, while the order would be as follows:
1) GA generates values for the window property. 2) Such values would be stored into the IDF file as new values for window properties. 3) EP lunch would simulate the model simply as an IDF file.
Thanks again for all your continued support.