EcoDesigner and EcoDesigner STAR are unusable for design?

[Anonymous]

EDIT: As it stands today (May 2014, AC17 build 6004) this issue is still not resolved. It has been over a year.

EcoDesigner STAR does not appear to be AHSRAE compliant and should not be advertised as such.

As it stands today (March 2014, AC17 build 5019), both, standard EcoDesigner and a commercial version of EcoDesigner STAR have a fundamental flaw in a calculation of solar gain causing these add-ons to overestimate needed cooling by a huge margin, basically rendering these programs unusable for sustainable architectural design.

Moreover, this is not a new issue. It goes back for more than a year and started when AC17 was released in summer 2013.

I, personally, made this issue public back in summer 2013, shortly after the initial release of AC17, and brought it to Graphisoft's attention in this thread: Solar Analysis is not accounted in Energy Simulation (AC17).

However the issue is not resolved after 6(!) updates to the main program.


The root of this problem is very simple:

One of widely advertised features of AC17 is a, so called, concept of "model-based shading". The idea behind this concept is that a shaded opening (glass door or window) will not add to the solar gain calculations, thus providing architects with fundamental tool of sustainable architectural design.

In other words, if the window facing the sun in your project is shaded by model geometry (overhangs, adjacent walls or buildings, trees, etc.), EcoDesigner and EcoDesigner STAR are marketed as being able to account for that and subtract appropriate amount from total solar gain calculations. In reality - they do not.

Both, EcoDesigner built into AC17 and an expensive add-on EcoDesigner STAR, fail to calculate this issue properly, subsequently, grossly overestimating needed cooling equipment.

I did see a few threads in this forum asking questions about overinflated energy readings for buildings designed, but it appears people do not realize where these miscalculations come from.

Let me explain.

If you have any windows in your project receiving direct sunlight (How many of us have windows in our projects? All of us?) these windows will always be shown as unshaded no matter how you cover them up with model geometry.

Even a solid wall placed right in front of these windows will not prevent EcoDesigner or EcoDesigner STAR from showing these windows as being constantly exposed to direct sunlight throughout a year.

This basically means that EVERY AC17 project that uses EcoDesigner or EcoDesigner STAR (which is worse, as EcoDesigner STAR is a paid add-on, is expensive to own and supposed to be "Standard Compliant") will give erroneous results.

Interestingly, all windows in question are properly calculated and shown as shaded under EcoDesigner's or EcoDesigner STAR's "solar analysis" dialog accessible from "Openings" tab in "Energy Model Review" dialog box.

Moreover, kWh redings for any window shaded by model geometry is also properly reduced.

However, this reduction in kWh never makes it to the Energy Evaluation Report and every window is assumed to be unshaded there, thus ALWAYS showing exaggerated solar gain for any thermal block with windows oriented toward the sun, even if they are completely shaded by a solid wall built wight on top of them.

I am curious. This issue is around since AC17 came out, but I constantly see published success stories of architectural buildings being designed with AC17 and EcoDesigner and supposedly properly calculated in relation to sustainable design.

I wish I knew how they did it. Am I the only one here with this issue?

It is very easily reproduced and ANY project relying on EcoDesigner and model-based shading will ALWAYS give erroneous results.

Basically, until this issue is fixed, AC17 and EcoDesigner or EcoDesigner STAR are a dead weight in sustainable design.

Thoughts?

[hampden]

PLEASE PLEASE PLEASE FIX THIS!

I was so excited about being able to finally use this for passive solar analysis, and I get the same results as "EcoBoger" - model based solar analysis is not being taken into account in the energy balance reports.

WHATS UP WITH THAT? It's obviously doing the work in the solar analysis energy model review dialogue, why aren't these numbers making their way to the energy balance report? This makes overall comparison between scheme changes worthless from a cooling or heating perspective, if all the windows are assumed to have 100% exposure, they could be completely blocked or optimally shaded and it shows no difference.

