aaron's profile - activity

Does the program actually crash, or does the simulation get aborted? If just aborted, you can check the .sim file for a

Yes, that is correct on both points. An example of not being careful would be setting the Fraction of Tower Capacity in

The calculation sequence looks like this: Simulate tower at full speed IF (Setpoint exceeded) THEN Simulate tower in

The $CAPACITY$ variable above is the rated capacity input parameter. The operating capacity is an output variable label

This has to do with the specifics of the formula used by DOE2/eQUEST to calculate power. The "Corrected electric-input-

The definition of the thermodynamic wetbulb is the temperature of adiabatic saturation. i.e. it is the outlet temperatu

There's an option to create a formatted hourly report file. See this for more details. It isn't csv, but it can just as easily be imported into Excel.

The simplest way to run several batch runs is to just sequentially hard-code the DOE2 batch command for every run you want. For example, if you just had 3 files located in a folder named c:\inp_files, you could use a .bat file like the following.

c:\\doe21e\doe21e.bat c:\\inp_files\\building1 TN_Memphis_International
c:\\doe21e\doe21e.bat c:\\inp_files\\building2 TN_Memphis_International
c:\\doe21e\doe21e.bat c:\\inp_files\\building3 TN_Memphis_International

The output files will be named the same as the input files but with a .sim extension by default. To do specifically what you've asked, which is to run all inp files in a particular folder, you could use the following.

:: Script to runs DOE2.1E simulations for all .inp files
:: located in the inp_dir folder
:: Do not include spaces in inp file names
:: weather file must be in c:\\doe21e\weather\packed folder

set inp_dir=c:\\inp_files
set doe_cmd=c:\\doe21e\\doe21e.bat exent
set weather=TN_Memphis_International

:: Run simulations for each inp file in folder
for /r  %inp_dir%  %%f in ( *.inp) do (
  call %doe_cmd% %%~pf%%~nf %weather%
)

Just change inp_dir to the folder that you want and weather to the weather file that you want. This may look a little ugly because it uses some Windows command jargon, but you can accomplish a similar result that will look cleaner with other languages like Python or Java if you are familiar with them.

Below is another option but probably not as readable as Molly's solution.

The reason you can't access the name directly is because DOE2 doesn't treat U-NAMEs as keywords. This differs from other engines such as E+ which has a name field for many objects. In fact, names are always optional in DOE2. The engine uses a "reference table" to differentiate between objects. Each type of object is assigned a specific predefined spot in the reference table, and each instance of that type is stored sequentially starting at that spot. For example, if you look at the Command Table in the BDLKEY.OUT file, you'll see that the reference table start for all SPACE objects is 1723516. That means that if you have three spaces ("space 1", "space 2", and "space 3"), they will have a reference table index of 1723516,1723517, and 1723518. You can use this to create a workaround to your problem. For this to work, you need to know how many spaces are in each floor ahead of time. For example, assume you have 3 floors with 5 spaces on the 1st floor, 3 spaces on the 2nd floor, and 2 spaces on the top floor.

