DavidReddy's profile - activity

Hi Shruti, I recommend submitting your model to CBECC support: cbecc@energy.ca.gov

Neil, Here is the path to the most current version associated with the 2022 release. https://svn.code.sf.net/p/cbecc-c

@Ranjani, this option, if checked, does not result in a valid compliance run. It is available for research/early phase

@Ranjani, this option, if checked, does not result in a valid compliance run. It is available for research/early phase

@Ranjani, this option, if checked, does not result in a valid compliance run. It is available for research/early phase

Funny coincidence, I found this very same issue in the CBECC-Com curves two weeks ago. I've created a ticket for the dev

@NathanMiller, did you submit your model to the CBECC-Com help desk? Which program version are you using? Does the DOAS

@dradair, thanks for posting this detailed description. In doing some independent internal follow-up testing of v1.0, I'

Assuming you are comparing to the 90.1-2016 prototype, and the CBECC-Com 040012-OffLrg-CECStd.cibd16 model, the biggest

@Ranjani, Can you be more specific on how you got your results, including: - Which version of CBECC-Com you used (2016 o

@Rajani, In the CBECC-Com interface, on the Envelope tab, if you right-click on a BuildingStory object in your model, yo

When you run CBECC, and assuming you are retaining output files (see settings under Tools -> Program and Analysis Opt

Loop-to-Loop Heat Pump double counting of heat electricity Using the latest version of eQUEST v3.65, build 7174, we've g

Loop-to-Loop Heat Pump double counting of heat electricity Using the latest version of eQUEST v3.65, build 7174, we've g

Note that the control of fan powered boxes according to PNNL 90.1 PRMRM guidance: 2010: https://www.pnnl.gov/main/public

I agree with @pflaumingo, the ReverseTranslator covers the conversion of a CBECC-Com xml file to OS, and this code is a

I agree with @flaumingo, the ReverseTranslator covers the conversion of a CBECC-Com xml file to OS, and this code is a g

They are not included in the public releases, but can be found in the SF repo: https://sourceforge.net/p/cbecc-com/code/

The SDD 'Input' view contains the objects/properties that the program will accept, either from third-party tools, or ent

The SDD 'Input' view contains the objects/properties that the program will accept, either from third-party tools, or as

I agree with @flaumingo, the ReverseTranslator covers the conversion of CBECC-Com xml file to OS, and this is a good res

Extraneuous PIU system central heat coil output Hi all, I am modeling a PIU system w/ a water-cooled DX coil and series

Extraneuous PIU system central heat coil output Hi all, I am modeling a PIU system w/ a water-cooled DX coil and series

Once you import the IDF into OS, you need to assign each Space to an OS BuildingStory. Stories do not exist in the IDF d

I haven't tried it, but I believe this work flow should work. Though IDF -> OS does not include HVAC objects, the OS

@rraustad, regarding the connection of DOAS to the VRF inlet node; is using AirTerminal:SingleDuct:InletSideMixer not a viable option?

Have you sent the model to the CBECC help desk for support on this? Generally, I recommend not modeling surfaces as ceiling, but rather only model floors for spaces and connect to the space below. In translation form SDD to OS, OS will create the reversing surface. Though it has been some time, I have seen this issue before, including the the baseline not having the problem when it has the same surfaces. I found modeling all interior horizontal surfaces as InteriorFloor objects, as opposed to Ceiling objects, alleviated the problem with out of control zone temps.

Does the zone have a floor, and does that floor have some mass to it? If it doesn't try adding one to see if it alleviates the issue.

If you are using v3c, you can uncheck the 'Has Process Exhaust' box in the Space -> Vent & Exh tab input screen. This allows you to model the space as you would any other space, including just specifying general exhaust.. For good measure, make sure you remove any of the kitchen exhaust inputs before making this change. (remove inputs by first restoring the default is my general recommendation.

I also should add... CBECC-Com support through Unmet Hours is not currently funded since the CEC funds support through their own channel. http://bees.archenergy.com/issue.html Perfectly fine (and encouraged) to circulate CBECC-Com questions/issues/work-arounds on this forum, but best to also submit a ticket for issues like this through that system to make sure they get tracked and resolved.

Unfortunately, I don't develop the help documentation, so I am not sure if this is documented in the CBECC-Com help, but I agree that is should be caught by rules so I created a ticket for it in our system.

Sorry, missed that there was an XML file posted with the question when I first looked at this...

The SDD->OS translator failure is occurring because you have a pump defined in your SHW systems. CBECC-Com does not yet support modeling reciric SHW systems serving nonresidential spaces, so these systems should be modeled without a pump defined. The SDD->OS translator automatically creates the pump needed for simulation in EnergyPlus.

For a properly defined/working model, the only pump that should have a UID name is circulation pump on SHW loops. If you can't post the file here, I recommend submitting this as a CBECC-Com issue for further review.

Yes, the intent is, at least for v3 and later versions, older projects can be opened and run in the most current version.

Depending on the changes between releases, you may find some properties that were previously defined in your file are no longer recognized as valid inputs. Also, you may find that when you initiate compliance analysis, there may be some new or previously existing properties that must now be defined. Dialog and log file messages should alert you to either of these cases, but otherwise, it should work.

If you do run into errors that result in the project not loading, please submit an issue here: http://bees.archenergy.com/issue.html

... For example, say you want to study WWRs as individual measures by cardinal direction (story, or section of a building are also scenarios we look ). If the measure groups were created by direction (0.2 WWR Group = 0.2 North Msr, 0.2East Msr... 0.3 WWR Group = 0.3 North Msr, 0.3 East Msr... ) and a whole building WWR Design Alternative was desired, it seems logical to just combine the measures within the one group. It is not that big of a deal to use a different structure, just something for users to think about when developing their measure groups.

Thanks very much for all the responses Larry. The rationale for 1) seems obvious from the perspective of applying measures to the whole building. However, it is not uncommon to break the building into smaller components, and have the same or similar measure for each component, allowing you to see the impact more iteratively.

Thanks Dan, but I incorrectly worded my question: Do you have an example of a reporting measure that writes csv format energy summary results from simulations? Ideally, a CSV file of key annual energy results (kWh, kW, therm, etc); one set of model results per line/row. This is the format output by eQUEST in its 'Parms.csv' file. It would be useful to create a report that is in the same or similar format so we can more quickly adapt internal results viewing/reporting spreadsheets to OS/E+ output. Just wanted to ask in case something has already been developed.

I'm also interested in seeing recommendations on this. In Washington State, though there is an economizer exception for VRF systems, it requires providing heat recovery on the DOAS. Given these trade-offs, some designers are inclined to use the ducted VRF terminals w/ economizers. In this case, the cost trade-off is between a) providing an OA duct sized to 100% OA + economizer vs b) providing a smaller duct sized for vent only + ERV unit. Not saying these configurations are more efficient that non-ducted terminals + DOAS ± ERV, but hence, wanting to model and compare them.

We've used revision control (TortoiseSVN) in our work flow, versioning energy model files and supporting documents for projects, for almost 3 years now, and can't even remember how we got by without it. It is very useful for tracking history, collaborating, and reducing the amount of information we need to backup. On more than one occasion, I have made some change to the model that causes a fatal error that cannot be debugged easily with logging. Diffing versions of the file is one more way to help debug the problem.

Our repositories are stored in local folders that are sync'd with the cloud and then across all our computers. We currently use Egnyte, but have also used DropBox; both have worked fine. There is a bit of lag time between commits/syncing between users on different computers, but nothing that has slowed us down.

Most of our experience is in the context of versioning eQUEST files, and the following are the files we archive in each revision: *.inp *.pd2 (though only for the initial wizard model. Once in detailed mode, we often skip versioning this) *.prd *.Parms.csv (This is once we get int

We try to commit any supplemental files (xlsx, etc) that help document the model along with the model commit. Also, we have found it valuable to tag the trunk when delivering a set of results or final report to the client.

I am using the PAT tool to evaluate some design alternatives, and finding some workflow questions/potential issues that I am hoping to get some help with:

1. What is the rationale for not being able to combine Measures from the same Measure Group into one Design Alternative?

2. On the Run Simulations screen, I can't select individual Design Alternatives and run them. Should I be able to do this?

3. Creating a new Measure/Measure Group, or reordering of Measures, causes the Design Alternatives I created to be deleted. Is this a bug, or what is the rationale for this?

Using OS v1.7.0

David/Dan. Do you have an example reporting measure that writes energy summary results for PAT simulations?

However, my related comment/question is: PAT projects have a pretty deep directory structure and a lot of files are created when the projects are run/saved. Does anyone have a good summary of what files are important to control, and which can be ignored for PAT, or are they all important?

We use TortoiseSVN with local repositories on our harddrive (sync'd between computers by cloud service Egnyte), and we can diff (using WinMerge) revisions of files without any issues.

Yes, you are correct, CBECC does not currently support modeling fixed OA fraction systems. If you feel that this capability is important, I recommend submitting an 'Other' issue and specify it as a feature request: http://bees.archenergy.com/issue.html This will allow us to formally track it as a possible feature for future versions.

No, there is currently no way to only operate the exhaust fan only when the economizer is active. The work-around you propose, i.e. modeling a fan on the relief air segment, is the best solution. The relief fan will operate at the minimum outdoor air flow when the economizer is not active. However, if the fan is variable speed, the amount of energy used at this low part-loads will be small.