[BLDG-SIM] User Friendly (was: Building Simulation in the U.S.)
Jason Glazer
jglazer at gard.com
Wed Jun 13 05:57:43 PDT 2001
Lets not forget that the team of design engineers and
architects working on the design of a building knows as
much as anyone could know about how the building is
supposed to work. Through drawing and specifications, they
have a created a model of how the components work and
interact that can be turned into a working building in
order to serve the needs of the occupants. The complex and
rich expression of how a building is supposed to be
simulated is already present just in the wrong language.
Allowing easy expression of this type of complexity in a
building simulation program therefore is "simply" a user
interface issue. It is solvable. My suggested general
rule to follow:
The closer to the design team's way of expressing the
design the better.
That said, the current state of the art in building energy
simulation programs are not very close to the way engineers
do express designs.
For example, a schematic design with all flows between
equipment and a sequence of operations for the sensors and
controls is what is often used in practice. Why isn't the
building energy simulation software input more like that?
In part, because in the past, the input requirements are
driven by the algorithmic approach of the software. This
needs to be reversed to achieve "friendly" software - the
algorithms need to be driven by the input requirements.
Thermal blocks (a.k.a zoning) are another big issue, the
level of abstraction needed to understand what a good
thermal block plan would be for a simulation program
requires an understanding of the simulation algorithm. Why
should a design engineer care? Assuming that all surfaces
are imported from a CAD program (a big assumption) and each
zone is associated with a type of occupancy, why can't the
simulation program find out the best way to break up the
building into thermal blocks. Someone could come up with
an algorithm to do this.
Another issue is libraries of materials and equipment. It
is in the best interest of the manufacturers of products to
supply enough information for building energy simulation
programs but they don't. What are the barriers here?
a) Different types of information needed by each software
program.
b) Possible incorrect interpretation of data by the user or
the software.
c) Not a large enough market to bother with supporting
those customers.
d) Not enough specifying engineers asking for the data.
The last point brings us back to why are simulation
programs not used more. One way to start solving these
programs is to look at all the standards used to specify
the different products and make sure the simulation
programs accept the standard performance metrics as direct
inputs. DOE-2 cannot accept AFUE or EER. Also product
specifications should be examined for common methods of
expressing performance and control of equipment and
components.
What is left of the problem? The unique domain of
knowledge about the building simulation program itself.
This is new knowledge that the engineer doesn't need
normally to fulfill his responsibilities and thus it needs
to be minimized. Can it be? I think so, the typical space
loads and schedules for operation for occupation are easy
lookup's in a library. Engineers do that all the time when
the specify building components. Select a weather file -
again easy. The problem is all of these other inputs:
ground reflectance,
fraction of heat to space,
weighting factor,
infiltration coefficient,
maximum glare,
inside visible reflectance,
convergence tolerances, etc..
Any of these types of inputs require a engineer to learn
new stuff. I think most can be avoided completely,
specified as part of a building component, or expressed
differently in terms the engineer can appreciate.
In summary, I assert that the almost all of the needed
details of the building energy simulation are known by the
design team of a building but they don't use building
energy simulation programs partially due to the information
being expressed differently. The complexity that remains
that is unique to building simulation can be minimized.
Jason
=========================================================
Jason Glazer, P.E. mailto:jglazer at gard.com 847 698 5686
GARD Analytics - http://www.gard.com/
1028 Busse Highway, Park Ridge, IL 60068
Building Energy Simulation and Analysis
List Administrator for 90.1, GPC18 and BLDG-SIM
======================================================
You received this e-mail because you are subscribed
to the BLDG-SIM at GARD.COM mailing list. To unsubscribe
from this mailing list send a blank message to
BLDG-SIM-UNSUBSCRIBE at GARD.COM
More information about the Bldg-sim
mailing list