First time here? Check out the Help page!
2020-12-14 07:42:05 -0500 | received badge | ● Necromancer (source) |
2019-06-12 19:33:39 -0500 | commented answer | How to measure heating degree day (HDD) and cooling degree day (CDD) for a building I might clarify that heating/cooling degree days (HDD/CDD) to my experience are a metric used to characterize climate/we |
2019-06-11 21:31:31 -0500 | answered a question | How to measure heating degree day (HDD) and cooling degree day (CDD) for a building If you are simply looking for degree day stats to fill in a box for something prescriptive like a LEED analysis, then Ja |
2019-06-11 19:40:53 -0500 | commented answer | How to measure heating degree day (HDD) and cooling degree day (CDD) for a building @lirainer : For your 2nd assertion: For degree-day analyses, I have commonly encountered heating/cooling systems "overl |
2019-06-11 19:34:33 -0500 | commented answer | How to measure heating degree day (HDD) and cooling degree day (CDD) for a building @lirainer : I believe one major contextual reason for the CDD50 and HDD65 temperature conventions is that those are the |
2018-10-27 09:00:51 -0500 | answered a question | Chiller water plant with absorption chiller with recovered heat source While for equipment like abs chillers I tend to err towards my own spreadsheet models wherein I can assure absolute cont |
2018-10-15 22:44:20 -0500 | answered a question | How to model constant air volume system using eQUEST? So to be clear, you have quite a few options with VAV and with CV system types in eQuest, and a VAV system made to produ |
2017-07-19 21:04:21 -0500 | answered a question | eQuest fan/exhaust static pressure units Interesting project. Alternatively, you could try using the peak of 15 inches w.c. and adjusting fan system efficiency |
2017-03-11 08:55:58 -0500 | commented answer | 90.1 Lab MakeUp Air unit flow I can't answer specifically how to handle this in OS/e+, however I believe 90.1 is referencing 50% of peak design flow (as driven by cooling or heating conditioning needs) in that specific clause. The next two parts of the sentence mean you must also meet minimum ventilation (62.1) and you must maintain minimum air change rates as required for laboratories. ACH rates can vary between lab types/usage, and is determined ultimately by (with) the owner/operator, who might not permit reducing ACH rates during unoccupied periods. Can you specify separate schedules for each requirement? |
2016-12-14 11:08:07 -0500 | answered a question | Reducing WWR to 40%: which approach? TLDR: I'm in complete agreement with Daric (he got my vote!), but don't see this as a binary question with only one right answer so I'm contributing some additional perspectives. I'm going to diverge a little from LEED / Appendix G and the 40% rule to tackle the topic of window distribution during model development more broadly as well, so I'm not expecting this to get upvoted as a best answer - just adding to the discussion: I typically also take the latter approach, adjusting each window's area in-place thereby retaining the proportionality of the window distribution by any metric: facade/surface/orientation. Appendix G contains fuzzy phrasing (subject to interpretation) with regard to maintaining the proposed cases' distribution proportion, and LEED/GBCI have interpreted that to mean you should maintain WWR by major orientation (still a fuzzy line for complex floorplates)... However my reading of Appendix G is that you CAN ultimately take either approach, and this decision is a good framework to consider for workflows both inside & outside of the confines of Appendix G. At times (early schematic/box-model studies come to mind), you might not know anything about the eventual window distribution (or what you do know is subject to major revisions), so uniform distribution could make the most sense when you don't have a better guess. More often, you as the modeler can make the informed decision that a strategy of uniform distribution for geometries is a "fair enough" estimation for model development (where the actual distribution is or could be relatively uniform), to allow you to smartly invest more of your limited development time in more pressing/important areas of the simulation. Consider: Appendix G has nothing to say about a "distribution accuracy threshold" in discussing the baseline model's fenestration requirements - it is more broadly concerned with ensuring the baseline/proposed case are on equal footing (at least at/below the 40% mark). In practice however, I have found aiming for "equal distribution" by facade/surface (by ensuring glass in on each opaque air-facing exterior surface) can become problematic, particularly in the proposed case. One reason is this can introduce "disconnects" with details of the proposed case HVAC system(s) design: You can end up for example with zones/systems that weren't designed to handle the new skin/solar loads introduced by "spreading the windows around," and conversely systems/zones designed to handle a lot of glass are now "oversized" in your model's representation. This leads to concessions either with more autosizing and/or more unmet conditioning hours taken as an acceptable threshold (potentially butting heads with App. G's thresholds). Minor reasons may include that the models can end up looking substantially different from the design (which is a big deal for some individuals), and also it can make for additional necessary documentation/explanation in a review process. I hope this helps suggest a few new ideas - In my mind there's a time & place for ... (more) |
2016-12-10 10:30:36 -0500 | commented question | Where can I find epw. of year 2050? I am no climate scientist, but I think you could clarify your question for more constructive replies by establishing whether (a) you have identified some specific (cite-able) research/model that suggests a "rise of 2°C," and you're looking for help supplementing that model to derive other columns of data to "fit the mold," or (b) if you're a few steps behind there and are requesting help finding papers/models that support your prediction/assertion of a "rise of 2°C" with other conditions. Regardless, you should probably also specify the location and extend your description for "rise of 2°C. |
2016-12-09 17:57:55 -0500 | answered a question | Plug loads estimate from electrical wiring capacity I've done a fair amount of electrical design for commercial / residential buildings and can affirm, there likely isn't any clear line to be drawn in most cases between electrical distribution/service calculations and trended electrical load profiles. Electrical distribution design (per NEC in the USA, at least) has a lot of safety built into the standard loads & sizing factors we attribute to receptacles, motors, lights, etc. We depend on those guidelines and upsizing factors to ensure we do not undersize our systems and cause a life/safety hazard (i.e. fires). More productively (kinda?), I suppose you could walk a path of using the associated feeder/circuit over current protection (fuses, circuit-breakers) to determine a ceiling on sustained (this is a loaded word - in electrical design terms I'm thinking minutes, not seconds) amperage draw, for the purposes of gut-checking the order of magnitude that your simulation's inputs produce for a peak demand interval... but if you polled 100 electrical designers I expect 99+ would sincerely hope that real world measurements would bear out some distance in peak sustained draw from what they sized up, else somebody is in hot water! Long story short: No, I don't believe you can use electrical power distribution calculations to productively estimate something like a plug load density or a plug load usage profile. Your electrical designer's calculations / specifications concerning large motor efficiencies, lighting, the likes of VFD's however are probably of much interest to the typical building simulation, so you should still buy him/her a beer when you have the opportunity! |
2016-12-02 04:53:52 -0500 | answered a question | eQUEST Batch Simulation Runs In the off-chance you're interested to get your feet wet with Python, somebody asked basically the same question for energyplus and I composed the following script/module. For situations like this calling for a large quantity of simulations, I prefer starting/developing my projects with eQUEST then leveraging the substantial speed gains from doe2 command line. The actual simulations will take only a fraction of the time. This will simulate every combination of BIN and INP files located in the same directory in quick order, and will retain/name the associated SIM with unique naming for clarity: As with Aaron's answer, this requires installing doe2 for command line operation. Note also that to get "direct" doe2 playing nicely with eQUEST-borne projects there's an extra step where you'll want to copy the contents of the eq_lib.dat file inside your eQUEST installation directories into the usrlib.dat located in the doe2 installation. That's explained further here. This additionally requires installing Python, so this answer ... (more) |
2016-11-18 08:02:37 -0500 | answered a question | eQUEST Sim.file corrupt Attempting an answer based on the commentary so far, I might hit the nail on the head but some shooting in the dark here! This sounds quite a bit like some related scenarios I've been hearing about on and off the [equest-users] list. While I have not run into this yet personally, I can assert you are not alone! Whatever the cause(s), SIM "corruption" issues appear new to version 3.65 build 7173 (the most recent version). I understand there are some established ties to when coil capacities are auto-sized (not specified) and improvements to the associated sizing routines, but an update/patch hasn't surfaced yet to resolve the problem. You can acquire an installer for the previously published version/build (3.65.7163) here: http://doe2.com/download/equest/ I consider build 7163 my "stable" version though I have 7173 installed alongside to explore & take advantage of the new features on occasion. If you're only going to have one installed (today) I'd recommend build 7163, and more specifically I recommend you give switching to 7163 a shot with your current project. That said, I'm not sure how smoothly continuing your model development in 7163 after starting in 7173 will go. I would suspect major problems if you were using the doe 2.3 engine in 7173, or otherwise still in wizard edits, but I'm not picking up that's the case from the commentary so far. Certainly worth a shot in a separately saved copy if you don't have time to wrestle with the issues. If you do have the time, I would recommend notifying Jeff Hirsch directly about your situation and sending him a copy of your project input files (pd2/inp/prd-if-occurring): james.j.hirsch@gmail.com . It could be your situation is related to the coil thing and they are already working on a fix, or else you may have stumbled into a case that could help them resolve the bug. If you don't mind sharing your efforts with the public, posting the same files and explaining the context so far to the [equest-users] mailing list will expose your case to more like me who may have the time to toy around and help you work around the current state of things: http://lists.onebuilding.org/listinfo... Best of luck! |
2016-11-18 07:40:38 -0500 | answered a question | Leed 2009 exterior lighting To my reading: You are correct to assert 0.7 kW for both proposed and baseline cases. "Zone 4" serves only to define the base allowance plus the allowances associated with your nontradable surfaces (likely building facades). Technically for LEED 2009, I think you should reference 90.7-2007 addendum i, but for simplicity you could also just look to 90.1-2010 Tables 9.4.3A/B and the associated passage. The exterior lighting power allowance will be 1.3 + (some multiplied value for tradable surfaces). That allowance cannot be exceeded by your 0.7 kW of installed power (so you should be in the clear). This understanding might be the source of the "warning" being thrown in the spreadsheet - perhaps you need to enter your lighting allowance inputs differently? I will insert however that it's kinda weird that you have absolutely zero tradable surfaces (unless you're asserting that for simplification reasons)... no illuminated main entry? |
2016-11-01 21:16:37 -0500 | commented question | eQUEST Sim.file corrupt Would it be a huge stretch to guess you're using the latest version/build of eQUEST (v3.65, build 7173), with the doe2.3 engine option, and that your model involves some degree of auto-sizing for coil capacities? Also how large is the SIM file, and can you open the SIM file with a text editor (like notepad)? |
2016-10-12 11:05:34 -0500 | commented answer | script for multiple simulations While it's a little depressing to learn something that informs me all my self-made conventions for self-documentation are wrong, this is the first anyone has alerted me to the concept of docstrings so on that level I'm quite thankful for Julien's commentary (and the helpful links)! I'll plan to review PEP 8/257, clean up my formatting, and re-re-update my answer later. Incidentally this is also the first I've realized one can review past edits by others - neat! |
2016-10-11 19:45:07 -0500 | edited answer | script for multiple simulations I used Amir's current answer to make a working script for doe22, v48r: EDIT (10/12/2016): ... and following is a more developed, current version of the same script. I am retaining the relatively simple example above in this answer to facilitate comparison and clarity of concept for others traversing the bridges between python, doe2, and e+. I was prompted in the answer commentary to try and make this script compatible when executed directly from notepad++. While I've pushed the module further in form/function, I'm not certain what made previous versions incompatible with notepad++ execution, and I only recently picked up the realization that was possible (I've been used to executing all python efforts to-date from powershell). The following is tested and working using Python 2.7 and the notepad++ plugin called "PyNPP" with the shortcut Alt+Shift+F5. I was also prompted to get my act together with respect to docstring styling. As a self-learner I appreciate the encouragement, and hopefully this is a little easier on our French friends' sensibilities now =)! (more) |
2016-10-11 18:39:36 -0500 | commented answer | script for multiple simulations @ ngkhanh : I'm not clear on your question... can you provide more context or information as to the errors you're running into? I should add that to-date I haven't really embraced executing my python scripts directly from notepad++. I always use powershell... EDIT: I've updated my answer to include a more current, polished version. Looks to be working when executed from notepad++ via the "PyNPP" plugin. |
2016-10-10 13:50:00 -0500 | commented answer | eQuest Geometry to EnergyPlus I see this is a year old, but count me in as interested in any updates concerning the capacity to create doe2 measures! I'm struggling right now to envision/create a means to distribute python-based tools (of which I suppose some might be analogous to "measures") out for others without a Python/programming background to leverage in doe2/eQUEST simulation development. |
2016-10-10 13:42:22 -0500 | commented answer | doe21e geometric input I can't constructively comment regarding drawBDL problems or OS export issues as these are not tools I've used much. Perhaps you could dig into & edit the OS-generated IDF file to resolve the error/fault you're observing in SIMEB... Maybe a new question (with pertinent details) is in order to re-address/summarize this query as an OS exporting / SIMEB importing issue? |
2016-10-06 13:37:45 -0500 | commented answer | doe21e geometric input Also: for drawBDL specific questions, @Joe Huang would be a naturally good bet to feel out limitations (and bonus for your query: IIRC he actually prefers doe2.1e as his engine of choice). I think however his contact info on http://www.drawbdl.com/ may be out of date. Here's what appears in his recent email signatures on the onebuilding.org mailing lists: Joe Huang White Box Technologies, Inc. 346 Rheem Blvd., Suite 205A Moraga CA 94556 yjhuang@whiteboxtechnologies.com http://weather.whiteboxtechnologies.com for simulation-ready weather data (o) (925)388-0265 (c) (510)928-2683 |
2016-10-06 13:32:45 -0500 | received badge | ● Commentator |
2016-10-06 13:32:45 -0500 | commented answer | doe21e geometric input I've had limited success converting from e+ --> doe2.2 using SIMEB. The resulting *.inp file includes SPACEs defined with unique polygons, but the child walls are defined via X/Y/Z/HEIGHT/WIDTH/AZIMUTH (independent of the polygons). Based on what you've shared (again I don't consider myself a doe2.1e expert), it sounds as though SIMEB will get you in the right ballpark. I should also advise planning for output QC time to fix issues with conversion via SIMEB. I recall issues like missing roofs and interior floors on floors abovegrade being incorrectly converted to exterior floors. |
2016-10-06 13:05:57 -0500 | commented answer | LEED Appendix G - System 7 or System 8? Thanks @MatthewSteen - is that something you would generally advise on unmethours.com when the character limit becomes a problem? I'm still learning the platform, but my usual intuition on "answer" vs. "comment" may be influenced by my extensive mailing list discussion history, where I'm usually building off someone else's contributions =). |
2016-10-02 23:18:45 -0500 | commented answer | [doe 2.1e] parametric setup I'd like to jump in and add: I've been developing some similar stuff with Python, specifically with mind to extract select outputs from doe2.2/2.3 borne SIM files. I'm actually wrestling in the present with re-tooling (breaking & rebuilding) a previously working script to generate a CSV in a format compliant wtih dview for easy visualizations. Would be happy to compare notes sometime to see how others are accomplishing similar tasks - maybe we can learn from each other! |
2016-10-02 23:10:34 -0500 | answered a question | doe21e geometric input Searching the reference manual for 2.1 I don't believe SHAPE = POLYGON is an option. Here is the entry for the SPACE keyword SHAPE in 2.1e:
In the 2.2 reference manual Vol-1 "Basics", I found the following quote, suggesting POLYGON space geometry definitions were a "new" thing as of 2.2:
(emphases mine) I think you have 2 options:
A qualifier: 2.1e is mostly before my time - I only really got started in the simulation world with 2.2. Others better qualified to answer might be more easily reached by cross posting into the [eQUEST-users] mailing list at onebuilding.org, but if you should need help identifying someone for a cold call let me know and I'll help point you in the right direction! Thinking forward: If you don't want to script out the math to determine each floor polygon's area - it sounds as though you might have a doe 2.2/2.3 project handy which you could open up in eQUEST, navigate to Building Shell -> Spreadsheet view for spaces, then sort the spreadsheet view by Polygon Assignment. Area for each polygon used for SPACE shapes appears 2 columns to the right. If you are additionally using polygons in lieu of simpler methods to specify building shades, PV Arrays, or specially shaped interior/exterior/underground surfaces (hard to do these by accident if you are used to leveraging the wizards), you'd need to seek those out separately, but in a similar fashion using the spreadsheet views. I hope this helps - best regards! ~Nick |
2016-10-02 11:09:48 -0500 | commented answer | LEED Appendix G - System 7 or System 8? (continued due to character limit) ... so in summary and with my own experience in hindsight, I'd advise reaching out to GBCI and making the case for System type #8 if it will be beneficial to your project. System type #7 is likely the "safe" route for reasons discussed in that it's less likely to be called into question, and for that reason might suit your priorities better. Ultimately it's your call to decide whether this is a fight worth fighting ;-). Best of luck! |
2016-10-02 11:06:36 -0500 | commented answer | LEED Appendix G - System 7 or System 8? I had a similar situation to Annie's (though I would not say "recent"): Gas preheat for OA at the central units, but with a substantial majority of airstream heating accomplished at electric reheat coils in the terminal boxes. For the preliminary review I went with the "Electric and other" System type 8. The first round of comments advised my baseline choice should be #7, but citing the "predominant conditions" line following TG3.1.1A & proving the majority of heating was actually electric, I was able to stick with system type #8. Just another anecdote reinforcing Matthew's point. |
2016-09-21 04:30:22 -0500 | answered a question | Can I adjust fan CFM on a schedule in eQuest? Found this post while perusing eQUEST/doe2 related queries some time later... surely too late to help with this project directly but I can answer for the record if anyone else has a similar query: The 'easy' response to achieve the intended effect for the purposes of calibration would be to (A) not combine the two existing DOAS systems (so split them up, permitting the assignment of unique FAN-SCHEDULEs), then (B) creating a "broken" FAN-SCHEDULE forcing non-operation for the requisite 6 months out of the year (using days with all zeroes for the hourly ON/OFF/FLAG input). An ECM to resolve that issue, thus providing the amount of OA intended by the design, could then simply swap in the "normal" fan schedule that's assigned to the other DOAS for each run. Hope that helps someone moving forward! ~Nick |
2016-08-31 21:30:28 -0500 | received badge | ● Enthusiast |
2016-08-29 02:35:12 -0500 | answered a question | Envelope & Lighting without Mechanical I found this exchange which seems to provide some related advice specific to envelope+lighting compliance with CBECC: https://unmethours.com/question/998/c... I can not claim any practicing expertise with CBECC or recent direct experience with T24, but it does look like auto-sized baseline systems of the same type should be expected. Whether those auto-sized baseline systems applicable to both cases should result in a net penalty I suppose should then depend upon what exactly you're inputting for lighting and envelope, relative to the baseline case. If the results remain quite unintuitive, perhaps you may find some luck submitting a support ticket here? http://bees.archenergy.com/issue.html |
2016-08-26 09:05:58 -0500 | commented question | Envelope & Lighting without Mechanical In the real world, changes to envelope and lighting systems can be substantially interactive with HVAC enduse energies. You might productively ask yourself: "If I were to remove any differences in fan/heating/cooling, then how am I trying to quantify envelope performance?" It would be further helpful if you could clarify the code/standard for which you are trying to demonstrate compliance. I suspect for showing envelope and/or lighting prescriptive / "calculated" compliance, you might find the whole exercise much simpler with a purpose-built tool like COMcheck. |
2016-07-13 07:11:19 -0500 | answered a question | eQuest will not open file I am not seeing anything posted as an attachment either. It would probably be helpful to include a copy of a previously working & recent version of the same project, if you have something like that handy to share as well. That would help isolate what might have gone awry. In the meantime you might try moving a copy of the .INP file to a separate location (independent from the .PD2) and try starting a "new" project by opening the .INP directly from eQuest (this will generate a new PD2, but you'd lose any wizard-level inputs and weather file assignment). If ultimately you cannot get attachments working here, you could try cross-posting the issue & files to the [equest-users] mailing list. |
2016-03-18 22:04:52 -0500 | answered a question | Will eQuest continue to be supported? There are a number of clues floating about that leave me optimistic we'll continue to see incremental additions to both the doe-2 engine and the eQuest interface in the future. Specific to VRF, note that DOE-2.1E functions have already been developed to directly model hourly behavior for a variety of VRF system setups [1] - I imagine it's a matter of time before such efforts get worked into something we can access directly via eQuest. I am not in a position to speculate or play up what may or may coming in the pipeline, but we have seen bits and pieces features under development surface over the past few years. Advances are also still being made by others for simulation around the doe2 engine, outside of eQuest. At the last ASHRAE energy simulation conference, a platform-agnostic theme that kept resurfacing was how to go about tackling multi-variable "optimization" problems (and notably the "runtime" conundrum involved). During the Lowdown Showdown presentations, team eQuest (disclaimer: I may have played a part in this) presented a unique doe-2 centric approach which, thanks largely to the raw speed of doe2 command line simulations (a benefit realized from decades of engine development, from an era when processing efficiencies were a necessity), was able to "brute force" a Monte Carlo simulation without the crutch/pitfalls of "seeded" genetic algorithms to inform simulations along the way. 24 design parameters were randomized and overnight produced a cloud of data from which we could identify a "first-cost optimized" minimal EUI result. In doing, so we did not just present the lowest EUI possible before adding renewables, but rather the best bang-for-buck combination of design parameters to suit an added "real world budget" constraint. At present, I still consider the eQuest/doe2 platform my go-to choice for most simulation tasks. I recognize it isn't the best tool for every task, but that's why I carry more than one tool in my belt! I'm confident we're going to see all of the tools in the playing field (old, new, and still unborn) make advances in years to come. It's an exciting time to be playing a part in the field of building energy simulation! [1] EnergySoft - "APPLICATION FOR ADOPTION OF VARIABLE REFRIGERANT FLOW SYSTEMS UNDER THE TITLE 24-2008 NONRESIDENTIAL ACM PROCEDURES" |