WOULD SOMONE FROM GRAPHISOFT PLEASE RESPOND TO THESE CONCERNS AND LET US KNOW WHEN IT WILL BE FIXED? I have projects in the works which I've touted our ability to provide energy guidance for and I'm embarrassed to show such obviously unrealistic reports to the clients. This is so basic (and seemingly so simple to fix since all the work appears to have been done to implement model based shading), I don't understand how it can go unaddressed.

-Stefan

EcoBoger wrote:
As it stands today (March 2014, AC17 build 5019), both, standard EcoDesigner and a commercial version of EcoDesigner STAR have a fundamental flaw in a calculation of solar gain causing these add-ons to overestimate needed cooling by a huge margin, basically rendering these programs unusable for sustainable architectural design.

Moreover, this is not a new issue. It goes back for more than a year and started when AC17 was released in summer 2013.

I, personally, made this issue public back in summer 2013, shortly after the initial release of AC17, and brought it to Graphisoft's attention in this thread: Solar Analysis is not accounted in Energy Simulation (AC17).

However the issue is not resolved after 6(!) updates to the main program.


The root of this problem is very simple:

One of widely advertised features of AC17 is a, so called, concept of "model-based shading". The idea behind this concept is that a shaded opening (glass door or window) will not add to the solar gain calculations, thus providing architects with fundamental tool of sustainable architectural design.

In other words, if the window facing the sun in your project is shaded by model geometry (overhangs, adjacent walls or buildings, trees, etc.), EcoDesigner and EcoDesigner STAR are marketed as being able to account for that and subtract appropriate amount from total solar gain calculations. In reality - they do not.

Both, EcoDesigner built into AC17 and an expensive add-on EcoDesigner STAR, fail to calculate this issue properly, subsequently, grossly overestimating needed cooling equipment.

I did see a few threads in this forum asking questions about overinflated energy readings for buildings designed, but it appears people do not realize where these miscalculations come from.

Let me explain.

If you have any windows in your project receiving direct sunlight (How many of us have windows in our projects? All of us?) these windows will always be shown as unshaded no matter how you cover them up with model geometry.

Even a solid wall placed right in front of these windows will not prevent EcoDesigner or EcoDesigner STAR from showing these windows as being constantly exposed to direct sunlight throughout a year.

This basically means that EVERY AC17 project that uses EcoDesigner or EcoDesigner STAR (which is worse, as EcoDesigner STAR is a paid add-on, is expensive to own and supposed to be "Standard Compliant") will give erroneous results.

Interestingly, all windows in question are properly calculated and shown as shaded under EcoDesigner's or EcoDesigner STAR's "solar analysis" dialog accessible from "Openings" tab in "Energy Model Review" dialog box.

Moreover, kWh redings for any window shaded by model geometry is also properly reduced.

However, this reduction in kWh never makes it to the Energy Evaluation Report and every window is assumed to be unshaded there, thus ALWAYS showing exaggerated solar gain for any thermal block with windows oriented toward the sun, even if they are completely shaded by a solid wall built wight on top of them.

I am curious. This issue is around since AC17 came out, but I constantly see published success stories of architectural buildings being designed with AC17 and EcoDesigner and supposedly properly calculated in relation to sustainable design.

I wish I knew how they did it. Am I the only one here with this issue?

It is very easily reproduced and ANY project relying on EcoDesigner and model-based shading will ALWAYS give erroneous results.

Basically, until this issue is fixed, AC17 and EcoDesigner or EcoDesigner STAR are a dead weight in sustainable design.

Thoughts?

[Anonymous]

PLEASE, PLEASE FIX THESE PROBLEMS.

We too are running into major problems with EcoDesigner failing to account for things like overhands and shading as well as other composite structures that actually provide insulation around non-conditioned volumes of interior space. Also, trees with detailed leaf canopies bring ArchiCAD to its knees - solar analysis can take up to 18 hours just to get beyond Phase 5 of its calculations.

