[Equest-users] Custom Keywords and BDLKEY file

Mon Feb 17 09:27:17 PST 2020

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<mailto:nicholas.caton at se.com>
15200 Santa Fe Trail Drive
Suite 204
Lenexa, KS 66219

[cid:image003.png at 01D5E350.8AAE3860]

From: Equest-users <equest-users-bounces at lists.onebuilding.org> On Behalf Of Aaron Powers via Equest-users
Sent: Friday, February 14, 2020 2:51 PM
To: equest-users at lists.onebuilding.org
Subject: [Equest-users] Custom Keywords and BDLKEY file

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.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.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20200217/fa034001/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 8477 bytes
Desc: image003.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20200217/fa034001/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 36227 bytes
Desc: image002.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20200217/fa034001/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 1794 bytes
Desc: image006.jpg
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20200217/fa034001/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 72173 bytes
Desc: image007.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20200217/fa034001/attachment-0002.png>