@mostapha Thanks for your reply.
I found the difference betweem running simulation in the local folder and running simulation on the cloud.
in.osm file and in.idf file are not generated in the local folder. I only found model.idf file in the local folder.
For now, the files I need to download on the cloud are the osm and idf files only, not all of the files in the result-folder.
This is because we run the intermediate steps for local folders in a temp folder and delete them when the study is finished. We can expose the option to overwrite the debug folder but I don’t see it as a high priority unless you tell me otherwise.
I imagine the results are still identical. If that’s not the case, then it is worth a separate Discourse post.
This is because we run the intermediate steps for local folders in a temp folder and delete them when the study is finished. We can expose the option to overwrite the debug folder but I don’t see it as a high priority unless you tell me otherwise.
Understood. Personally, in.osm file is always necessary as we can assign very limited parameters for HVAC system in Pollination.
Have you tried to save the file as an OSM? Is there a reason that you need to run the simulation and get the in.osm file?
Have you seen this discussion, and the new Ironbug video tutorials? You can get pretty far by using Ironbug as the Pollination HVAC editor.
Have you tried to save the file as an OSM? Is there a reason that you need to run the simulation and get the in.osm file?
Sorry, I don’t know how to save osm files. Just saving Rhino files as osm files often fails.
Have you seen this discussion, and the new Ironbug video tutorials? You can get pretty far by using Ironbug as the Pollination HVAC editor.
No, I haven’t yet. Ironbug is beyond Rhino plugin. I guess Ironbug is based on OpenStudio and not all of OpenStudio features are available in Ironbug. OpenStudio lacks many features that EnergyPlus(IDFEditor) can do.
So, what we can do are
EnergyPlus(IDFEditor) >> OpenStudio > Ironbug
Essentially, users only need to learn EnergyPlus. May I know what the incentive is for users to learn Ironbug with different interface?
Hmm. That looks like a bug, but I can’t recreate it on my end. Can you share the sample file that you are using with us to recreate the issue. I used this file for testing, but I was able to create the osm file with no issues.
Thank you for sharing the error message. I can’t tell what’s happening there but maybe @chriswmackey can help. My understanding is that associating a weather file is optional.
Interesting! We consider Ironbug as an extension to the Rhino plugin. Think about it as a virtual interface for creating detailed HVAC systems that can be used with Pollination models. Even right now, the two are fully integrated. You can use Ironbug to build/edit the HVAC systems and assign them to Pollination models.
Ironbug is using OpenStudio SDK under the hood. Can you be more specific about the missing features? What do you need that you were not able to find in Pollination and Ironbug?
Similarly, I need to know more about the specific features that you are looking for to be able to help here. You should be able to build most of what you need for the HVAC part with Ironbug, and then only edit it in IDF if necessary. We are in the process of shaping up the next Ironbug <> Pollination integration features, and your feedback will be helpful.
Great question! The advantage of using Ironbug is that you will have access to several reusable templates. Eventually, all the inputs will be translated to an IDF but in most of the common scenarios the user shouldn’t need to edit the IDF.
It is similar to how you use the Pollination UI to build other resources like geometry, construction sets, and program types. It is faster to build them in Pollination, and they are reusable for other projects. Of course, you can always do these in an IDF editor, but it will be slower and harder to build and debug. I would love to hear your thoughts on this.
@mostapha Thank you for responding in detail.
Please find the Rhino file which fails to save as an osm file in the link below.
Test_Unable_to_Save_as_osm.3dm
So, Ironbug allows users to model HVAC systems much more quickly than IDFEditor once they are familiar with it. Am I correct? But I’ve rarely wished I could reuse HVAC systems because parameters such as flow rate, capcity, efficiency and pressure rise are different in each zone in each building.
I just searched some components I came up with on the GH canvas. For example, absorption chilller, thermal storage, swimming pool, LoadProfile:Plant, desiccant heat exchanger, desiccant defumidifier are not found.
Rhino Plugin and Ironbug look quite different. I’m assuming users new to Rhino and GH. Rhino is similar to other 3D modelling tool. Rhino Plugin (Icons for Pollination) is easy to understand. On the other hand, GH is a visual programming language. The user interface is completely different. What should we start with the blank GH canvas? What are components? How to connect them? I experianced that there is a big gap between getting new users used to Rhino and getting them used to GH.
I’ll go through the 12 video tutorials, but I’m not sure I would recommend that to other employees.
One of the major features that IDFEditor has but OpenStudio does not have is for example, AirloopHVAC:DedicatedOutdoorAirSystem. I often have projects with AHUs connected to PAUs in series.
Hey @keigonomura ,
Sorry this was the result of us not completing a certain feature that we’ve had in development on our end. At the moment, you can’t assign an Efficiency Standard to the simulation parameter if the OSM will not have any EPW file associated with it (that is, if the OSM is not immediately going to be used for simulation).
I see there’s an efficiency standard in your 3dm here:
When I remove it, I can save the OSM:
Test_Unable_to_Save_as_osm.3dm
Test_Unable_to_Save_as_osm.osm
FYI, if you actually want the OSM translation process run a sizing calculation and then assign efficiencies to all of the HVAC equipment using the AHSRAE_2019 standard, then you can achieve this by bringing the pollination Model into Grasshopper and exporting it to OSM using the HB Model To OSM component. Because this component has an input for an _epw_file, it will be able to get the design days to be used for the sizing calculation. We will be including this same functionality in the Rhino plugin’s “Save As OSM” functionality soon. It’s just not completed at the moment.
Thank you for sharing the sample file. @chriswmackey already answered your question there. We will improve the error message for now. As Chris mentioned we are adding a project information object that will allow the user to add the weather file information to the model which we can use in cases similar to this one.
Yes. Once you have it set up the first time then you can reuse the Grasshopper definition. You can change the input parameters as needed starting from the template. Try the PO_HVACManager command, and you can see some of the available templates.
And check the available input parameters. Here is an example.
You can also build your templates as needed. The videos should cover the steps for building an HVAC system.
You don’t have to watch all the videos unless you like to. Watching a couple of them should give you a sense of the logic behind the Ironbug. 
I’m very familiar with the challenge. In my experience, with the ladybug tools project, once the benefits are clear people are willing to learn new tools. The question is if Ironbug and its integration with Pollination add those clear advantages and if we can communicate them successfully. I would love to hear your feedback on this topic. We might want to create a new topic to discuss that.
This is a question for @mingbo to answer.
Thanks again for taking the time to document all your questions. Appreciate it! 
FYI, I have improved the error message that you get for this case, which should hopefully ameliorate things until we finish the feature:
FYI, @keigonomura ,
One way to possibly deal with this issue:
… is just to set up the structure of your IronBug HVAC to reflect the way that you typically lay out a given system but leave all of the equipment sizes autosized and the equipment efficiencies default. Then, you can have other people in the office make use of these generalized templates but have them select the “Efficiency Standard” for the version of the energy code that the building is built to. This will result in the translation process to OpenStudio running a sizing calculation of your model to get all all of your flow rates + capacities and then all of the equipment efficiencies will be set based on this standard and the resulting sizes.
Granted, this workflow has limitations, particularly if you are aiming to use equipment that’s much more efficient than what the code specifies. So, for a final “production” energy model, you may want to replace all of the autosized parts of your IronBug HVAC with the real final sizes and efficiencies. But hopefully you get the sense of what we’re trying to achieve here by helping you reuse as much as you can in the process so that you don’t always have to rebuild a complete HVAC system from scratch every time that you want to update a model or test something new.
@chriswmackey Thank you for detecting the cause!
Hi @keigonomura, we have added a new command/object to Pollination to set the location information for the project including the weather station and the building vintage.
The simulation parameters is now linked to the Project Information and uses the weather file, and the efficiency standards from the Project Information to apply the efficiency standards if it is selected by the user.