Just as troubling is that EcoDesigner calculates R-Values as being higher for windows the lower the grade of window framing you choose. Select double glazing low-E glass (R4.37) and a "basic" steel frame (R7.25) and EcoDesigner calculates a combined R-value of 2.44. Now choose "Ultimate" for the metal framing and the R-Value for the opaque part of the window now drops to 0.78 giving a combined R-Value for the window of 1.48.

Somehow the calculations are upside down. But they need to be fixed otherwise we cannot use EcoDesigner - or EcoDesiger Star (for which we have a license) to conduct any reliable energy assessments for our clients.

Lastly - Operational profiles. I've mentioned this before in previous posts but the same issue exists within EcoDesigner. In the "daily schedules" part of EcoDesigner the application still insists on users typing in the floor area per person for the building. This seems to be an utterly illogical requirement because ArchiCAD already knows the square footage of the building (via Zones) and the architects and clients know how many people will be occupying it. Moreover, Fire and Safety codes around the world define occupancy levels for different kinds of buildings. Thus EcoDesigner's Daily Schedule should only ask for the number of occupants and NOT a guestimate of the square footage per person in the building. Such guestimates are far too arbitrary.

I do hope someone at Graphisoft is reading these posts from users and listening to the problems that continue to plague EcoDesigner and Ecodesigner Star.

[Miklos Sved]

Dear pallsopp42, hampden, EcoBoger

Thank you for reporting these issues!

In your posts you made several comments. I will address them one-by-one in my upcoming posts but let me start by letting you know that we are working on the bugfixes - where applicable - which will be made available to all EcoDesigner STAR and ArchiCAD Energy Evaluation users ASAP.

Best Regards,

Miklos Sved
Product Manager

[Miklos Sved]

Dear EcoBoger,

Thank you for revealing a bug in the model based solar irradiation functionality of GRAPHISOFT Sustainable Solutions!

The technical background information regarding this issue is the following:

First, the Model Based Solar Irradiation functionality prepares the hourly shadow masks on every transparent element of the building envelope. This data is stored in schedules.

These BIM-based data schedules then must be translated to ASHRAE shadow mask model input data format, which is the data format the VIP-Core simulation kernel (and other ASHRAE-compliant simulation engines) can process. This format defines the shadow masks using pairs of angles on the window's 2D projections to define horizontal and vertical shadow casting edges.

This simplified input methodology was standardized in the pre-BIM times by ASHRAE and is actually much less accurate then the data we get from the BIM. Still, the simplifying conversion must be made to satisfy the industry standard for building energy modeling.

A typo in this conversion algorithm is the root of the bug you report in your post. Interestingly, it does not always give faulty results as you claim - only in case of shadow masks of certain shapes - which makes detecting this bug difficult. We used the relevant ASHRAE 140 Standard Test cases (Case600, Case610, Case620, Case630, Case900, Case910, Case920, Case930) to check the accuracy of our solar study, which - interestingly - all give correct results. Please download the PLNs of these test cases from here if you wish to try running them yourself:
https://graphisoft.sharefile.com/d/sa7f66eab4454d558

The issue detailed above is quite similar to the one you reported in the summer of 2013. Still, they are two completely separate issues. The one you reported in the summer of 2013 was corrected in ArchiCAD 17 Hotfix 3.

The frustrating thing about this kind of bugs for us software developers is that we get the "difficult" part (the BIM based solar analysis) dialed but a stupid error in the "easy" bit of the code can sometimes still ruin the overall functionality. Now matter how hard we test the product - in this case using the ASHRAE 140 protocol (which is globally regarded as the most demanding test of Building Energy Simulation functionality) and also using other case studies - it's impossible to cover all geometries and situations.

Therefore I thank you again for sharing your findings with us - the fix will be available in the next ArchiCAD 17 Hotfix.

Best Regards,

Miklos Sved

EcoBoger wrote:
As it stands today (March 2014, AC17 build 5019), both, standard EcoDesigner and a commercial version of EcoDesigner STAR have a fundamental flaw in a calculation of solar gain causing these add-ons to overestimate needed cooling by a huge margin, basically rendering these programs unusable for sustainable architectural design.

