I have added some comments in between your wish list.
The OpenStudio and the EPlus teams have done a very good job in providing such a comprehensive environment saving software.
I mainly used the EPlus modules for my work.
Dr. Li
To: EnergyPlus_Support@xxxxxxxxxxxxxxx; openstudio-support@xxxxxxxxxxxxxxxxxxxxx
From: jones.0bj3@xxxxxxxxx
Date: Thu, 29 Dec 2011 15:20:03 +0100
Subject: [EnergyPlus_Support] E+/OpenStudio Christmas 2012 wishlist
So in closing, I would wish for a return to basics before adding all sorts of new features like radiance coupling, dakota interface, system outlining, online database, etc. For now I would prefer a much more boring Openstudio that does even complex geometry quickly and cleanly, and then my next wishlist will be for all the cool stuff.
All that aside, I'm grateful to all the devs who have put in countless hours of work envisioning and implementing a revolutionary modeling tool free of charge for the world, keep up the good work!
Excuse cross posting, and have a great holiday,
Marcus
--
Marcus Jones, M.Sc., LEED®AP BD+C
Freelance energy consultant
Vienna, Austria
__._,_.___
Primary EnergyPlus support is found at:
http://energyplus.helpserve.com or send a message to energyplus-support@xxxxxxxx
The primary EnergyPlus web site is found at:
http://www.energyplus.gov
The group web site is:
http://groups.yahoo.com/group/EnergyPlus_Support/
Attachments are currently allowed but be mindful that not everyone has a high speed connection. Limit attachments to small files.
EnergyPlus Documentation is searchable. Open EPlusMainMenu.pdf under the Documentation link and press the "search" button.
![]()
__,_._,___
The OpenStudio and the EPlus teams have done a very good job in providing such a comprehensive environment saving software.
I mainly used the EPlus modules for my work.
Dr. Li
To: EnergyPlus_Support@xxxxxxxxxxxxxxx; openstudio-support@xxxxxxxxxxxxxxxxxxxxx
From: jones.0bj3@xxxxxxxxx
Date: Thu, 29 Dec 2011 15:20:03 +0100
Subject: [EnergyPlus_Support] E+/OpenStudio Christmas 2012 wishlist
As someone who does compliance and research building performance energy modeling with EnergyPlus on a daily basis: here is my wish list for next Christmas, nice and early.
My main wish is related to geometry creation for energy modeling. This is the foundation of an ASHRAE 90.1 model, and remains essentially the same for baseline and proposed models. This is always my first step in modeling. The under-development OpenStudio plugin for Sketchup is phenomenal, and a step in the right direction, but I still have some suggestions. Working directly, learning, and also starting to teach and supervise others, I feel like the geometry can get out of control for anything but a rectangular block building.
This is specifically related to my experience with the NREL OpenStudio project (not the legacy tool) and integrating it into my workflow with E+.
Here are some items on my list, all are related to Robustness of geometry creation;
1. Precision.
I constantly see 15 decimal points in my surfaces. Femtometers. This is the size of a PROTON!!!
BuildingSurface:Detailed, !
-10.893252914887839, !
3.5671903621940375, !
4.6999999999999993, !
In computers 4.6999999999999993 meters is not 4.7 meters, and might be causing problems with surface matching etc, and other strange bugs. Also file size, speed, and parsing issues. Each number is one byte of data, so say: 10 zones, 6 surfs per zone, 4 vertices per surface, 3 coordinates, 15 redundant characters per coordinate =~ 10 kB for a simple box building with no windows.
I do not have this problem myself. Only the OpenStudio and DesignBuilders seems to be using the negative numbers and long precisions. SketchUp Ori can be more precise using its lay-out program. The latest version EPlus would show 4.70 as 4.70000000 after passing the IDF file through the IDFeditor. I think, 1mm accuracy is more than enough for a building.
Maybe the problem is that Google Sketchup has no inherent "grid", only a precision setting. So I typically draw surfaces that are exact in width and height, but their absolute position in space might be offset by 0.000001. (1 mm resolution is sufficient for building drawings. Actual building tolence is only +-10 mm. Is this correct.)
2. Pre-flight
Desktop publishing has the notion of checking everything is ok before rendering or printing. I think we can learn from this and have a real-time check of the geometry as we draw it. The problem is that I can draw a surface which will cause errors (let's say a 5 edged window), and then I won't see it until I run the model, maybe a week later, and have to spend 5 minutes searching the model for FenestrationSurfaceDetailed Whatever.
I believe that some checking is done. if you use EPlus DesignDay and IdealLoadsAirSysem and a simple theremostat schedule, the building error can be discovered very quickly. I always start my simulation with this combination. This is equivalent to your bare bone template. The Zone thermostat and Zone:IdealLoadsAirSystem can all be included in a one line MACRO using ZoneName as the parameter.
Effectively, there are three secontions in the IDF. 1) the Location and run control.
2) the building with material and construction. 3) Zone load information and report variables. These will be the three include files in the IMF. The three files can be tested separately.
3. Bloat
I was disappointed to see a new file format (.OSM) with the OpenStudio project. We already have tens of extensions for E+, now we have another. A lot of the OS: objects seem redundant to IDF. Draw a single zone building in OpenStudio and save it. 200 kB and 6000 lines of text! I would prefer a bare-bones template which can be used to check the basic geometry before we move to applying loads and constructions (pre-flight). Maybe this is just because I'm on the outside and don't see the master plan behind the program and where the formats and interfaces are going.
I only use the OpenStudio to look at the building display and to find the surface ID, when I receive an IDF to debug.
(Aside: And I was surprised to see that the syntax is unchanged. What about XML as a new native format for E+? I personally parse everything to XML and then operate on the model for bulk actions and parametrization. I think OpenStudio does the same internally?? Or is it SQL? XML is a natural evolution for the IDF quasi-CSV syntax; each object in a tag, each attribute as a child, with extensions for units, the ! comments, XSLT transform, but I think the dev team is aware of this and moving towards something similar...?)
When plain text can be used, csv and rvi with ESO is sufficient.
The new SQL result viewer cannot display the two designDay results on one window or over the same time axis.
XML is used for SVG. XML is great with formating, but I am not sure that it can plot a curve without a point or data script to help.
IDD file is basically the input data for the Fortran modules.
The intruduction of Templates and EMS like controller/managers has confused the user.
4. Transparency
I haven't delved into the source code for OpenStudio, but it would be nice get some more feedback from the underlying engine. Is the code using a logging module? I only have Python experience, my world changed once I started to use it's native logging module. If there is, it would be nice to have a console window open in an advanced user mode or at least a text file dump with lots of feedback - where is the execution now? Which Module? How many surfaces did it find? What are they called? What are we doing with them? What errors and online fixes are made? This would help users provide feedback in the current beta phase, help to self-correct and understand, and help future developers.
The OpenStudio group have done a good job. It is very difficult to follow two different program sources, which are chaning independently. SketchUp is changing, and Eplus is changing, although they are two different parts of the IDF.
There are many reports generated in the EPlus. Audit, bnd, eio, html reports all have some error reporting and listing. Most diagnositic error messages in EPlus are very detailed now.
My main wish is related to geometry creation for energy modeling. This is the foundation of an ASHRAE 90.1 model, and remains essentially the same for baseline and proposed models. This is always my first step in modeling. The under-development OpenStudio plugin for Sketchup is phenomenal, and a step in the right direction, but I still have some suggestions. Working directly, learning, and also starting to teach and supervise others, I feel like the geometry can get out of control for anything but a rectangular block building.
This is specifically related to my experience with the NREL OpenStudio project (not the legacy tool) and integrating it into my workflow with E+.
Here are some items on my list, all are related to Robustness of geometry creation;
1. Precision.
I constantly see 15 decimal points in my surfaces. Femtometers. This is the size of a PROTON!!!
BuildingSurface:Detailed, !
-10.893252914887839, !
3.5671903621940375, !
4.6999999999999993, !
In computers 4.6999999999999993 meters is not 4.7 meters, and might be causing problems with surface matching etc, and other strange bugs. Also file size, speed, and parsing issues. Each number is one byte of data, so say: 10 zones, 6 surfs per zone, 4 vertices per surface, 3 coordinates, 15 redundant characters per coordinate =~ 10 kB for a simple box building with no windows.
I do not have this problem myself. Only the OpenStudio and DesignBuilders seems to be using the negative numbers and long precisions. SketchUp Ori can be more precise using its lay-out program. The latest version EPlus would show 4.70 as 4.70000000 after passing the IDF file through the IDFeditor. I think, 1mm accuracy is more than enough for a building.
Maybe the problem is that Google Sketchup has no inherent "grid", only a precision setting. So I typically draw surfaces that are exact in width and height, but their absolute position in space might be offset by 0.000001. (1 mm resolution is sufficient for building drawings. Actual building tolence is only +-10 mm. Is this correct.)
2. Pre-flight
Desktop publishing has the notion of checking everything is ok before rendering or printing. I think we can learn from this and have a real-time check of the geometry as we draw it. The problem is that I can draw a surface which will cause errors (let's say a 5 edged window), and then I won't see it until I run the model, maybe a week later, and have to spend 5 minutes searching the model for FenestrationSurfaceDetailed Whatever.
I believe that some checking is done. if you use EPlus DesignDay and IdealLoadsAirSysem and a simple theremostat schedule, the building error can be discovered very quickly. I always start my simulation with this combination. This is equivalent to your bare bone template. The Zone thermostat and Zone:IdealLoadsAirSystem can all be included in a one line MACRO using ZoneName as the parameter.
Effectively, there are three secontions in the IDF. 1) the Location and run control.
2) the building with material and construction. 3) Zone load information and report variables. These will be the three include files in the IMF. The three files can be tested separately.
3. Bloat
I was disappointed to see a new file format (.OSM) with the OpenStudio project. We already have tens of extensions for E+, now we have another. A lot of the OS: objects seem redundant to IDF. Draw a single zone building in OpenStudio and save it. 200 kB and 6000 lines of text! I would prefer a bare-bones template which can be used to check the basic geometry before we move to applying loads and constructions (pre-flight). Maybe this is just because I'm on the outside and don't see the master plan behind the program and where the formats and interfaces are going.
I only use the OpenStudio to look at the building display and to find the surface ID, when I receive an IDF to debug.
(Aside: And I was surprised to see that the syntax is unchanged. What about XML as a new native format for E+? I personally parse everything to XML and then operate on the model for bulk actions and parametrization. I think OpenStudio does the same internally?? Or is it SQL? XML is a natural evolution for the IDF quasi-CSV syntax; each object in a tag, each attribute as a child, with extensions for units, the ! comments, XSLT transform, but I think the dev team is aware of this and moving towards something similar...?)
When plain text can be used, csv and rvi with ESO is sufficient.
The new SQL result viewer cannot display the two designDay results on one window or over the same time axis.
XML is used for SVG. XML is great with formating, but I am not sure that it can plot a curve without a point or data script to help.
IDD file is basically the input data for the Fortran modules.
The intruduction of Templates and EMS like controller/managers has confused the user.
4. Transparency
I haven't delved into the source code for OpenStudio, but it would be nice get some more feedback from the underlying engine. Is the code using a logging module? I only have Python experience, my world changed once I started to use it's native logging module. If there is, it would be nice to have a console window open in an advanced user mode or at least a text file dump with lots of feedback - where is the execution now? Which Module? How many surfaces did it find? What are they called? What are we doing with them? What errors and online fixes are made? This would help users provide feedback in the current beta phase, help to self-correct and understand, and help future developers.
The OpenStudio group have done a good job. It is very difficult to follow two different program sources, which are chaning independently. SketchUp is changing, and Eplus is changing, although they are two different parts of the IDF.
There are many reports generated in the EPlus. Audit, bnd, eio, html reports all have some error reporting and listing. Most diagnositic error messages in EPlus are very detailed now.
So in closing, I would wish for a return to basics before adding all sorts of new features like radiance coupling, dakota interface, system outlining, online database, etc. For now I would prefer a much more boring Openstudio that does even complex geometry quickly and cleanly, and then my next wishlist will be for all the cool stuff.
All that aside, I'm grateful to all the devs who have put in countless hours of work envisioning and implementing a revolutionary modeling tool free of charge for the world, keep up the good work!
Excuse cross posting, and have a great holiday,
Marcus
--
Marcus Jones, M.Sc., LEED®AP BD+C
Freelance energy consultant
Vienna, Austria
__._,_.___
Primary EnergyPlus support is found at:
http://energyplus.helpserve.com or send a message to energyplus-support@xxxxxxxx
The primary EnergyPlus web site is found at:
http://www.energyplus.gov
The group web site is:
http://groups.yahoo.com/group/EnergyPlus_Support/
Attachments are currently allowed but be mindful that not everyone has a high speed connection. Limit attachments to small files.
EnergyPlus Documentation is searchable. Open EPlusMainMenu.pdf under the Documentation link and press the "search" button.
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___