LIGHTING-W/AREA = (
{
  if (#RI() < 1723516 + 5) then
    1.5
  else if (#RI() < 1723516 + 8) then
    1.25
  else
    1.0
  endif
  endif
} )

You can make this a little more readable by making global parameters which hold the index to the first SPACE of each FLR. e.g.

PARAMETER
"Floor 1" = 1723521
"Floor 2" = 1723524
..

Then the expression would look like:

LIGHTING-W/AREA = (
{
  if (#RI() < #PA("Floor 1")) then
    1.5
  else if (#RI() < #PA("Floor 2")) then
    1.25
  else
    1.0
  endif
  endif
} )

Having said all that, according to the documentation, you should be able to access an object by name using

#SI("Floor 1","FLOOR")

But I've only seen the 3 parameter option work for the #SI function. I'm not sure if the 1 and 2 parameter options ever worked.

If you have any interest in working with DOE2 directly, you can do this relatively easy using the following .bat file as a template. In this example, the file "BatchTest.inp" is run for two locations. The results are stored in "BatchTest_1.sim" and "BatchTest_2.sim". You can add as many locations as you'd like to the end of the file.

:: Script to run DOE2 simulations over multiple locations
:: Do not include .inp extension in file name.
:: By default, the doe22.bat script does not allow spaces in input file.
set inp_file=BatchTest
set doe_cmd=c:\\doe22\\doe22.bat exe48r

:: First run is Memphis, TN.  Do not include the .bin extension in 
:: weather file name
set weather=TN_Memphis_International
call %doe_cmd% %inp_file% %weather%
copy %inp_file%.sim %inp_file%_1.sim

:: Second run is Jackson, MS.  This procedure can be followed for any number
:: of locations.
set weather=MS_Jackson_International
call %doe_cmd% %inp_file% %weather%
copy %inp_file%.sim %inp_file%_2.sim

The variable speed tower curves model a sort of scaleable shape of the thermal performance and not the effectiveness of the tower. Generally, you only want your own curve if you're modeling a piece of technology that's not a traditional cross or counterflow cooling tower. To alter the heat transfer capabilities of the tower, you need to change the design approach temperature. For example, a tower with a design approach of 5F will provide more heat transfer than a tower with a design approach of 7F.

If it is the same as DOE2.2, you should see a file that looks like CECDDT<>.bin

As far as parsing goes, you may have to look into the source code to see if they do any data compression or encryption before writing to the .bin file (perhaps similar to the strategy used int he weather .bin files). I could be wrong, but the binary output option was probably never meant to be used by end users.

You may want to try the HOURLY-REPORT-SAVE = FORMATTED option. Again, if this were DOE2.2, you'll see a file like CEC2<>.DAT which is a plain text fixed-format file that can easily be opened in excel. It should have the same data as the binary file, but it will be larger and readable.

How far from zero? The items you listed shouldn't sum exactly to zero because the HVAC controller almost never keeps the zone air exactly at setpoint. The net amount of energy that doesn't balance will cause the space temperature to slightly drift up or down in the next time-step.

Have you looked at the DOE2 model? When hourly solar data isn't available, DOE2 estimates the direct normal and diffuse radiation based on geometric data, a clearness number, and a cloud cover factor. It roughly corresponds to the algorithms SUN and CCF described in ASHRAE's Procedure for Determining Heating and Cooling Loads (1975). The algorithm is described on page III.21 of the DOE2.1A Engineer's manual. Not sure if it qualifies as simple. Parts of the model are also described in Chapter 14 of the 2013 ASHRAE Fundamentals handbook. You'll probably be able to find an appropriate model in Duffie and Beckman's Solar Engineering of Thermal Processes as well.

I think this will help. Basically, you control the rated wattage by surface area and cell efficiency. Most panel power ratings are given at STC conditions with 1000 $W/m^{2}$ incident radiation . So as an example, if you specify a 100 $m^{2}$ system with 15% cell efficiency, that corresponds roughly to a 15 kW system.

This is only a partial answer, but as far a speed goes, any algorithm that doesn't involve a $ \Delta T$ term will allow E+ to run faster on average. The models that include a $ \Delta T $ term are accounting for buoyancy driven natural convection. For a given surface, the convection contribution to the energy balance equation is $ Q_c = h_c \Delta T $. This is a linear expression only when $ h_c $ doesn't depend on temperature, and linear equations can be solved with one iteration. Also equations that are near-linear can be solved faster than highly nonlinear ones. So a model with $ h_c \sim \sqrt { \Delta T } $ will generally run faster than one with $ h_c \sim \ { \Delta T } ^2 $. This also relates to the robustness because a more linear model is more likely to help the heat balance convergence.

You can also try the poor man's hack which is to use the raw data from NOAA here . Unfortunately, most of these don't include solar data (it's sad how little measured solar data we have given how important it can be), so you'll have to use a workaround to get a complete set. The process looks like this:

• Start with a complete TMY weather data set for your location.
• Download actual weather data from link above (and probably import it to something like Excel).
• Fill in any gaps that may be in the data and make any required unit conversions.
• Merge the drybulb/wetbulb/pressure/wind direction/wind speed from the NOAA data with the TMY data. This new data set will essentially contain AMY ambient air data and TMY solar data. Elements can be a very useful tool for this task, or you can use Excel/notepad and the old FMTWTH program if you're using DOE2.

This method is going to be most accurate for buildings which rely on a lot of outside air (e.g. labs) and least accurate for buildings with a lot of glazing. If you feel that solar could have a large impact on the building, or if you want a high level of accuracy, I would recommend purchasing a set from someone like White Box as the others have suggested (also if it's worth the reduced hassle of having to create the file yourself). Good AMY files will use state of the art algorithms for providing the best estimate of solar radiation.

There's no way to do this directly that I'm aware of. You can, however, use the results from a CFD program to inform your inputs to DOE2. For example, you can run steady-state simulations in your CFD software over a variety of ambient temperatures and windspeeds. You could then use the data from these simulations to calculate the equivalent Sherman-Grimsrud coefficients for use in a DOE2 model (assuming you can get a good fit). If you really do need the CFD coupled to the energy simulation, then you might want to look at other engines besides DOE2. You might also want to check out the airflow network model in EnergyPlus which is like a good compromise between empirical methods and full CFD.

Sorry, I was not thinking about EnergyPlus at all when talking about bug fixes (I only mentioned to contrast funding sources). I was referring more to consumer based software that people may be more familiar with. e.g. think about how often you get app updates on your phone and the details say "minor bug fixes". I wanted to make the point that you shouldn't necessarily set your expectations on how often you get updates to an energy simulation engine to the rate you get them from companies like Google or Microsoft for consumer based software.

With eQuest you really have to manage your expectations of what support means. The biggest thing is that it is free and not directly funded by a government entity on a continuous basis (by this I mean like E+). As a tradeoff, the program has always been "unsupported" in the sense that you don't get direct support/help from the developers. However, entities like the eQuest Users Group at onebuilding.org quickly bridged this gap by allowing other practitioners to volunteer their time to help others with problems. Many people thrive in this structure and prefer it to other business models.

Also, eQuest releases don't work like many other software packages with regular updates every 6 months. You may have 2-4 years without an update, but this doesn't mean that the program has been abandoned. A big reason for the this is that the code base for DOE2 goes back 30+ years, so most of the accidental bugs have been fixed. Therefore, updates to the program are almost entirely additions rather than bug fixes. Other newer programs require a 6 month rolling release just to keep up with newly discovered bugs.

As far as the addition of specific pieces of equipment to the program goes, I don't think you can ever guarantee that this will happen (although past evidence shows that it does eventually happen). But I don't think this should deter you from using the program. Long time users understand the framework of DOE2 and the environment in which it was built and therefore know when it is the best tool for a specific task. If you still feel uneasy about the future of eQuest, just remember that this question gets asked a lot, and yet the software goes on...

Ok, I don't know of a built-in feature like this, but someone else on the forum might still know. You've probably already seen this too, but check out the int called LIST which controls some built-in reporting. It's hard coded to 0, so you'd have to recompile to change this. It might be a leftover feature from AIRNET that has been disabled. If you continue to have issues with convergence (and you have some time and patience), you may want to look into modifying the solver to the Levenberg-Marquardt algorithm. I've had success at modeling hydronic flow networks with this method.

Since you're already modifying the source code, you could just write to a file while the program is checking for convergence at the beginning of each iteration. See line 719 in AirflowNetworkSolver.cc below as an example.

I would caution that the Merkel model has a few known flaws, of which the largest is that it assumes no water loss through the tower. This causes the model to overpredict the heat transfer rate for a given NTU. The magnitude of this error has been discussed in a number of places (e.g. Braun Methodologies for the Design and Control of Central Cooling Plants, Benton/Feltzin A More Nearly Exact Representation of Cooling Tower Theory...) The Empirical models don't use any of Merke'ls simplifications.

Here's a plot comparing the models over a wide range of conditions. The range that I ran them over was:

• Inlet drybulb from 40 to 100 deg-F
• Inlet humidity ratio from 0.004 to 0.023
• Inlet water temperature from 65 to 100 deg-F
• Airflow ratio from 0.4 to 1.0
• Waterflow ratio from 0.4 to 1.0

The CoolTools model generally tended to underpredict the heat rejection rate compared to the YorkCalc model. I'm not sure of the reason for this. Here's a comparison of the two models vs a finite difference solution. Again, the CoolTools model tended to underpredict.

Have you looked at the ElectricLoadCenter:Distribution output for Total Electric Energy Produced? The report for the Photovoltaic may be the DC potential of the panels.

There are a couple things you can try for a quick fix.

1. Set the Initialization Type = LinearInitializationMethod. This will calculate the first iteration of flows and pressures assuming a linear relationship. All subsequent iterations will be nonlinear. A better initial guess will improve you're chances of convergence.
2. Adjust the Convergence Acceleration Limit field. The solver uses a "Steffenson like" algorithm to reduce oscillations when steps in pressure are too large. One of the downfalls of Newtonian solvers is that they can fall outside of their radius of convergence when step sizes are large, so the E+ solver uses a kind of damper on the Newton step in an attempt to prevent this. However, it only applies the damper when the ratio of pressure corrections for the current iteration to the previous iteration is less than a critical value. This critical value is the Convergence Acceleration Limit. This field also controls the amount of damping in the Newton direction. A value between -1 and 0 will reduce the step size , and a value between 0 and 1 will increase the step size. Since you are trying to improve convergence, a value of Convergence Acceleration Limit = 0 will be the most conservative choice. You'll also see an increase in computation time. To my knowledge, no one has actually proven that this method improves the chances for convergence, so this may not work for you, but it's worth a shot.

Yes, all of the mechanical energy of the pump does end up as heat in the fluid. There's a really good article in HPAC Engineering by Gerald Williams which explains pump/fan heat called "Fan Heat and Pump Heat: Sources and Significance." You might be able to find a pdf copy floating around on the internet.

You can think of hot water pumps as in-line electrical pre/post heaters for the boilers. By reducing the speed of the pumps, you're reducing the "supplemental heat" from the pumps, and this must be overcome by the boilers. There are still good reasons for implementing variable hot water flow systems:

• Electricity can be on the order of 3 times more expensive than natural gas (per Btu). So even though you're total energy consumption has risen, you're still going to save money. Natural gas is also usually perceived as greener than electricity due to the inefficiencies in the electric grid. This is the same reason people tend to opt for natural gas boilers over electric boilers even though electric boilers are more efficient on a Btu basis. Using the previous analogy, you can think of variable flow hot water systems as removing an in-line supplemental electric heater.
• The delta-T in a variable flow system will tend to be greater than those in a constant volume. If you have condensing boilers, this allows for lower return temperatures which increases the efficiency of the boiler. Larger delta-Ts also will result in lower environmental/radiant losses in the piping because the average loop temperature will be lower.

@FrontierAssoc104 You may want to post this as a separate question since it will get more visibility that way.

The Fan:ConstantVolume and Fan:VariableVolume objects both have a field for motor efficiency separate from the fan efficiency (circled in red below). The difference between the two efficiencies is that the motor losses can be specified as out of the airstream and therefore not add any heat to the supply flow. So any losses that you don't want to contribute to a temperature rise (e.g. drive losses outside the AHU) will have to be included in the motor efficiency.

Are you using a 32 bit Debian?

I believe that you can capture some of these benefits, but maybe not as directly as you might be hoping for. The makeup water treatment could (**see note below) have the effect of increasing the mass diffusion and convection coefficients by increasing the interstitial area between pure H20 and air molecules. If you select the CoolingTower:VariableSpeed:Merkel tower model, then the transfer coefficients are controlled by the input of the tower UA at design conditions. One of the assumptions in Merkel's Theory is that the Lewis Number is 1, so by specifying the UA you are effectively specifying both heat and mass transfer coefficients. The tower with water treatment should have a higher UA than the current tower, but the challenge is to know by how much. I believe it will be difficult to find reliable data on the effects of mineral concentrations on transfer coefficients in cooling towers. But if you do find a delta that you're comfortable with, then you can calculate the savings by simulating the tower with different design UA values. As for the water savings, I would just caution that the EnergyPlus algorithms are fairly crude in this department. The SaturatedExit method will always over-predict water consumption, and the LossFactor method has a low precision. If you have access to Trnsys, then the Type 51 cooling tower would be a useful tool for this task. In this model, the mass flow rate through the tower is not assumed to be constant, and the water loss is calculated explicitly.

** Removing minerals might not always be a good thing. You could be removing some which have a high conductance with air, and you could be loosing more sensible potential than what you gain with the increased latent potential.

Does anyone know where I can find the coefficients for the CoolTools counterflow cooling tower model? The original paper by Benton et al. mentions that two different curves were generated for both crossflow and counterflow configurations, but it appears that only the crossflow coefficients made their way into EnergyPlus.

The equivalent file that you're looking for is the .inp file generated by eQUEST. However, eQUEST uses DOE2.2 as the simulation engine while EnergyPro uses DOE2.1E, and although there are similarities, the two input file types are not compatible. You will either have to modify your spreadsheet to analyze DOE2.2 input files or attempt to convert the DOE2.2 file from eQUEST to a DOE2.1E file (.inp to .DOE). You can find information on the difference between the two file formats and how to manually convert from DOE2.2 format to DOE2.1E format on the doe2 website.