Moreover, this is not a new issue. It goes back for more than a year and started when AC17 was released in summer 2013.

I, personally, made this issue public back in summer 2013, shortly after the initial release of AC17, and brought it to Graphisoft's attention in this thread: Solar Analysis is not accounted in Energy Simulation (AC17).

However the issue is not resolved after 6(!) updates to the main program.


The root of this problem is very simple:

One of widely advertised features of AC17 is a, so called, concept of "model-based shading". The idea behind this concept is that a shaded opening (glass door or window) will not add to the solar gain calculations, thus providing architects with fundamental tool of sustainable architectural design.

In other words, if the window facing the sun in your project is shaded by model geometry (overhangs, adjacent walls or buildings, trees, etc.), EcoDesigner and EcoDesigner STAR are marketed as being able to account for that and subtract appropriate amount from total solar gain calculations. In reality - they do not.

Both, EcoDesigner built into AC17 and an expensive add-on EcoDesigner STAR, fail to calculate this issue properly, subsequently, grossly overestimating needed cooling equipment.

I did see a few threads in this forum asking questions about overinflated energy readings for buildings designed, but it appears people do not realize where these miscalculations come from.

Let me explain.

If you have any windows in your project receiving direct sunlight (How many of us have windows in our projects? All of us?) these windows will always be shown as unshaded no matter how you cover them up with model geometry.

Even a solid wall placed right in front of these windows will not prevent EcoDesigner or EcoDesigner STAR from showing these windows as being constantly exposed to direct sunlight throughout a year.

This basically means that EVERY AC17 project that uses EcoDesigner or EcoDesigner STAR (which is worse, as EcoDesigner STAR is a paid add-on, is expensive to own and supposed to be "Standard Compliant") will give erroneous results.

Interestingly, all windows in question are properly calculated and shown as shaded under EcoDesigner's or EcoDesigner STAR's "solar analysis" dialog accessible from "Openings" tab in "Energy Model Review" dialog box.

Moreover, kWh redings for any window shaded by model geometry is also properly reduced.

However, this reduction in kWh never makes it to the Energy Evaluation Report and every window is assumed to be unshaded there, thus ALWAYS showing exaggerated solar gain for any thermal block with windows oriented toward the sun, even if they are completely shaded by a solid wall built wight on top of them.

I am curious. This issue is around since AC17 came out, but I constantly see published success stories of architectural buildings being designed with AC17 and EcoDesigner and supposedly properly calculated in relation to sustainable design.

I wish I knew how they did it. Am I the only one here with this issue?

It is very easily reproduced and ANY project relying on EcoDesigner and model-based shading will ALWAYS give erroneous results.

Basically, until this issue is fixed, AC17 and EcoDesigner or EcoDesigner STAR are a dead weight in sustainable design.

Thoughts?

[Anonymous]

One other item regarding EcoDesigner and Ecodesigner Star are the options we have for cooling systems. In most parts of the United States (and certainly in Mexico and other countries even closer to the equator) cooling - not heating - is the major draw on electric power. In the US we have several systems to choose from:

• Window and Through-the-wall air conditioners
  Ductless Split and Mini-duct systems (Mitsubishi, Freidrich, LG, GE etc.)
  Central air handlers with an external heat pump for chilling the refrigerant (Trane, Lennox, GE etc.)
  Attic heat pumps and air handler "Packaged Units" serving insulated flexible or rigid ducts (Trane, Lennox, GE etc.)
  Rooftop packaged HVAC units (heat pump and blower pumping cooled air into ductwork)

Currently, ArchiCAD appears to be more oriented toward climatic conditions that require heating systems rather than the range of cooling systems that are in fact specified and used everyday in the US.

Is there any chance at all that in up-coming versions of EcoDesigner, we will be able to load a "US Systems" version so we can properly and accurately calibrate EcoDesigner and/or EcoDesigner Star using actual manufacturers equipment technical specifications?

