Apologies if this is a no-brainer, but I personally don’t see myself ever writing my own recipe - what is the benefit?
I might be misunderstanding what constitutes a recipe. I thought it was an algorithm that tells the simulation engine exactly what to run under the hood (e.g. the DaylightFactor component in LBT is an example of a recipe). Everything else - the geometry, the EPW file, the analysis mesh density, the simulation parameters (e.g. number of ambient bounces) - is not part of the recipe, correct?
If that is true, then the variations between how you run a recipe (e.g. Daylight Factor) from one project/study to the next doesn’t really lie in inventing a new daylighting metric, but in how you treat everything else (e.g. the threshold you use to define what constitutes “good daylighting”, say 2%DF vs. 5%DF). All these things happen pre- or post-recipe/-simulation, so why edit the actual recipe?
I’m doing a Green Star assessment for daylighting - specifically using their Daylight Autonomy approach. The existing LBT recipe doesn’t work for me because Green Star considers a point in space to have good daylighting if it exceeds 160lux for 80% of the nominated hours.
This means I can’t just take the DA output of the recipe, but need to do some custom data crunching on the raw lux values in post, which is inconvenient and requires extra runtime:
Hi @Max, This is one of those questions that is really critical to how and why we build Pollination that I wanted to write a longer answer - sorry that I didn’t reply last week. It seems you have already faced a case where you need to edit the recipe but here is a slightly longer answer. I will use Grasshopper analogies to make it easier to make the argument here.
I wrote a longer post about how to write your own recipe here but in short there are two user-facing concepts in Pollination that are related to a recipe:
Plugin: A plugin is a collection of inter-related Functions. You can think about them similar to Grasshopper plugins. Each plugin is a collection of Functions that are trying to help with a specific domain. For example honeybee-radiance plugin for Pollination is where you can find the Functions related to Radiance including the one for annual daylight metrics.
Recipe: Recipe is a collection of these Functions connected to each other. You can think about it as a Grasshopper script and we are trying to visualize it like one. Here is the annual-daylight recipe. If you click on the step you will see the details for each step including the Function that they are referencing too. You can think about each step like a Grasshopper component. I expanded the last step which is the one that does calculate the annual metrics.
So now to answer your initial question - and if you think about it as when would you need to create a new Grasshopper script - you can think of cases like:
Editing current recipes for specific use cases: This is similar to your current case and I think it will be the most common for architects and consultants. You want to take a current recipe and add some pre-processing or custom post-processing while keeping the most of the recipe untouched.
Of course you can do what you can add these steps inside the Grasshopper plugin but that doesn’t scale. Think about running a parametric study with 1000s of options. You don’t want to download all those results to post-process each option. It will break the whole workflow.
Add new functionalities to Pollination: Even though we will provide most of the common cases for environmental building simulation we know that we can’t support every possible workflow in a recipe. The recipes will empower you to completely build a new solution for your problem and run it on Pollination just like it is developed by us. For instance the SimScale team are working on writing a recipe to integrated the available plugins with SimScale API for accurate UTCI calculation - or @Theodore_Galanos wants to run 1000s of models for training for ML.
Customer projects: This will be the case mostly for engineers and consultants. We (Ladybug Tools) use Pollination like that were we build a specific solution (as a recipe) for client projects and deploy for them to Pollination. This will give their whole office access to the solution right away from inside Pollination CAD plugins (Rhino, Grasshopper and Revit) and the web UI.
Results visualization: I imagine as soon as we add the plugin for results visualization every single recipe will be modified for a new type of results visualization. I can also imagine several recipes just for results visualization. You can nest a recipe inside another recipe. For example the comfort recipes use the annual-radiation recipe as one of the steps through the process.
Similarly, you can think about results visualization recipes that you would develop to visualize the results of the other recipes based on your office’s standards.
As I said, in other discussions we are building an editor for the recipes so it can get easier to built your own recipes but the functionalities are currently available through pollination-dsl.
I should also add that Recipe are trying to address some of the limitations of the Grasshopper scripts. They can natively run on Pollination or run locally as needed. They are version-controlled. You can set the rules and permissions for each recipe and so on.
Finally, in your example for Green Star assessment if it is OK with you to share the post-processing code I can fork the annual daylight recipe and make it specific to your needs so you can see what it takes to do that if you want to do it right now. We should probably start a new topic and discuss the details there so others can also see the process.
