On 2011-06-13 09:21:03, @DavidGoldwasser wrote:

Reported by Brent, but I have seen this as well. Seems like it shows correctly at top, in chart, but not in tree or column view.

On 2011-11-16 09:50:14, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:41:13, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-09-24 13:18:52, @DavidGoldwasser wrote:

Want to show this as open vs. wont' fix. So eventually we can get to it.It is still on the known issues in release notes.

On 2013-03-29 13:30:48, @axelstudios wrote:

Appears to work fine

On 2013-06-27 08:03:02, @DavidGoldwasser wrote:

I still got this a few weeks ago.

Keywords: ReleaseNotes

On 2011-12-29 09:17:44, @DavidGoldwasser wrote:

Created an attachment (id=99)
screenshot of source and unsupported file in IDF editor

The source file (bottom of picture) had 3 thermostats and 1 each heating and cooling thermostat setpoint object. The unsupported file has no thermostats and 4 each heating and cooling setpoint objects.

There seem to be two issues here.

1. the thermostat setpoint objects seems to be duplicating multiple times (one more than the number of zones).
2. The thermostat object doesn't make it into the OSM file but also doesn't make it into the sidecar file.

On 2011-12-29 09:22:54, @DavidGoldwasser wrote:

Even for people who are not using the sidecar file, I expect these extra objects are artificially inflating the number of unsupported objects that show up in the alert box when an IDF is imported.

On 2012-01-13 15:22:03, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-01-19 10:52:48, @DavidGoldwasser wrote:

Batch moving bugs from SketchUp to "Code" component

Original attachments:

• sidecar_thermostats_bug.png (ID 99)

Keywords: ReverseTranslation

On 2011-09-23 11:43:43, @DavidGoldwasser wrote:

There are a number of known reasons for this that I have in my diagnostic script.

e.g. Duplicate names, construction with air gap material exposed. This file isn't getting caught, I'd like to find out the issue.

On 2011-09-23 11:44:53, @DavidGoldwasser wrote:

Created an attachment (id=30)
figure out why this opens empty without error

On 2011-11-16 09:50:34, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:34:09, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 11:45:00, @DavidGoldwasser wrote:

Seems to import ok, but then doesn't re-open correctly as OSM file. I ran it through the diagonstic script and no duplicate names caught.

The OSM opens as if it is empty and I get the following ruby error. What is odd is that the spaces show up in the inspector, and as you select a space in the inspector is renders in SketchUp (but not all surfaces in the space.)

I'll attach the 0.6.2 osm file.