I realize that some work needs to be done to correct the significant errors that many of us have been reporting. However, Graphisoft has a lot of users in the US and I would urge the development team in Budapest and in Newton, MA to please use our insights and experience to help Graphisoft to create a version of EcoDesigner that is more tuned to the realities of "Building Systems" that apply to everyday US practice.

[Anonymous]

Dear Miklos,

I took a few months to see if this thread will generate any interest, but given total lack of relevant posts from other users, I can only assume that hampden, pallsopp42 and I are the only people in the world interested in using EcoDesigner STAR in our practice at the moment.

Miklos wrote:
We used the relevant ASHRAE 140 Standard Test cases (Case600, Case610, Case620, Case630, Case900, Case910, Case920, Case930) to check the accuracy of our solar study, which - interestingly - all give correct results. Please download the PLNs of these test cases from here if you wish to try running them yourself:
https://graphisoft.sharefile.com/d/sa7f66eab4454d558

I am not sure who provided you with the information about cases listed above to be properly calculated, but none of them (i.e. 610, 910 etc.) that have to do with solar shading are.

Basically, this makes EcoDesigner STAR not compliant with ASHRAE standards no matter the marketing hype.

As of ArchiCad 17 release 5019 this issue stands tall. No matter how much external shading you have in your project you will always get the same solar load on any window with or without external shading. Period. No exceptions. This is not a specific issue. This happens every time, in any project, on any window.

I think you should really look into your QA staff. This issue is so easy to spot, it should take only a minute for any qualified QA personnel.

Moreover, as of ArchiCad 17 release 6004, this issue still exists, although in a much reduced form.
It almost appears that instead of resolving this issue properly someone literally tried to get the numbers match in the end report. We all used to do that in middle school, but I didn't know this practice still in use in professional development.

To test, simply take AC 17 v 5019 and open your own file Case610 or Case910. Then run energy evaluation as is. Then, remove an overhang shading device, update the model and run evaluation again, effectively transforming Case610 and Case 910 into cases 600 and 900 respectively. THERE IS NO DIFFERENCE! There is no difference even if you completely block the sun with a single wall right outside your windows!

What ASHRAE compliance are we talking about?

Lets look into AC 17 v 6004. Same routine. Open your own file Case610 or Case910. Then run energy evaluation as is. Then, remove an overhang shading device, update the model and run evaluation again, effectively transforming Case610 and Case 910 into cases 600 and 900 respectively.
Now, we definitely see the reduction.
Does it work? Not really.
Try to completely block the sun from your windows and you are still left with plenty of solar load in the final report that comes from windows and not from any other object in the BEM.
Removing windows from your file removes solar load, adding them (even completely blocking them from sun by extending slab, walls and roof forward) instantly brings back a portion of solar load.

Miklos wrote:
The issue detailed above is quite similar to the one you reported in the summer of 2013. Still, they are two completely separate issues. The one you reported in the summer of 2013 was corrected in ArchiCAD 17 Hotfix 3.

Actually, it is the same exact issue I detailed in my thread related to this issue as far back as June 2013. You can read my initial post here: Solar Analysis is not accounted in Energy Simulation (AC17)

This issue being up for over a year and 7 hot fixes.
Could you please fix this? This is not an isolated case with specific shading mask translation. This affects EVERY WINDOW IN ANY PROJECT.

I know that you primarily work on something lots of people request and, since here are only tree people in the world willing to use EcoDesigner STAR, we are not a top priority, but unless this critical issue is resolved we can't use EcoDesigner STAR in our projects and YOU SHOULD NOT ADVERTISE IT AS ASHRAE COMPLIANT!

Since Graphisoft clients are led to believe they can, actually, use EcoDesigner STAR, they can, potentially, find themselves in a position that they can not deliver on promises to their clients and potentially lose business and that might cause some companies to attempt to take actions to recover lost income from Graphisoft directly.

Thank you.

[Miklos Sved]

Hi EcoBoger,

You make several strong claims in your post. I cannot agree with any of them.
In short:

