Finally I had my model simulated using annual-energy-use/0.3.4 online. Carefully expressed I don’t know what to say.
Almost a piece of art, while same model same settings locally
Checking out what goes wrong isn’t much fun since for example it’s really hard to work with such room names. Hope the search function is updated soon and the custom Room names should be also passed trough, shouldn’t they?
But maybe the answer what went wrong is more simple than I think?
Hi @martin6, do you mind sharing the link to the run on Pollination with us? I don’t see any recent runs under your account → Pollination Cloud App
Hi @mostapha I deleted them since the jobs where public and I still haven’t asked the people providing the data ,if the model can be made public.
Thanks! Do you want me to create an organization for you where you can create private projects? I need this information from you.
Sure @mostapha no problem
@mostapha I’ve sent you a mail
Thanks @martin6!
@chriswmackey, I added you to the project so you can have a look whenever you get a chance. I suspect this is a strange bug. Hopefully I’m wrong!
Here is the link to the job for your reference: Pollination Cloud App
Hi @martin6 ,
The simulation looks fine on Pollination. You can see your heating and cooling values in the report make sense:
So I don’t think the error is with the pollination simulation or with your model setup but rather whatever is happening locally to build that LoadBalance graph from the Pollination results. There’s probably some extra output that’s being accounted for in the results that’s causing the results to be mis-calculated.
I was planning to add a dedicated recipe for producing LoadBalances since you really need both the Model and the results to follow a specific format (and usually exclude certain types of outputs) in order for all of the postprocessing to work correctly.
I’ll take a look at your .sql file when I get the chance but, for the time being, I recommend using the custom-energy-sim recipe if you need to construct an energy balance like this and then use the future dedicated recipe for load balances when it’s available.
Yes, this has to do with the OpenStudio Results measure (that generates the nice HTML report in the annual-energy-use recipe) interfering with the format of the SQL. I’ll add some checks for this type of differently-formatted SQL when I get the chance but just using the custom-energy-sim recipe should avoid all of this weirdness since that recipe doesn’t include the report.
And I was correct that the EnergyPlus simulation ran fine and the results are valid in the annual-energy-use recipe. They’re just not imported in the right format by the LBT plugin on the local side of things.
I was able to recreate the SQL formatting issue with the LBT plugin using a simple 2-zone case:
I’ll let you know when I manage to push a fix to the LBT plugin.
Ok, I just pushed a fix that should ensure that the LBT plugin can import the SQL data in the correct order even when the OpenStudio Measure changes the format of the SQL:
I tested it with the .sql file on @martin6 's project and it now loads the SQL data correctly:
I’ll warn that the fix noticeably increases the run time of the SQL result-parsing components when you load a lot of data, like the ~5 million data points (8760 * 40 * 16) being loaded with this particular SQL and the “HB Read Room Energy Result” component. But this is what’s needed to avoid incorrectly-formatted results whenever OpenStudio reporting measures request other outputs to be written to the SQL.
The fix should be available with the “LB Versioner” in an hour or so.
FYI, I implemented something that should mitigate the run time for large files:
It seems Python 3 is much more efficient at running this type of sqlite query than Python 2 so, whenever we have a large sql file, we just use the honeybee-energy CLI with Python 3. When the SQL file is small enough , the overhead of calling Python 3 isn’t really worth it so we still use the SQLite module in IronPython for this case.
But the change above drops the runtime of this 5-million data point import from 6 minutes to 2 minutes. So it seems worthwhile.
