Different results for same script between ModelToOSM and custom-energy-sim

Hello everyone,

I’m working on a workflow to simulate a large sample for sensitivity analysis. I want to use Pollination to parallel simulate all the samples. To test whether this approach is feasible, I started by simulating a seed model locally using ModelToOSM and then sent it to Pollination using the Custom-energy-sim recipe.

Surprisingly, I encountered discrepancies in the results when comparing the same script. For example, when using ModelToOSM, the normalized heating energy I calculated was 198 kWh/m², while with custom-energy-sim, it was only 96 kWh/m².

I delved deeper into the generated HTML reports and eventually discovered that the recipe doesn’t consider the setpoint of 20 degrees that I defined earlier in the script for the coldest day. Instead, it uses 16 degrees.

#Model to OSM


I should also mention that this is my first experience using Pollination, and I’m uncertain whether this issue is related to the recipe itself or how I’m implementing it.

Any insights or suggestions would be greatly appreciated.


Hi @prateekwahi ,

There is nothing that I can think of that could cause one version of the simulation to use a setpoint of 20C while the other uses 16C except that there are two different Models with two different setpoint specifications in them. There’s really no other place in the simulation process where the thermostat setpoints are defined except in the input Pollination Model / HBJSON.

Can you share the model you are using that you think represents both of these cases? If I have that, I can at least tell you which set of energy results currently represents your model and then, if you want this changed, I can demonstrate how to do so.

Hi Chris.
Thank you so much for your prompt reply. Please find the attached zip.

Sample_simulations.zip (896.9 KB)

Hi @prateekwahi ,

Sorry that I should have been more specific. Can you send me your model as a HBJSON or Pollination Rhino .3dm model? I would bet that the reason why the setpoint is changing on you without you noticing has to do with the complexity of this Grasshopper script that is generating your model:

Also, I don’t have all of the dependencies to run your Grasshopper script.

If you have a model as HBJSON or Pollination .3dm, at least this is a static model that we can both reference and we can agree on its properties. It can just be tough to know if such a large Grasshopper script is running exactly the same way on my end as it does on your end, especially when you are using a few different external Grasshopper plugins and I don’t know if the versions of those plugins are matched between your machine and mine.

Hi Chris !!.

I have attached the HBJSON file generated by the ModeltoOSM component.
Terraced_house.hbjson (305.0 KB)

Is the ‘pollination.3dm’ file you requested is exported using the Pollination plugin for Rhino? If so, unfortunately, I do not have it installed. I hope the HBJSON file is helpful.

I’ve found something. When I use the HBJSON file for simulating and calculating my output, I obtain a value of 96.6 kWh/m2 for heating energy (normalized with 142 m2). However, when I use the .idf file and check the results, it provides me with the expected values (197 kWh/m2)and adheres to the setpoints I specified. I do not know what causing this.

IDF file

Hi @prateekwahi ,

By looking at your HBJSON file, I can see what the problem is. You have two schedules with the same ID in your model. Both schedules are called Heat_Setpoints_Neimen_<1975. You can see that one of them has all of the setpoints assigned at 20C:

… and the other has all of the setpoints assigned at 16C:

If you use the HB Validate Model component in your Grasshopper definition (or run the PO_ValidateModel command in the Pollination Rhino plugin), it will tell you that this has makes your model invalid for correct simulation in EnergyPlus. It will also give you a message with the name of the schedule so you can fix it.

Long story short, use better unique names when you are creating your schedules. Or just don’t supply a name/ID for the schedule and use the default behavior, which will always ensure that a unique ID is used.

1 Like

Hi Chris !!!

You were right. It works now.
Thanks a lot for your help.


1 Like