-) Our modelling tools not working on your computer must be a hardware-specific issue that only very few users encounter. In house we cannot reproduce them, nor can thevast majority of our users.

-) Your remarks about ASHRAE testing and the envelope test cases are strange. I am in charge of designing and maintaining the ASHRAE 140 envelope test infrastructure myself, so the information I have regarding the topic is first hand. We have these tests running on our GS Autotest system on every daily build with no problems - I checked the results last Friday.

-) Fortunately, it's not only
"hampden, pallsopp42 and I are the only people in the world interested in using EcoDesigner STAR in our practice at the moment"
- as you stated in your post. The number of active EcoDesigner STAR users is in fact quickly approaching the four digits range. Consequentially, the number of ongoing EcoDesigner STAR projects are also quite numerous, out of which issues and complaints inevitably must surface.

Thankfully, most of them are resolved by our Technical Support team quickly and efficiently and very few end up as actual bugfixing tasks for us. Therefore, I also suggested to you - in my reply to the personal message you had sent me - to have a support session set up for you personally where we can go through each topic in details.

Afterwards, we could issue a post on this very thread together to clarify all misunderstandings.

Best Regards,

[Anonymous]

Wondering if the previous parties to this conversation are now in agreement and what that "agreement" might be.

[Anonymous]

At the risk of repeating myself regarding EcoDesigner calculation issues and errors, have the following items been addressed in any updates to EcoDesigner in ArchiCAD 18?

1) When selecting higher performing window frames, the R value drops (not good)

2) Adding physical shading elements over windows doesn't seem to make any difference to the energy consumption calculations but selecting a "shade type" from a list within EcoDesigner does. If we are building physical models of buildings, EcoDesiger should account for the effect of shading devices located on the building. Otherwise the shading devices, while they do indeed throw shadows, become far less useful and more in line with arbitrary applied "aesthetics" - something we avoid at all costs.

3) Placing trees near a building can bring EcoDesigner Star to its knees as it calculates the shading effect of leaves on the building - yet actual shading devices seem to have no bearing on EcoDesigner's energy assessment

4) Are we ever going to get the range of typical HVAC equipment in used in the US? For example, will EcoDesigner ever link HVAC objects such as ductless split air distribution units or specific heat pumps for ductless interior devices so as to account for the actual power loadings and the actual cooling (or air-heating) efficiency of these systems?

It is CRITICAL to professional credibility to have accurate calculations come out of EcoDesigner and EcoDesigner Star (why have two variants by the way when only one of them does the job?). Thus far as a firm using ArchiCAD 18 and Ecodesigner in the US, our requests seem to have fallen on deaf ears. At least that's how it feels as a firm whose primary focus in using ArchiCAD is to create accurate and complete physical models of structures, and not as a quasi drawing system for supplementing the typical architect's design office processes.

If we knew what the status was of these fixes and where they can be downloaded - e.g. new HotFixes for ArchiCAD 18 - it would let us know how to proceed - use EcoDesigner Star or just return to a completely unlinked, standalone "guestimate" system not connected to the BIM model, the latter of which is very unsatisfactory.

Any light you can shed on these issues would be very much appreciated.

Thanks

Phil
____________________
Phil Allsopp, D.Arch, M.S.(Public Health) RIBA, FRSA

Principal
Transpolis Global: USA, Inc.
W: www.transpolisglobal.com
E: phil_allsopp@transpolisglobal.com
E: pallsopp42@gmail.com

Phil Allsopp, RIBA, FRSA
Principal and Trustee
Smart Pad Living, LLC
E: pallsopp42@gmail.com

Adjunct Professor
ASU Global Institute of Sustainability
E: pallsopp@email.asu.edu

M: 480-276-7707
S: philallsoppskype
T: pallsoppRIBAUSA

ArchiCAD 18
EcoDesigner STAR
MEP
CADIMAGE electrical

OS X (Yosemite Beta + OS X 10.9.4)
iMac (3.4 GHz Intel Core i7; 16GB RAM)