RFO Benchmark version 2

Wow, what a crazy couple of months, and the blog has taken a back seat because of it. But, finally something new to mention. The RFO Benchmark has been updated, to version 2 and for the 2016 products.
This new benchmark is a big improvement over years past in a number of ways. The biggest is that everything is now written in PowerShell, which is a much more capable and secure environment than the VBScript based approach of previous benchmarks. Also, the benchmark “definitions” are now stored in XML, which makes it very easy to mix and match what tests make up a specific benchmark ‘set’. As such, there are now three sets provided OOTB.

• Simplified: This test does a single run, without rendering or non HA graphics. Best for quick results.
• Standard: This test is the same as the v1 tests from previous years and averages three runs by default. Best for comparing to other results on RFO.
• Expanded: This test adds new sections and expanded sections to provide a more thourough benchmark, and runs 5 times, throwing out high and low outliers and averages the rest. Best for doing extensive in-house testing used to make purchasing decisions.

The modular nature of the new test also makes it easier for you to build your own series of benchmark journals and use the RFO Benchmark engine to manage running and reporting. And if you are playing with journals for your own use, you may want to dig into the benchmark journals as a crash course in journal minutia. There are some changes made this year with help from The Factory that address one “issue” and one “opportunity”.
The “issue” was that historically the benchmark journals have used two Directives to make them a little more fault tolerant, but the way any faults get handled could also invalidate the results. The two Directives in question are
Jrn.Directive “DebugMode”, “PerformAutomaticActionInErrorDialog”, 1
and
Jrn.Directive “DebugMode”, “PermissiveJournal”, 1
and both have been removed from all the benchmark journals, and the journals revised to eliminate the kinds of issues that might have triggered the need for these directives in the first place.
The “opportunity” came from the insight from The Factory that you can have conditional execution in a journal, and you can split a journal and run an optional journal between them. The first condition comes up in the Model_creation journal in the creating the exterior curtain wall section. Revit Structure requires the creation of “Structural Plans” while the other verticals use “Floor Plans”. Previously this meant two different journal files, with 90% the same content, but with a conditional a single journal file supports all verticals, and only the lines that need to be different are run conditionally. And, if you are a nerd and curious about such things, the trick used to drive the conditional is an Environment Variable. The Benchmark script knows which vertical is being run, and writes that information to a User Environment Variable called RFOVertical, and the journal reads this Environment Variable and branches processing appropriately. Pretty slick!
As for splitting and inserting journals, you can see this in action in the Expanded test. In previous years there was a single Model_creation journal, which created the new file from the benchmark template and proceeded to build the benchmark model. For v2 that journal was split into a New_file journal, which then saves the empty file, and a revised Model_creation journal that opens the created file and picks up with the benchmark from there. At least that’s what happens with the Simplified and Standard sets. But with the Expanded set a third journal is run between them, which links in a copy of the completed model, arrays it, sets the links to halftone, and saves. Then Model_creation carries on, but with a much “heavier” model. The key to all of this is finding the conditions the journal is working with at the point of the split, and providing the same conditions at the beginning of the next journal. The key information we need is the last GlobalToProj and ProjToPage directives. You just need to find the last state of each, as seen here in New_file…
Jrn.Directive “GlobalToProj” , “[Project2]”, “Floor Plan: Level 1” , 0.01041666666667 , 1.00000000000000, 0.00000000000000, 0.00000000000000 , 0.00000000000000, 1.00000000000000, 0.00000000000000 , 0.00000000000000, 0.00000000000000, 1.00000000000000 , 0.00000000000000, 0.00000000000000, 0.00000000000000
Jrn.Directive “ProjToPage” , “[Project2]”, “Floor Plan: Level 1” , 337.44024425673138 , 337.44024425673138, 0.00000000000000, 0.00000000000000 , 0.00000000000000, 337.44024425673138, 0.00000000000000 , 0.00000000000000, 0.00000000000000, 337.44024425673138 , 738.77887425126755, -304.24505389030594, 0.00000000000000
Jrn.RButtonDown 2 , 270 , 260
Jrn.RButtonUp 0 , 270 , 260
Jrn.Command “ContextMenu” , “Redraw everything as large as fits into window , 32782 , ID_ZOOM_FIT”
Jrn.Directive “ProjToPage” , “[Project2]”, “Floor Plan: Level 1” , 355.92465753437278 , 355.92465753437278, 0.00000000000000, 0.00000000000000 , 0.00000000000000, 355.92465753437278, 0.00000000000000 , 0.00000000000000, 0.00000000000000, 355.92465753437278 , 468.21839945739771, -305.59671756686146, 0.00000000000000

And set the same state at the beginning of the files that need to follow, so both Array_link and Model_creation define the same conditions to start off…
Jrn.Directive “GlobalToProj” , “[Project2.rvt]”, “Floor Plan: Level 1” , 0.01041666666667 , 1.00000000000000, 0.00000000000000, 0.00000000000000 , 0.00000000000000, 1.00000000000000, 0.00000000000000 , 0.00000000000000, 0.00000000000000, 1.00000000000000 , 0.00000000000000, 0.00000000000000, 0.00000000000000
Jrn.Directive “ProjToPage” , “[Project2.rvt]”, “Floor Plan: Level 1” , 355.92465753437278 , 355.92465753437278, 0.00000000000000, 0.00000000000000 , 0.00000000000000, 355.92465753437278, 0.00000000000000 , 0.00000000000000, 0.00000000000000, 355.92465753437278 , 468.21839945739771, -305.59671756686146, 0.00000000000000

In this way you can make some pretty amazingly modular journals, and I am still wrapping my head around the possibilities. One that I am collaborating with Aaron Maller of Parallax on is extending the Version Upgrade tool chain. We have a working example now that upgrades not just family and project files, but family and project templates as well, and the next step is digging in to managing standards in those files. Imagine being able to plug in what standards you want updated in the XML, which then runs a series of optional journals to address things like Sub Categories or fonts in text and Dimension Styles? The possibilities boggle the mind! 😉

Anyway, that’s enough nerdiness for now. I hope you enjoy the new benchmark, and I hope some of you dig in to the PowerShell and Journal code to see what makes it all work under the hood. Some pretty fun learning over the last year there.

As always, you can get the Benchmark here at RevitForum.org. There are v2 downloads going back to Revit 2014.
And, once a again a HUGE thanks to The Factory for the often needed and always appreciated, support, insight and overall awesomeness.