Error: #<RuntimeError: Could not create edge>
C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/interfaces/PlanarSurface.rb:172:in add_face' C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/interfaces/PlanarSurface.rb:172:increate_entity'
C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/interfaces/DrawingInterface.rb:121:in draw_entity' C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/interfaces/ModelInterface.rb:672:inattach_openstudio_model'
(eval):54:in each_with_index' C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/interfaces/ModelInterface.rb:670:ineach'
C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/interfaces/ModelInterface.rb:670:in each_with_index' C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/interfaces/ModelInterface.rb:670:inattach_openstudio_model'
C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:209:in attach_openstudio_model' C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:159:inopen_openstudio'
C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/CommandManager.rb:68:in open_openstudio' C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/MenuManager.rb:149:increate_commands'
C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/interfaces/ModelInterface.rb:691:in `call'
C:/Documents and Settings/dgoldwas/My Documents/OpenStudio 0.6.2/Ruby/openstudio/sketchup_plugin/lib/interfaces/ModelInterface.rb:691

On 2012-01-17 11:45:52, @DavidGoldwasser wrote:

Created an attachment (id=134)
Not sure what user this came in from

Original attachments:

• USIEF-12.idf (ID 30)
• bug260_USIEF-12.osm (ID 134)

Keywords: SyncWithSU, UserFile

Steps to reproduce.

1. Launch SketchUP
2. Draw a rectangle
3. Extrude to space
4. Select one surface, and using inspector set it to match itself. (At some point in the past we didn't let you do this, and if you opened a where a surface matched itself it was changed to adiabatic)
5. Assign zone to space
6. Save the model
7. Open in OS App, add weather file and run simulation. It seems to run fine.
8. Re-open in Plugin (I expected to to convert surface to adiabatic which would bring its own problems, but instead it just didn't open.

This is the error I see when I re-open:

Error: #<NoMethodError: undefined method openstudio_model' for nil:NilClass> C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/dialogs/RunSimulationInterface.rb:35:in populate_hash'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/dialogs/DialogInterface.rb:51:inupdate' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/DialogManager.rb:123:in update_all'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/stdruby/set.rb:189:ineach' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/stdruby/set.rb:189:in each_key'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/stdruby/set.rb:189:ineach' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/DialogManager.rb:123:in update_all'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/interfaces/ModelInterface.rb:1084:indetach_openstudio_model' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:238:in delete_model_interface'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:183:inattach_openstudio_model' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:181:in each'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:181:inattach_openstudio_model' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:167:in open_openstudio'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/CommandManager.rb:68:inopen_openstudio' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/MenuManager.rb:152:in create_commands'

This is the first issues I have seen like this with 1.0. Since I can't attach files I placed a zip file of the project on the network at the path below. @lgentile I will add to Pivital and put at top of backlog.

Y:\5500\5500 HPBldg\davidg\issue6.zip

On 2011-09-29 10:29:07, @DavidGoldwasser wrote:

I expect this is because when the first value changes we check the box for exclude horizontal. I know I requested that but if there isn't a way t fix the tab and keep that, maybe we don't automatically turn it off.

On 2011-11-16 09:50:37, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-16 10:09:25, @DavidGoldwasser wrote:

Dan, I think I'm fine, turning off the auto check of the check box if we can fix the tab issue.

On 2012-01-13 15:22:00, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-01-16 15:31:08, @DavidGoldwasser wrote:

If we are in that dialog anyway for 0.7 we can fix it, otherwise it can wait until later.

I tested in Plugin and PAT. It would be great if we could work with non rectangular base surfaces, or at least offer two unique warnings. one saying "The requested WWR and offset is too large to fit on the base surface" and then one that says "Can't set WWR on non rectangular surface."

We need a call to OpenStudio::Application::instance::application at the beginning of this method

A number of fields in the SimulationSettingsView (e.g. ShadowCalculation::polygonClippingAlgorithm and ShadowCalculation::skyDiffuseModeling) are presented to the user as free-form line edits, even though they are choice fields that are expecting particular key strings. From the user's perspective, they see a free-form field and have no way (without going outside the app) to know what they are supposed to type there. In general, if the underlying IDD field is of type \choice, the app should use OSComboBox, not OSLineEdit.

On 2011-07-01 13:40:08, @DavidGoldwasser wrote:

If you copy a zone or zones generally things work fine, but I've noticed a problem if you copy a zone and then use a (*#) to make multiple vs. a single copy. For example a single zone copied over and then a *4 used should produce 5 zones in a row. That is what appears but the first copied zone (next to the original zone) has a duplicate on top of it. I ran across this because of surface matching problems that were in the end due to the duplicate zone. Looking back EnergyPlus 1.0.6 exhibits this same problem (so it is a bug in our release version). I'll have to go back and look at 1.0.5 for this. If it was there I sure missed it for a long time. Not surprisingly the same thing happens with a /# vs. a *# for multiple copies. A user work around for this is not to use multiple copy or if they do they need to go and remove the duplicate copy after they make it. I can't find a way to avoid the unwanted duplicate from being made.

Bug imported from Excel; Status -confirmed; Created on - 12/29/10; By - David Goldwasser; Owned by -

On 2011-11-16 09:50:18, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:41:16, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 14:19:05, @DavidGoldwasser wrote:

Copy multiple is now broken on space level. This is because the select is changed after the copy. But if we do fix that then it will be making an extra zone. That fix may involve Google's input.

Keywords: ReleaseNotes

On 2011-12-06 12:54:52, @macumber wrote:

This does not seem like it should be the behavior here, does anyone remember the logic behind this?

On 2012-01-13 15:22:02, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

Keywords: Invalid?

On 2011-11-16 14:44:22, @DavidGoldwasser wrote:

There is a horizontal white lien that shows up on the left and right side of the loop just before the first node on the demand side. I don't think this existed 0.5.3 or earlier.

On 2011-11-16 14:54:31, @DavidGoldwasser wrote:

OK, so I see it now on 0.5.2, but Kyle has seen this come an go, so maybe other factors (e.g. zoom level, ???)

On 2012-01-13 15:22:00, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-03-14 10:21:05, @DavidGoldwasser wrote:

Keywords: OldGUI

I'm seeing warnings like these for objects that have an expected life shorter than the analysis period.

** Warning ** For life cycle costing a nonrecurring cost named LCC_DEMO - CBECS BEFORE-1980 LARGEHOTEL GUESTROOM LIGHTSDEF 1 contains a cost which is not within the study period.
** Warning ** For life cycle costing the recurring cost named LCC_DEMO - CBECS 1980-2004 EXTROOF IEAD CLIMATEZONE 5B 1 RECURRING has the first year of the costs that is not within the study period.
** Warning ** For life cycle costing the recurring cost named LCC_DEMO - CBECS BEFORE-1980 LARGEHOTEL GUESTROOM LIGHTSDEF 1 RECURRING has the first year of the costs that is not within the study period.
** Warning ** For life cycle costing the recurring cost named LCC_MAT - CBECS BEFORE-1980 LARGEHOTEL GUESTROOM LIGHTSDEF 1 REPLACEMENT has the first year of the costs that is not within the study period.

Here is some of the IDF code. @macumber let me know if you need the models and I'll put them on the network. Code below is for a construction with 20 year expected life and 0 years until costs start.

LifeCycleCost:Parameters,
{40036f17-103a-409c-9b40-193360cbbbe3}, !- Name
EndOfYear, !- Discounting Convention
ConstantDollar, !- Inflation Approach
0.03, !- Real Discount Rate
, !- Nominal Discount Rate
, !- Inflation
, !- Base Date Month
2011, !- Base Date Year
, !- Service Date Month
2011, !- Service Date Year
25, !- Length of Study Period in Years
, !- Tax rate
None; !- Depreciation Method

Construction,
CBECS 1980-2004 ExtRoof IEAD ClimateZone 5b, !- Name
Roof Membrane, !- Layer 1
IEAD NonRes Roof Insulation-3.51, !- Layer 2
Metal Decking; !- Layer 3

! OS:Construction, CBECS 1980-2004 ExtRoof IEAD ClimateZone 5b
LifeCycleCost:NonrecurringCost,
LCC_Demo - CBECS 1980-2004 ExtRoof IEAD ClimateZone 5b, !- Name
Salvage, !- Category
26753.9052967911, !- Cost
ServicePeriod, !- Start of Costs
20; !- Years from Start

! OS:Construction, CBECS 1980-2004 ExtRoof IEAD ClimateZone 5b
LifeCycleCost:RecurringCosts,
LCC_Demo - CBECS 1980-2004 ExtRoof IEAD ClimateZone 5b Recurring, !- Name
Replacement, !- Category
26753.9052967911, !- Cost
ServicePeriod, !- Start of Costs
40, !- Years from Start
, !- Months from Start
20; !- Repeat Period Years

! OS:Construction, CBECS 1980-2004 ExtRoof IEAD ClimateZone 5b
LifeCycleCost:NonrecurringCost,
LCC_Mat - CBECS 1980-2004 ExtRoof IEAD ClimateZone 5b, !- Name
Construction, !- Category
160523.431780747, !- Cost
ServicePeriod; !- Start of Costs

! OS:Construction, CBECS 1980-2004 ExtRoof IEAD ClimateZone 5b
LifeCycleCost:RecurringCosts,
LCC_Mat - CBECS 1980-2004 ExtRoof IEAD ClimateZone 5b Replacement, !- Name
Replacement, !- Category
160523.431780747, !- Cost
ServicePeriod, !- Start of Costs
20, !- Years from Start
, !- Months from Start
20; !- Repeat Period Years

On 2011-09-25 23:15:21, @DavidGoldwasser wrote:

This is an old bug I thought was fixed, but may have come back. Not something we need to fix for 0.5.0

On 2011-11-16 09:50:35, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-12-01 12:01:56, @macumber wrote:

To reproduce:

1. run energyplus simulation with sqlite output
2. open sqlite file in OpenStudio ResultsViewer
3. rerun energyplus, it will fail as expected
4. close ResultsViewer
5. rerun energyplus, it will continue failing, this is the bug

On 2012-01-13 15:22:00, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-12-17 12:25:53, @DavidGoldwasser wrote:

This isn't valid for the SketchUp Plugin, I'm going to remove from release notes, but still leave open and Assign to OS app, as I think this is still an issue, but maybe not as bad because we are using temp files. I'll retest sometime after 0.10.0 is out.

Keywords: ReleaseNotes

On 2011-12-02 14:14:50, @macumber wrote:

https://openstudio.nrel.gov/forums/runmanager/help-desk/lines-duplicated-during-runmanager

On 2012-01-13 15:22:02, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

Keywords: Invalid?

This URL is the origin of the issue
http://openstudio.nrel.gov/forums/openstudio-application/help-desk/why-result-summary-doesn%E2%80%99t-show-results

The issue seems specific to a computer. Someone in Moscow saw this but I didn't with the same model and weather file. Suspected cause may be special characters in user name. This is used for the temp results that are made after a run. I have requested additional information from the user and will add to the bug when I get feedback.

1. After running a simulation. Save your OSM file then quit the OpenStudio application and the start it again and load your file. At this point the temporary files should be gone, and the results tab should pull from the “run” directory next to your OSM file
2. Another idea is a little more work. Make a new user account called something like “testuser”. Logged in as this user, try to run a simulation and see if you still hit the same problem.

I'm using the current version of SketchUp 2013 and the 1.0.0 OpenStudio installer.To confirm that nothing was wrong with my installer I un-installed, and even removed files left behind in the plugin folder. Then re-installed.

SketchUp 8 works fine, it only affects SketchUp 2013. I can't duplicate this on my dev machine. Same version of SketchUp and OpenStudio work fine.

Here is the ruby error. You can get it by opening any OSM or importing an IDF. If you dont' have an OSM model on that machine, just make a box, save the file and try to re-open it. I first hit this on issue #17 witch turned otu to be invalid, I thoguht this was related to surface matching issue, which it was not. I'll copy @macumber on this since he is familiar with the plugin, but will assign to @axelstudios.

If you can reproduce this then it is a very critical bug, if you can't then I guess just need to figure out what is messed up on my VM.

ruby error:

Error: #<NoMethodError: undefined method openstudio_model' for nil:NilClass> C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/dialogs/RunSimulationInterface.rb:35:in populate_hash'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/dialogs/DialogInterface.rb:51:inupdate' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/DialogManager.rb:123:in update_all'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/stdruby/set.rb:189:ineach' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/stdruby/set.rb:189:in each_key'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/stdruby/set.rb:189:ineach' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/DialogManager.rb:123:in update_all'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/interfaces/ModelInterface.rb:1084:indetach_openstudio_model' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:238:in delete_model_interface'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:183:inattach_openstudio_model' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:181:in each'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:181:inattach_openstudio_model' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/ModelManager.rb:167:in open_openstudio'
C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/CommandManager.rb:68:inopen_openstudio' C:/Program Files (x86)/OpenStudio 1.0.0/Ruby/openstudio/sketchup_plugin/lib/MenuManager.rb:152:in create_commands'

The small icon shows up in place of the large one.

On 2011-12-06 13:53:12, @macumber wrote:

https://openstudio.nrel.gov/forums/openstudio-plug-google-sketchup/bug-reports-and-feature-requests/warning-about-wall-missing-s

On 2012-01-13 15:22:02, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-01-16 14:23:39, @DavidGoldwasser wrote:

This may have been related to undo, or backing out of space while activity was still going on. I'll leave it open for now, but have not seen this before, unless the users reversed the faces within SketchUp?

Keywords: Invalid?, Random, SyncWithSU

I have requested more feedback from the users who reported this (Thais Malta Baracat and Santiago Ferreyra ). They tried in various apps, I think the boost error comes up in the plugin, while. I will add feedback when I hear back from users.

"There are no tools configured. The system will now automatically search for tools" and
"boost::filesystem::exists:Acess denied" , or "EnergyPlus 7.2. could not be located, simulation aborted".

there are no tools configurated, the system will now automatically search tools, i press ok and then appears a screen boots::filesystem:exists:acceso denegado (access denied)

There is a dialog to save or not save your model, but there is also an "x" at the top right of the dialog box. I clicked that expecting it to function as a cancel but it functions as a "No" to saving your model and still exists.

It would be nice if this acts as a cancel option, or if we explicitly add a cancel button to the dialog.

On 2011-07-01 13:43:00, @DavidGoldwasser wrote:

I'm not too concerned that you can't create illuminance maps in either relative or absolute, but I noticed that they import form IDF incorrectly if the source file is absolute. Of course this only matters if there is a zone rotation with daylighting or map objects. For control points could just adjust the glare angle. Maps aren't as easy. If we want to support them but but still keep them relative, then maybe we can rotate the zone itself on IDF conversation so the map to zone relationship is correct? Dan, I'll let you address where this goes. I suppose the fix itself is probably not something for Q1, but our import could log this in the error dialog?

Bug imported from Excel; Status -unknown; Created on - 12/29/10; By - David Goldwasser; Owned by -

On 2011-11-16 09:50:18, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:41:17, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 14:12:42, @DavidGoldwasser wrote:

I'm not sure that we ever addressed this. Would be good to pick up before we deprecate the legacy plugin.

On 2012-01-19 10:52:46, @DavidGoldwasser wrote:

Batch moving bugs from SketchUp to "Code" component

On 2011-09-22 10:17:43, @DavidGoldwasser wrote:

If you have a really long pulldown list for example with 70 thermal zones, and it goes off the screen, you can't scroll to the end of the list. This may just be a limitation of the basic SketchUp UI Dialog with pulldowns. For 0.6.0 This should be gone if we have Multi-select in Inspector.

Minor issue for now, don't think we have to fix for 0.5.0.

On 2011-09-28 08:41:43, @DavidGoldwasser wrote:

First pass of bugs for 0.5.1. Some of Rob's mac bugs should be here as well

On 2011-11-16 09:50:34, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:41:35, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 11:49:42, @DavidGoldwasser wrote:

Still an issue, but I don't expect we will touch this for 0.7. Maybe put in QT dialog for 0.8

On 2011-12-01 10:34:16, @macumber wrote:

Suspect that the appropriate observer is not always called, could be due to race condition due to asynch proc in space's entities observers

On 2011-12-01 10:34:32, @macumber wrote:

Created an attachment (id=74)
File

On 2011-12-14 10:50:29, @DavidGoldwasser wrote:

This should work fine by hand, but came about with overhang user script with option to delete shading surfaces before adding new ones. Once this is fixed, we should re-implement that element of the ruby script.

On 2012-04-25 14:57:31, @DavidGoldwasser wrote:

Dan, so this now seems to work fine in the project overhang script but as the user did I hit this when I tried to delete by hand. Saving and re-opening the file the objects are still there. I wonder if the source of bug 650 is similar?

https://openstudio.nrel.gov/forums/openstudio-plug-google-sketchup/bug-reports-and-feature-requests/additional-known-issues-op-1#comment-1262

Original attachments:

• demo2.osm (ID 74)

Keywords: SyncWithSU

I have created a test file with only two spaces and a total of 5 surfaces. They both look exactly the same but one (e7) crashes while the other (e8) does not crash. e8 was made by taking e7 and moving one of the spaces a few times and then back to the original location. This file does not directly supper from the SketchUp intersect but that makes odd diagonal lines, but maybe there is a similar core issue? I have emailed the file to @macumber but I'll find a place on the network for them soon.@lgentile, I'll add this to Pivotal now that we have more to go on.

Here is an initial summery of the diff's of the two files. There are changes in all 5 surfaces, which is a bit odd, as two of them (Surface 1 and Surface 3) were in a space that was not touched. but in comments below I can narrow it down to a single vertex value. Also if you go to the crashing file (v7) and remove any of the 5 surfaces, intersect won't crash it anymore.

Surface 35, vertex 4
E7 -4.8641002032, -2.84479960791214, 2.79136546036137e-030; !- X,Y,Z Vertex 4 {m}
E8 -4.8641002032, -2.84479960791214, 7.81582328901191e-029; !- X,Y,Z Vertex 4 {m}

Surface 54 vertex 3 (this is a common point to surface 35)
E7 -4.8641002032, -2.84479960791214, 6.69927710486735e-029, !- X,Y,Z Vertex 3 {m}
E8 -4.8641002032, -2.84479960791214, 7.81582328901191e-029, !- X,Y,Z Vertex 3 {m}

Surface 17 (all 4 vertices changed, and in x,y,&z, vs. just in z)
E7 1.3721262813875e-011, -3.35280167186981, 5.3359104714532, !- X,Y,Z Vertex 1 {m}
E7 -4.86410020320009, -3.35280036549766, 5.33589202837834, !- X,Y,Z Vertex 2 {m}
E7 -4.86410020319988, -3.35279934681557, 7.30763488926745e-014, !- X,Y,Z Vertex 3 {m}
E7 -1.20135833253303e-013, -3.3528006531842, -7.09398344747063e-014; !- X,Y,Z Vertex 4 {m}

E8 1.38071556551538e-011, -3.35280135205875, 5.33591047145323, !- X,Y,Z Vertex 1 {m}
E8 -4.86410020319999, -3.35280000000003, 5.33589202837841, !- X,Y,Z Vertex 2 {m}
E8 -4.86410020319998, -3.3527997123132, 3.29872092895969e-015, !- X,Y,Z Vertex 3 {m}
E8 -2.06028674725995e-013, -3.35280097299526, -1.04612436956894e-013; !- X,Y,Z Vertex 4 {m}

Surface 1
E7 -1.46757023317472e-037, -1.15505827125162e-014, 3.74294931277106e-019, !- X,Y,Z Vertex 1 {m}
E7 1.46757023163683e-037, -6.753225, -1.87147465255285e-018, !- X,Y,Z Vertex 2 {m}
E7 -5.72769980280216, -6.75322500000003, -4.11724424069883e-018, !- X,Y,Z Vertex 3 {m}
E7 -5.7276997968, -7.94102561485488e-015, -1.87147465451548e-018; !- X,Y,Z Vertex 4 {m}

E8 5.7276997968, -7.94102561485488e-015, -1.87147465451548e-018, !- X,Y,Z Vertex 1 {m}
E8 1.46757023317472e-037, -1.15505827125162e-014, 3.74294931277106e-019, !- X,Y,Z Vertex 2 {m}
E8 1.46757023163683e-037, -6.753225, -1.87147465255285e-018, !- X,Y,Z Vertex 3 {m}
E8 -5.72769980280216, -6.75322500000003, -4.11724424069883e-018; !- X,Y,Z Vertex 4 {m}

Surface 3
E7 8.59135517801374e-028, -6.75322499999995, 3.57665764490041, !- X,Y,Z Vertex 1 {m}
E7 -5.72769982218217, -6.7532250000001, 3.50528987642782, !- X,Y,Z Vertex 2 {m}
E7 -5.72769981273667, -6.75322500000012, -3.08872326694553e-017, !- X,Y,Z Vertex 3 {m}
E7 -8.20050777011538e-028, -6.75322499999996, -1.87147465268921e-018; !- X,Y,Z Vertex 4 {m}

E8 5.45000032332442e-028, -6.75322499999995, 3.57665764490041, !- X,Y,Z Vertex 1 {m}
E8 -5.72769982218217, -6.7532250000001, 3.50528987642782, !- X,Y,Z Vertex 2 {m}
E8 -5.72769980280216, -6.75322500000003, -4.11724424069883e-018, !- X,Y,Z Vertex 3 {m}
E8 1.46757023163683e-037, -6.753225, -1.87147465255285e-018; !- X,Y,Z Vertex 4 {m}

On 2011-07-01 13:37:28, @DavidGoldwasser wrote:

Re generate object information data if users uses scale tool on a zone. In the past I recommended against users doing this, but as it turns out it works well, and could be very usefull. Right now the only issue is that you have to save close and re-open the IDF/OSM to get accurate data in the object info window. It would be great if this could update without having to re-open. For now I can just show this in the documentation, but if it can work directly that would be great. I'll put it in first quarter, but it could slide.

Bug imported from Excel; Status -unknown; Created on - 12/29/10; By - David Goldwasser; Owned by -

On 2011-11-16 09:50:17, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:41:16, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 14:20:00, @DavidGoldwasser wrote:

Moved to enhancement

On 2012-08-28 14:46:24, @DavidGoldwasser wrote:

Just as an update in this bug. It no longer does work, and users have used this and then had the SketchUp model out of sync with the OSM model. Would be nice to support this.

See URL for forum post.

On 2011-09-26 10:45:00, @macumber wrote:

These functions seem to work well if input is vector of idf object, but if vector is of workspace object then reference fields are blank. I encountered this trying to import constructions in the plug-in, see ModelInterface.rb, def import_constructions for the work around.

On 2011-11-16 09:50:35, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:41:35, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 10:50:51, @DavidGoldwasser wrote:

Dan, are you still using a work around for this?

Keywords: Invalid?

@kbenne if you run the following code, you'll get a model with 2 plant loops. The pump/cooling tower order is opposite of what you expect given the methods used. I believe the inletModelObject and outletModelObject methods are returning the opposite nodes of what they're supposed to.

require 'openstudio'

model = OpenStudio::Model::Model.new

case 1 - add pump get outlet node add clg twr to outlet node

plant_loop_1 = OpenStudio::Model::PlantLoop.new(model)
plant_loop_1.setName("case 1 add pump get outlet node add clg twr to outlet node")
cooling_tower_1 = OpenStudio::Model::CoolingTowerSingleSpeed.new(model)
pump_1 = OpenStudio::Model::PumpConstantSpeed.new(model)
plant_loop_1.addSupplyBranchForComponent(pump_1)
pump_outlet = pump_1.outletModelObject.get.to_Node.get
puts pump_outlet
cooling_tower_1.addToNode(pump_outlet)

case 2 - add pump get inlet node add clg twr to inlet node

plant_loop_2 = OpenStudio::Model::PlantLoop.new(model)
plant_loop_2.setName("case 2 add pump get inlet node add clg twr to inlet node")
cooling_tower_2 = OpenStudio::Model::CoolingTowerSingleSpeed.new(model)
pump_2 = OpenStudio::Model::PumpConstantSpeed.new(model)
plant_loop_2.addSupplyBranchForComponent(pump_2)
pump_inlet = pump_2.inletModelObject.get.to_Node.get
puts pump_inlet
cooling_tower_2.addToNode(pump_inlet)

model.save(OpenStudio::Path.new("C:/Projects/ruby testing/pump_inlet_outlet_test.osm"),true)

On 2011-12-02 14:28:30, @macumber wrote:

E.g. -6.06254e-031 radians

On 2012-01-13 15:22:02, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-01-16 14:50:24, @DavidGoldwasser wrote:

I need to retest this. Use geo-location to introduce minor angle.

Keywords: Invalid?

In other cases, such as adding or deleting a measure or measure group the user is warned and offered a chance to cancel.

On 2011-12-06 11:46:08, @macumber wrote:

Otherwise schedules can get so large that E+ cannot run

On 2012-01-13 15:22:02, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2013-01-10 11:36:09, @DavidGoldwasser wrote:

<batch comment: added this to Pivotal Epic, https://www.pivotaltracker.com/epic/show/458473>

Keywords: ForwardTranslation, Invalid?

The error checking is trapping any negative numbers, but I should be able to enter up to -100 as a percentage reduction. Also the default of 150 is really odd. I look at that and see that default is 50% increase for 30% lighting reduction, but it is really 150% increase. The default should be 0 (in both measures). I'll change that as well.

#make an argument for material and installation cost
material_and_installation_cost = OpenStudio::Ruleset::OSArgument::makeDoubleArgument("material_and_installation_cost",true)
material_and_installation_cost.setDisplayName("Increase in Material and Installation Cost for Electric Equipment per Floor Area (%).")
material_and_installation_cost.setDefaultValue(150.0)
args << material_and_installation_cost


if material_and_installation_cost < 0
  runner.registerError("Leave Material and Installation Cost blank or enter a non-negative number.")
  return false
end

On 2011-11-07 07:56:06, @macumber wrote:

https://openstudio.nrel.gov/forums/openstudio-plug-google-sketchup/help-desk/illuminance-map

also need to check daylighting control

On 2011-11-29 10:37:15, @macumber wrote:

This is the desired behavior, there is no correct way to map this to E+

On 2011-12-05 15:50:27, @DavidGoldwasser wrote:

Seems we should warn user of this on export if we don't already.

On 2012-01-17 14:31:43, @DavidGoldwasser wrote:

See if there is a warning issued for this.

On 2012-01-19 10:52:47, @DavidGoldwasser wrote:

Batch moving bugs from SketchUp to "Code" component

On 2012-01-24 09:18:19, @DavidGoldwasser wrote:

User reported and I confirmed same issue with daylighting control points. Maybe not an issue for illuminance map since E+ doesn't let you rotate them (although there is issue of global geometry rules to orient map with zone or with building.

Below is the warning on export to IDF.

Warning: Rotation of 180 radians about Z axis not mapped for OS:Daylighting:Control OS:Daylighting:Control 1

Keywords: ForwardTranslation

On 2011-12-19 13:01:13, @axelstudios wrote:

Crashes when building

Keywords: Invalid?, ReleaseNotes

On 2011-12-28 19:53:10, @DavidGoldwasser wrote:

If you watch the video I'm making (will put on YouTube tonight, but not public yet) you can see that I had to manually add this back. I think there was an unsupported material in the construction "blind" which led to its removal.

On 2012-01-13 15:22:03, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-01-19 10:52:48, @DavidGoldwasser wrote:

Batch moving bugs from SketchUp to "Code" component

Keywords: ReverseTranslation

On 2011-09-22 14:11:06, @DavidGoldwasser wrote:

You can load the sql but changing date/time doesn't change color or data values. Maybe this is related to the developer logging I have going on now. Need to test this is really broken?

On 2011-09-22 14:31:48, @DavidGoldwasser wrote:

Also zone based sql data doesn't seem to back back at all. Is that an issue with mapping back from zones to spaces?

If we can't fix this we should disable render by data?

Render by Data isn't acting like timeseries data for me

On 2011-09-24 22:55:38, @DavidGoldwasser wrote:

Dan, so data now loads for zone based, variables, but the update still isn't happening when you change the time of day or year. You have to click the "render by data" button again and then it updates. This is for surface or zone variables.

Import bug fix seems good.

On 2011-09-26 11:34:40, @DavidGoldwasser wrote:

tested

On 2011-10-03 15:45:32, @DavidGoldwasser wrote:

Dan, using this today it seemed broken again. The whole ResultsViewer dialog was slow, and update only happened when re-clicked render mode. (vs. changing time of day and time of year.

Just went back to 6706 and it works there, but is broken at 6727. I can do a little more testing tomorrow.

On 2011-10-05 16:08:53, @DavidGoldwasser wrote:

I'll close this it works now, but we will have to work on performance. On a 15zone model looking at solar incident it takes about 6 seconds for rendering colors to change. Interestingly that is about the same amount of time it takes for the Rendering Settings dialog to load when I re-open it. This was much quicker in 0.4.0 and earlier.

On 2011-11-07 07:54:12, @macumber wrote:

User is reporting that this is back:

https://openstudio.nrel.gov/forums/openstudio-plug-google-sketchup/bug-reports-and-feature-requests/render-data-value

On 2011-11-16 09:50:34, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:35:28, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2011-11-17 10:41:35, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-26 09:40:59, @DavidGoldwasser wrote:

So the comments before this describe the behavior for 0.6.0. But in 0.6.1 something changed. Dan, did you make a fix related to this.

In 0.6.1 when you go to render by data you briefly see color on the surfaces before they are replaced by white. When you drag the info tool over the data is there, but just not colored. As this is a SketchUp bug I don't expect us to address this in 0.7 so I'll move the milestone back.

On 2011-09-23 12:22:42, @DavidGoldwasser wrote:

We now have the reverse problem that bug 214 had. 214 was bout sluggish color object editing in the Inspector. That is now quick, but editing the color in SketchUp is slow.

I suppose if we add a QT based color picker in the inspector down the road, then we could get by with a one way sync and not have users edit materials from SketchUp's color picker.

I put this is 0.6.0 vs. 0.5.0.

On 2011-09-28 08:41:43, @DavidGoldwasser wrote:

First pass of bugs for 0.5.1. Some of Rob's mac bugs should be here as well

On 2011-10-04 12:32:13, @macumber wrote:

There was a crash related to this but I am having trouble reproducing it

On 2011-11-16 09:50:34, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:33:34, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 11:31:30, @DavidGoldwasser wrote:

This is still an issue, in particular until we improve our random color generation,but I'll push it until 0.8 for now.

On 2012-09-10 08:16:29, @DavidGoldwasser wrote:

On 2012-09-14 08:58:51, @DavidGoldwasser wrote:

This is currently assigned because it is in Pivotal, but I don't think necessary for 0.9.0.

I did re-validate this with a 200 space model. After changing color SketchUp was unresponsive for 10-15 seconds.This isn't a task that has to be done by user over and over, or even at all. And on smaller models is much better.

On 2011-11-22 11:28:55, @DavidGoldwasser wrote:

Working on upgrading the diagnostic script, and realized a few things were missing.

I used to provide information on author, version, date, etc, for the user script. It was a comment in the old scripts, I thought we were turning those into variables? but I don't see them.

We also lost the pop up dialog box that user gets when they first activate a script. Nice to give them a chance to cancel out if they make a mistake, or didn't understand what the script would impact.

On 2012-01-13 15:22:01, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-01-16 15:18:33, @DavidGoldwasser wrote:

I either want to add this in script as comment, or create constants that can be read by users if necessary. Similar to how original user scripts were. I also want pop open a dialog with description andchance to cancel whenever the user triggers one.

OpenStudio User Script

Script Name: Bad File Diagnostic

Author: David Goldwasser

Organization: NREL (optional field)

Version of OpenStudio written for: 0.4.5 and higher

Date Script Created/Modified: 10/24/11

User Script Version Number: 0.2 (updated for 0.5.0 files vs. 0.4.0 files)

SketchUp Versions Support: SU 7 or 8, free and pro, mac and windows

Description of script function and behavior:

Runs a variety of diagnostic tests on an IDF or OSM file looking for objects

that prevent the file from opening or running smoothly in the SketchUp Plugin

The diagnostic report is printed to the ruby console. It would be easy to adapt

this to write to an external file. It would also be easy to setup the script

to run from a command line. vs. SketchUp. Other than the interface to select the

file to test, there is no SketchUp API used for the diagnostic tests.

On 2011-07-01 14:39:27, @DavidGoldwasser wrote:

0.3.0 didn't have this, but the default sort order changed

Bug imported from Excel; Status -confirmed; Created on - 4/18/11; By - Brent Griffith; Owned by -

On 2011-11-16 09:50:25, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:41:24, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 13:57:32, @DavidGoldwasser wrote:

Originally reported by Brent, still a valid bug.

On 2011-10-04 12:09:15, @DavidGoldwasser wrote:

When I do push pull operations either the new surface or the adjoining surface isn't rendering correctly when you make a new surface. In my testing when classifying was correct, one of the old surfaces losing its link to rendering modes. When the classification is incorrect, it is the new surface that doesn't change render modes correctly (I expect the classification issue is more of a byproduct of same issue rather than cause. Two screenshots attached. I can show you this more tomorrow.

On 2011-10-04 12:10:24, @DavidGoldwasser wrote:

Created an attachment (id=34)
render by class

On 2011-10-04 12:10:52, @DavidGoldwasser wrote:

Created an attachment (id=35)
render by boundary

On 2011-10-04 22:17:57, @macumber wrote:

I'm having trouble reproducing, I know this has been an issue in the past

On 2011-11-16 09:50:38, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:41:36, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 10:28:39, @DavidGoldwasser wrote:

Dan, just re-tested and this is still an issue. Try splitting and using push pull 10 times or so and you should hit this issue (seems kind of random. Selecting the surfaces responds to the inspector, they just don't render correctly, yet things are fine when you re-open.

On 2012-01-17 10:30:19, @DavidGoldwasser wrote:

Created an attachment (id=133)
Screenshot after multiple split/push pull operations

Original attachments:

• pushpull01.png (ID 34)
• pushpull02.png (ID 35)
• bug303_0117.png (ID 133)

Keywords: Random, SyncWithSU

On 2011-11-28 15:34:29, @macumber wrote:

OpenStudio Inspector. The inspector chops off the edit fields/drop down boxes of the inspector.

On 2012-01-13 15:22:01, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2011-12-02 14:38:39, @macumber wrote:

https://openstudio.nrel.gov/forums/openstudio-plug-google-sketchup/bug-reports-and-feature-requests/apparent-geometry-error-open

On 2011-12-14 10:47:48, @DavidGoldwasser wrote:

Dan, can this be related to bug number 11?
http://cbr-drupaldev.nrel.gov/bugzilla/show_bug.cgi?id=11

Site Shading surfaces are improperly displayed when there is a a non-0 building rotation

That was fixed a long time ago, but maybe broke again?

On 2012-01-09 13:51:08, @DavidGoldwasser wrote:

This user seems to have same issue.

On 2012-01-09 13:51:20, @DavidGoldwasser wrote:

Forgot thread
https://openstudio.nrel.gov/forums/openstudio-plug-google-sketchup/help-desk/modified-idf

On 2012-01-16 14:49:28, @DavidGoldwasser wrote:

I think this is still a valid bug, but tagged as "Invalid?" so I remember to retest it.

On 2012-01-19 10:52:48, @DavidGoldwasser wrote:

Batch moving bugs from SketchUp to "Code" component

Keywords: Invalid?

On 2011-11-28 15:36:29, @macumber wrote:

This seems to be an issue with SketchUp on the Mac only.

On 2012-01-13 15:22:01, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-01-16 15:11:10, @DavidGoldwasser wrote:

The only way to fix this is to wait for SketchUp to fix it or migrate the entire toolbar over to OpenStudio.

Keywords: ReleaseNotes

On 2011-12-19 14:34:10, @axelstudios wrote:

Using SketchUp's undo operation on OpenStudio model elements may produce unexpected results.

On 2012-01-16 13:49:17, @DavidGoldwasser wrote:

While this is critical I don't know that we can tackle this until we have a debug build of SketchUp.

Other things that fit into this same category are other limitations of observers (e.g. multiple copy) backing out of group while things are still going on, seemingly random crashes while opening or working on a model.

On 2012-01-16 13:59:50, @DavidGoldwasser wrote:

While this really isn't random (just unknown cause) I tagged it with Random Keyword.

Keywords: Random, ReleaseNotes

On 2011-10-10 09:29:09, @DavidGoldwasser wrote:

We ran across this internally, and didn't find the cause. It came up in fixing errors in simulations runs. but was never its own bugs. We didn't figure out the cause of the warning, although it didn't seem to effect the output.

At any rate, came up in user questions, and seems worth fixing to me. I think happens an all simulation runs, or at least not a corner case.

content of post below
Hi, David: Thanks for replying to my .txt question. I think I'm going to walk away from that concern, however. I'm amazed at what OS is becoming. Its power and intuitiveness are far beyond any earlier version. Thanks for your great work. I am having to adjust to the drastic paradigm shift in 0.5.0, and I'm having a few hiccups. I get the warning "ProcessScheduleInput: Schedule:Compact="OS:THERMALZONE 2 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated." for each of my three zones. I've looked through all the schedules, schedule type limits, zone attributes, space type attributes, etc and I can't imagine what this means. Can you explain? Thanks, Randy

On 2011-10-26 11:36:19, @macumber wrote:

This is an automatically generated schedule 'Control Type Schedule Name' for 'ZoneControl:Thermostat'. Kyle can fix this.

On 2011-11-16 09:44:36, @DavidGoldwasser wrote:

These bugs had outdated milestone. Updated to next iteration.

On 2012-01-13 15:22:00, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-01-16 15:28:06, @DavidGoldwasser wrote:

*** Bug 332 has been marked as a duplicate of this bug. ***

On 2012-01-17 10:54:35, @DavidGoldwasser wrote:

*** Bug 272 has been marked as a duplicate of this bug. ***

On 2012-01-19 10:52:47, @DavidGoldwasser wrote:

Batch moving bugs from SketchUp to "Code" component

On 2012-09-09 23:54:51, @DavidGoldwasser wrote:

Maybe this warning will disapppear if we write type limits out. I need to test with 0.8.5

On 2012-12-21 12:03:33, @DavidGoldwasser wrote:

Moving from Normal to major to hilight that it is still open. Producing tons of warnings that makes it harder to find meaningful warnings in energyplus error files. There wasn't a way to fix this before we had schedule types in OpenStudio. But now that we do it seems we should wrtie them to IDF.

On 2013-01-07 08:46:54, @DavidGoldwasser wrote:

Just to document which schedules don't write type limits out correctly to EnergyPlus. I was going to paste the errors from the regression testing, but this seems more extensive. It also has SHW. I'll attach this file which was from our boot camp training.

** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_SUMMER_DESIGN_DAY 2", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_WINTER_DESIGN_DAY 3", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_DEFAULT 6", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_WINTER_DESIGN_DAY 2", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_DEFAULT 5", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_DEFAULT", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_WINTER_DESIGN_DAY 5", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_WINTER_DESIGN_DAY 7", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="OS:SCHEDULE:DAY 1", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_SUMMER_DESIGN_DAY", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_SUMMER_DESIGN_DAY 7", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_DEFAULT 4", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_WINTER_DESIGN_DAY 6", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_WINTER_DESIGN_DAY 4", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_SUMMER_DESIGN_DAY 4", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_WINTER_DESIGN_DAY", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_DEFAULT 2", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_SUMMER_DESIGN_DAY 3", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_SUMMER_DESIGN_DAY 5", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_DEFAULT 7", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_SUMMER_DESIGN_DAY 6", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="ALWAYS_ON_DEFAULT 3", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="OS:SCHEDULE:DAY 2", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Year="ALWAYS_ON 5", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Year="WATER HEATER AMBIENT TEMPERATURE SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Year="ALWAYS_ON 4", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Year="WATER HEATER SETPOINT TEMPERATURE SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Year="ALWAYS_ON 3", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Year="ALWAYS_ON 6", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Year="ALWAYS_ON 7", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Year="ALWAYS_ON 1", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Year="ALWAYS_ON 8", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="SCHEDULE:COMPACT {55806BA0-FA33-4649-BED6-0C21AE02207B}", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="SCHEDULE:COMPACT {48A4AEA5-D11B-4E70-B133-54ABC4289EE1}", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="SCHEDULE:COMPACT {2246B34F-15CC-49B7-B3CE-81F2C0E95085}", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="SCHEDULE:COMPACT {5D338CD5-EF0F-409D-8D33-1698237F858E}", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="PLANT LOOP 3 ON SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="PLANT LOOP 2 ON SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="PLANT LOOP 4 ON SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="PLANT LOOP 1 ON SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 4 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 3 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 5 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 2 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 1 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.

On 2013-01-07 08:47:40, @DavidGoldwasser wrote:

Created an attachment (id=260)
File from bootcamp training. Just add Chicago weather file and run

On 2013-01-07 08:48:58, @DavidGoldwasser wrote:

Below are similar errors from Regression testing for System 7

** Warning ** ProcessScheduleInput: Schedule:Day:Interval="SCHEDULE DAY 2", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="SCHEDULE DAY 4", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="SCHEDULE DAY 3", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Day:Interval="SCHEDULE DAY 5", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="SCHEDULE:COMPACT {D42A0875-CBD2-470C-B371-59ED476CC4B9}", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="SCHEDULE:COMPACT {9E07FCC6-2688-40DE-ADAA-CD8EF952DD03}", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="PLANT LOOP 3 ON SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="PLANT LOOP 1 ON SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="PLANT LOOP 2 ON SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 7 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 4 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 3 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 8 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 9 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 1 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 10 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 5 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 6 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.
** Warning ** ProcessScheduleInput: Schedule:Compact="THERMAL ZONE 2 THERMOSTAT SCHEDULE", Blank Schedule Type Limits Name input -- will not be validated.

On 2013-01-10 11:36:05, @DavidGoldwasser wrote:

<batch comment: added this to Pivotal Epic, https://www.pivotaltracker.com/epic/show/458473>

Original attachments:

• BasicWorkflow_ex08.osm (ID 260)

Keywords: ForwardTranslation

On 2011-12-28 12:15:47, @DavidGoldwasser wrote:

Created an attachment (id=98)
Sample file imported into OpenStudio and unsupported objects sent out.

This file has duplicate objects of this. The example file is in E+7 install. I have attached the exported file from OpenStudio.

WindowMaterial:Blind,
BLIND, !- Name
HORIZONTAL, !- Slat Orientation
0.025, !- Slat Width {m}
0.01875, !- Slat Separation {m}
0.001, !- Slat Thickness {m}
45.0, !- Slat Angle {deg}
0.1, !- Slat Conductivity {W/m-K}
0.0, !- Slat Beam Solar Transmittance
0.7, !- Front Side Slat Beam Solar Reflectance
0.7, !- Back Side Slat Beam Solar Reflectance
0.0, !- Slat Diffuse Solar Transmittance
0.7, !- Front Side Slat Diffuse Solar Reflectance
0.7, !- Back Side Slat Diffuse Solar Reflectance
0.0, !- Slat Beam Visible Transmittance
0.5, !- Front Side Slat Beam Visible Reflectance
0.5, !- Back Side Slat Beam Visible Reflectance
0.0, !- Slat Diffuse Visible Transmittance
0.5, !- Front Side Slat Diffuse Visible Reflectance
0.5, !- Back Side Slat Diffuse Visible Reflectance
0.0, !- Slat Infrared Hemispherical Transmittance
0.9, !- Front Side Slat Infrared Hemispherical Emissivity
0.9, !- Back Side Slat Infrared Hemispherical Emissivity
0.050, !- Blind to Glass Distance {m}
0.5, !- Blind Top Opening Multiplier
0.5, !- Blind Bottom Opening Multiplier
0.0, !- Blind Left Side Opening Multiplier
0.0, !- Blind Right Side Opening Multiplier
0, !- Minimum Slat Angle {deg}
180; !- Maximum Slat Angle {deg}

On 2011-12-29 09:06:53, @DavidGoldwasser wrote:

Given some more thought I'm pretty sure this is related to bug 451 which is about a construction being removed from the OSM without being added to the unsupported file. This is the material in question that caused the construction to be invalid. I assume that the duplicate copy of the material was mistakenly added instead of the construction which should have been added.

On 2012-01-13 15:22:03, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2012-01-19 10:52:48, @DavidGoldwasser wrote:

Batch moving bugs from SketchUp to "Code" component

Original attachments:

• test-Untranslated.idf (ID 98)

This doesn't seem to be affecting build versions. It is happening on Mac and Windows.

Elaine has a proposed change to CreateQAQCXML.rb to add the following line.

OpenStudio::Application::instance().application()

This worked on Windows, but not Mac. Dan thinks that following code in FileInfo.hpp is the issue.

const FileInfo &getLast(const boost::function<bool (const FileInfo &)> &f) const
{
  std::vector<openstudio::runmanager::FileInfo>::const_reverse_iterator itr 
    = std::find_if(m_files.rbegin(), m_files.rend(), f);

  if (itr != m_files.rend())
  {
    return *itr;
  }

  throw std::runtime_error("FileInfo not found");
}

On 2011-12-28 12:21:31, @DavidGoldwasser wrote:

When you choose a OS:ThermosatSetpoint:DualSetpoint object and click the heating setpoint temperature schedule name pull down all schedules show up twice. For cooling it is only once, and in most cases it only shows up once. Something odd happened with this specific menu. I hesitate to even file this as a bug as it should be deprecated with the new interface, but I thought I'd file just so the cause can be identified so it doesn't happen in elsewhere in the new interface.

I suppose we could fix this for an 0.6.x version, but it is so trivial may not be worth even the time to fix.

David

On 2012-09-10 01:05:22, @DavidGoldwasser wrote:

Still valid in 0.8.4

On 2013-01-10 11:36:09, @DavidGoldwasser wrote:

<batch comment: added this to Pivotal Epic, https://www.pivotaltracker.com/epic/show/458473>

Keywords: OldGUI

On 2011-08-24 15:53:47, @lefticus wrote:

There are SSH connection problems when queuing a large set of Job at once. The connection appears to time out during the process, then fail when the jobs actually begin.

On 2011-10-09 21:52:29, @lefticus wrote:

Raising priority to "Major" if any large projects (like 179d) are to be attempted again, stabilizing the SSH support will be important.

On 2011-11-16 09:50:33, @DavidGoldwasser wrote:

Moving older bugs to "retest" milestone. Will re-test these and then assign to appropriate milestone. These were all 0.6.0 prior to change.

On 2011-11-17 10:41:33, @lgentile wrote:

Still potential issue. This was an old bug. Please re-test/verify.

On 2012-01-17 13:31:18, @DavidGoldwasser wrote:

Check with Jason to see if this is still valid

Keywords: Invalid?

On 2011-07-01 13:22:39, @DavidGoldwasser wrote:

I think this is really important but is pretty deep in the software, will have to wait until there is a larger overhaul to fix (that is why it shows as low)

Bug imported from Excel; Status -unknown; Created on - 12/29/10; By - Daniel Macumber; Owned by - Daniel Macumber

On 2011-10-04 10:16:32, @macumber wrote:

Also generates this ruby error on idf import (think this is on the IES side):

Error: #<NoMethodError: undefined method visible?' for nil:NilClass> (eval):792:in onShadowInfoChanged'

On 2011-10-05 16:21:43, @DavidGoldwasser wrote:

I close this, but is a quick fix, and still doesn't isolate us from future conflicts with IES or other plugins. May have to address this again.

On 2013-03-25 15:21:54, @DavidGoldwasser wrote:

Since this is still in release notes and is still an issue waiting to be fixed at some point, I re-opened this bug.