Piggybacking a little off of Bill's post from earlier this week on keyword
expressions, I wanted to get people thinking about the possibilities/pros
and cons if one is able to add custom keywords and expressions (i.e. in
addition to the one's packaged with the standard eQuest release). In my
opinion, this is a huge advantage to eQuest/DOE2 in that the interface can
be tweaked for individual preferences without changing the underlying
calculations. As an example (and for anyone brave enough to try it out,
I've attached a modified BDLKEY.BIN and BDLDFT.DAT file which go in your
DOE23 folder as well as a modified BDLDialogs file which goes in the
ScreensDOE23 folder), this modified BDLKEY file includes an additional
numeric keyword for windows called WWR(window to wall ratio). Now assuming
that you have no more than one window defined per exterior wall, the BDLDFT
file can be edited to include the following expressions:
SET-DEFAULT FOR WINDOW
HEIGHT {SQRT(#L("WWR"))*#P("HEIGHT")}
WIDTH {SQRT(#L("WWR"))*#P("WIDTH")}
X {0.5*(#P("WIDTH") -#L("WIDTH" ))}
Y {0.5*(#P("HEIGHT") -#L("HEIGHT" ))}
..
Now the size and position of individual windows are controlled by a single
parameter, which is bound to each particular window (assuming you allow the
4 parameters above to default).
[image: image.png]
The major downside is that this is no longer complies with the standard
release, and one could end up with a nearly infinite number of eQuest
flavors depending on modifications to the keyword file. Sharing files and
QCing years after the fact could become a nightmare. A possible solution
to this problem would be the ability to add keywords on the fly, the way
that global parameters are, which are associated with individual .inp files
and not with the program itself.
I have dabbled before, but have never seen this process layed out so clearly, thanks Aaron!***
To be fair, I think this degree of local interface customization is going to be a considerable stretch/challenge for the average skilled end-user of eQuest/doe2? but the option for advanced end-users to tweak/modify their platform can be considered a substantial advantage for those valuing control and time-efficiency in their analysis workflows.
When I personally buy a vehicle, I do consider relative mechanical ease of maintenance / repairs as a determining factor. Even if I reserve the option to take it into the shop later, knowing I have that option is important to me when deciding where to invest my resources. Come to think of it? that?s probably going to be a hurdle for me shifting to an electric car someday =/?
In any case ? great thread so far! If any academics or developers are tuning in? This might be difficult to poll, but I?d personally be interested to see a tiered ranking illustrating the degree to which different platforms make it easy/difficult/impossible to customize the input/output interfaces provided, for those who are or would aspire to become ?power users? pushing the envelope of what the platform can accomplish.
To Aaron?s closing/leading thoughts around developing the ability to add keywords ?on the fly? to individual projects ? That?s a pretty exciting notion!
As an alternative implementation, the OpenStudio Measures feature-set may be a model to consider. This could allow for an ?a la carte? opportunity to add/remove community-vetted and documented custom keywords to your local eQuest installation on a project-by-project basis.
A similar case would be the ?Plugins? featureset of Notepad++.
[cid:image002.png at 01D5E584.0796E130]
A natural extension for such an interface would be to allow the community library to include community vetted and documented custom equipment curves, default expressions (which may require adding #PA?s)?
To get ahead of a certain potential headache, the local ?state? of which interface customizations are utilized should be saved with every project? either in the INP/PD2 or in a new file that?s generated/saved when this feature is in use (like the PRD for parametrics). With this recording in place, anytime a project is opened/initialized, a check can be made to ensure the local interface has the same set of features toggled ON, else to throw a caution/warning before saving/simulating. I?m hopeful a future build/version of eQuest will consider project-based tracking and checking of doe2.2 vs doe2.3 selection, in this fashion.
~Nick
[cid:image006.jpg at 01D5E585.32D8AE90]
Nick Caton, P.E., BEMP
Senior Energy Engineer
Energy and Sustainability Services
Energy Performance Contracting
D
M
E
913 . 564 . 6361
785 . 410 . 3317
nicholas.caton at se.com
15200 Santa Fe Trail Drive
Suite 204
Lenexa, KS 66219
[cid:image003.png at 01D5E350.8AAE3860]