diff --git a/404.html b/404.html index 9c7901f..c9f916e 100644 --- a/404.html +++ b/404.html @@ -6,13 +6,13 @@ Page Not Found | Badger - +
Skip to main content

Page Not Found

We could not find what you were looking for.

Please contact the owner of the site that linked you to the original URL and let them know their link is broken.

- + \ No newline at end of file diff --git a/assets/js/0e384e19.58ce0a6e.js b/assets/js/0e384e19.58ce0a6e.js deleted file mode 100644 index bf5c654..0000000 --- a/assets/js/0e384e19.58ce0a6e.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunkbadger_home=self.webpackChunkbadger_home||[]).push([[671],{9881:function(e,t,n){n.r(t),n.d(t,{frontMatter:function(){return s},contentTitle:function(){return l},metadata:function(){return m},toc:function(){return p},default:function(){return c}});var i=n(7462),a=n(3366),o=(n(7294),n(3905)),r=["components"],s={sidebar_position:1},l="Introduction",m={unversionedId:"intro",id:"intro",isDocsHomePage:!1,title:"Introduction",description:"Badger is an optimizer specifically designed for Accelerator Control Room (ACR). It's the spiritual successor of Ocelot optimizer.",source:"@site/docs/intro.md",sourceDirName:".",slug:"/intro",permalink:"/Badger/docs/intro",editUrl:"https://github.com/SLAC-ML/Badger-Home/edit/master/docs/intro.md",tags:[],version:"current",sidebarPosition:1,frontMatter:{sidebar_position:1},sidebar:"tutorialSidebar",next:{title:"Installation",permalink:"/Badger/docs/getting-started/installation"}},p=[{value:"Important concepts",id:"important-concepts",children:[{value:"Routine",id:"routine",children:[],level:3},{value:"Interface",id:"interface",children:[],level:3},{value:"Environment",id:"environment",children:[],level:3},{value:"Routine config",id:"routine-config",children:[],level:3}],level:2},{value:"Features",id:"features",children:[{value:"Plugin system",id:"plugin-system",children:[],level:3},{value:"Extension system",id:"extension-system",children:[],level:3}],level:2}],d={toc:p};function c(e){var t=e.components,s=(0,a.Z)(e,r);return(0,o.kt)("wrapper",(0,i.Z)({},d,s,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("h1",{id:"introduction"},"Introduction"),(0,o.kt)("p",null,"Badger is an optimizer specifically designed for Accelerator Control Room (ACR). It's the spiritual successor of ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/ocelot-collab/optimizer"},"Ocelot optimizer"),"."),(0,o.kt)("p",null,(0,o.kt)("img",{alt:"Badger architecture",src:n(4879).Z})),(0,o.kt)("p",null,"Badger abstracts an optimization run as an optimization algorithm interacts with an environment, by following some pre-defined rules. As visualized in the picture above, the environment is controlled by the algorithm and tunes/observes the control system/machine through an interface, while the users control/monitor the optimization flow through a graphical user interface (GUI) or a command line interface (CLI)."),(0,o.kt)("p",null,"Algorithms, environments, and interfaces in Badger are all managed through a plugin system, and could be developed and maintained separately. The application interfaces (API) for creating the plugins are very straightforward and simple, yet abstractive enough to handle various situations."),(0,o.kt)("p",null,"Badger offers 3 modes to satisfy different user groups:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"GUI mode, for ACR operators, enable them to perform regular optimization tasks with one click"),(0,o.kt)("li",{parentName:"ul"},"CLI mode, for the command line lovers or the situation without a screen, configure and run the whole optimization in one line efficiently"),(0,o.kt)("li",{parentName:"ul"},"API mode, for the algorithm developers, use the environments provided by Badger without the troubles to configure them")),(0,o.kt)("h2",{id:"important-concepts"},"Important concepts"),(0,o.kt)("p",null,"As shown in the Badger schematic plot above, there are several terms/concepts in Badger, and their meaning are a little different with regard to their general definitions. Let's briefly go through the terms/concepts in Badger in the following sections."),(0,o.kt)("h3",{id:"routine"},"Routine"),(0,o.kt)("p",null,"An optimization setup in Badger is called a routine. A routine contains all the information needed to perform the optimization:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"The optimization algorithm and its hyperparameters"),(0,o.kt)("li",{parentName:"ul"},"The environment on which the optimization would be performed"),(0,o.kt)("li",{parentName:"ul"},"The configuration of the optimization, such as variables, objectives, and constraints")),(0,o.kt)("p",null,"To run an optimization in Badger, the users need to define the routine. Badger provides several ways to easily compose the routine, so no worries, you'll not have to write it by hands:)"),(0,o.kt)("h3",{id:"interface"},"Interface"),(0,o.kt)("p",null,"An interface in Badger is a piece of code that talks to the underlying control system/machine. It communicates to the control system to:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"Set a process variable (PVs) to some specific value"),(0,o.kt)("li",{parentName:"ul"},"Get the value of a PV")),(0,o.kt)("p",null,"An interface is also responsible to perform the configuration needed for communicating with the control system, and the configuration can be customized by passing a ",(0,o.kt)("inlineCode",{parentName:"p"},"params")," dictionary to the interface."),(0,o.kt)("p",null,"The concept of interface was introduced to Badger for better code reuse. You don't have to copy-n-paste the same fundamental code again and again when coding your optimization problems for the same underlying control system. Now you could simply ask Badger to use the same interface, and focus more on the higher level logic of the problem."),(0,o.kt)("div",{className:"admonition admonition-tip alert alert--success"},(0,o.kt)("div",{parentName:"div",className:"admonition-heading"},(0,o.kt)("h5",{parentName:"div"},(0,o.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,o.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"12",height:"16",viewBox:"0 0 12 16"},(0,o.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"}))),"tip")),(0,o.kt)("div",{parentName:"div",className:"admonition-content"},(0,o.kt)("p",{parentName:"div"},"Interfaces are ",(0,o.kt)("strong",{parentName:"p"},"optional")," in Badger -- an interface is not needed if the optimization problem is simple enough (say, analytical function) that you can directly shape it into an environment."))),(0,o.kt)("h3",{id:"environment"},"Environment"),(0,o.kt)("p",null,"An environment is Badger's way to (partially) abstract an optimization problem. A typical optimization problem usually consists of the variables to tune, and the objectives to optimize. A Badger environment defines all the interested ",(0,o.kt)("strong",{parentName:"p"},"variables")," and ",(0,o.kt)("strong",{parentName:"p"},"observations")," of a control system/machine. An optimization problem can be specified by stating which variables in the environment are the variables to tune, and which observations are the objectives to optimize. Furthermore, one can define the constraints for the optimization by picking up some observation from the environment and giving it a threshold."),(0,o.kt)("p",null,"Take the following case as an example. Assume that we have an accelerator control system and we'd like to tune the quadupoles ",(0,o.kt)("inlineCode",{parentName:"p"},"QUAD:1"),", ",(0,o.kt)("inlineCode",{parentName:"p"},"QUAD:2")," and minimize the horizontal beam size on a screen ",(0,o.kt)("inlineCode",{parentName:"p"},"BSIZE:X"),". We also want to keep the vertical beam size ",(0,o.kt)("inlineCode",{parentName:"p"},"BSIZE:Y")," below a certain value. To do this in Badger, we could define an environment that has variables:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},"QUAD:1")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},"QUAD:2"))),(0,o.kt)("p",null,"And observations:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},"BSIZE:X")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},"BSIZE:Y"))),(0,o.kt)("p",null,"Then define a ",(0,o.kt)("strong",{parentName:"p"},(0,o.kt)("a",{parentName:"strong",href:"#routine-config"},"routine config"))," to specify details of the optimization problem, as will be mentioned in the next section."),(0,o.kt)("div",{className:"admonition admonition-tip alert alert--success"},(0,o.kt)("div",{parentName:"div",className:"admonition-heading"},(0,o.kt)("h5",{parentName:"div"},(0,o.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,o.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"12",height:"16",viewBox:"0 0 12 16"},(0,o.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"}))),"tip")),(0,o.kt)("div",{parentName:"div",className:"admonition-content"},(0,o.kt)("p",{parentName:"div"},"One environment could support multiple ",(0,o.kt)("strong",{parentName:"p"},"relevant")," optimization problems -- just put all the variables and observations to the environment, and use routine config to select which variables/observations to use for the optimization."))),(0,o.kt)("h3",{id:"routine-config"},"Routine config"),(0,o.kt)("p",null,"A routine config is the counterpart of optimization problem abstraction with regard to environment. An optimization problem can be fully defined by an environment with a routine config."),(0,o.kt)("p",null,"On top of the variables and observations provided by environment, routine config tells Badger which and how variables/observations are used as the tuning variables/objectives/constraints."),(0,o.kt)("p",null,"Use the example from the last section, the routine config for the problem could be:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-yaml",metastring:'title="Routine Config"',title:'"Routine','Config"':!0},"variables:\n - QUAD:1\n - QUAD:2\nobjectives:\n - BSIZE:X: MINIMIZE\nconstraints:\n - BSIZE:Y:\n - LESS_THAN\n - 0.5\n")),(0,o.kt)("p",null,"The reasons to divide the optimization problem definition into two parts (environment and routine config) are:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"Better code reuse"),(0,o.kt)("li",{parentName:"ul"},"Operations in ACR usually require slightly changing a routine frequently, so it's good to have an abstraction for the frequently changed configurations (routine config), to avoid messing with the optimization source code")),(0,o.kt)("h2",{id:"features"},"Features"),(0,o.kt)("p",null,"One of Badger's core features is the ability to extend easily. Badger offers two ways to extend its capibility: making a plugin, or implementing an extension."),(0,o.kt)("h3",{id:"plugin-system"},"Plugin system"),(0,o.kt)("p",null,"Algorithms, interfaces, and environments are all plugins in Badger. A plugin in Badger is a set of python scripts, a YAML config file, and an optional README.md. A typical file structure of a plugin looks like:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-shell",metastring:'title="Plugin File Structure"',title:'"Plugin',File:!0,'Structure"':!0},"|--\n |--__init__.py\n |--configs.yaml\n |--README.md\n |--...\n")),(0,o.kt)("p",null,"The role/feature of each file will be discussed in details later in the ",(0,o.kt)("a",{parentName:"p",href:"guides/create-a-plugin"},"create a plugin")," section."),(0,o.kt)("div",{className:"admonition admonition-tip alert alert--success"},(0,o.kt)("div",{parentName:"div",className:"admonition-heading"},(0,o.kt)("h5",{parentName:"div"},(0,o.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,o.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"12",height:"16",viewBox:"0 0 12 16"},(0,o.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"}))),"tip")),(0,o.kt)("div",{parentName:"div",className:"admonition-content"},(0,o.kt)("p",{parentName:"div"},"One unique feature of Badger plugins is that plugins can be nested -- you can use any available plugins inside your own plugin. Say, one could combine two environments and create a new one effortlessly, thanks to this nestable nature of Badger plugins. You could explore the infinity possibilities by nesting plugins together with your imagination!"))),(0,o.kt)("h3",{id:"extension-system"},"Extension system"),(0,o.kt)("p",null,"Extension system is another way to extend Badger's capabilities, and in a sense it's more powerful than the plugin system, since it could make a batch of existing algorithms available in Badger in a few lines of code!"),(0,o.kt)("p",null,"Let's assume that we already have an optimization platform/framework that provides a dozen of algorithms, and we'd like to use these algorithms to optimize on our machine environment. One way to do that is porting all these algorthms to Badger through the plugin system, and use Badger to perform the optimization. Extension system was designed just for this situation, since porting the algorithms one by one is tedious and inefficient. Extension system provides the APIs that are required to be implemented in order to \"port\" all the algorithms of another optimization framework/platform in one go. More details about extension system can be found in the ",(0,o.kt)("a",{parentName:"p",href:"guides/implement-an-extension"},"implement an extension")," section."),(0,o.kt)("p",null,"With the extension system, Badger could use any existing algorithms from another optimization package. Currently, Badger has the following extensions available:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/ChristopherMayes/Xopt"},"xopt"))),(0,o.kt)("p",null,"And more extensions are on the way (for example, ",(0,o.kt)("a",{parentName:"p",href:"https://teeport.ml/intro"},"teeport")," extension for remote optimization)!"))}c.isMDXComponent=!0},4879:function(e,t,n){t.Z=n.p+"assets/images/architecture-b0910240b36cb72a945230d415864f3a.png"}}]); \ No newline at end of file diff --git a/assets/js/0e384e19.5cde339a.js b/assets/js/0e384e19.5cde339a.js new file mode 100644 index 0000000..e266e9c --- /dev/null +++ b/assets/js/0e384e19.5cde339a.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunkbadger_home=self.webpackChunkbadger_home||[]).push([[671],{9881:function(e,t,n){n.r(t),n.d(t,{frontMatter:function(){return s},contentTitle:function(){return l},metadata:function(){return m},toc:function(){return p},default:function(){return c}});var i=n(7462),a=n(3366),o=(n(7294),n(3905)),r=["components"],s={sidebar_position:1},l="Introduction",m={unversionedId:"intro",id:"intro",isDocsHomePage:!1,title:"Introduction",description:"Badger is an optimizer specifically designed for Accelerator Control Room (ACR). It's the spiritual successor of Ocelot optimizer.",source:"@site/docs/intro.md",sourceDirName:".",slug:"/intro",permalink:"/Badger/docs/intro",editUrl:"https://github.com/SLAC-ML/Badger-Home/edit/master/docs/intro.md",tags:[],version:"current",sidebarPosition:1,frontMatter:{sidebar_position:1},sidebar:"tutorialSidebar",next:{title:"Installation",permalink:"/Badger/docs/getting-started/installation"}},p=[{value:"Important concepts",id:"important-concepts",children:[{value:"Routine",id:"routine",children:[],level:3},{value:"Interface",id:"interface",children:[],level:3},{value:"Environment",id:"environment",children:[],level:3},{value:"Routine config",id:"routine-config",children:[],level:3}],level:2},{value:"Features",id:"features",children:[{value:"Plugin system",id:"plugin-system",children:[],level:3},{value:"Extension system",id:"extension-system",children:[],level:3}],level:2}],d={toc:p};function c(e){var t=e.components,s=(0,a.Z)(e,r);return(0,o.kt)("wrapper",(0,i.Z)({},d,s,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("h1",{id:"introduction"},"Introduction"),(0,o.kt)("p",null,"Badger is an optimizer specifically designed for Accelerator Control Room (ACR). It's the spiritual successor of ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/ocelot-collab/optimizer"},"Ocelot optimizer"),"."),(0,o.kt)("p",null,(0,o.kt)("img",{alt:"Badger architecture",src:n(4879).Z})),(0,o.kt)("p",null,"Badger abstracts an optimization run as an optimization algorithm interacts with an environment, by following some pre-defined rules. As visualized in the picture above, the environment is controlled by the algorithm and tunes/observes the control system/machine through an interface, while the users control/monitor the optimization flow through a graphical user interface (GUI) or a command line interface (CLI)."),(0,o.kt)("p",null,"Algorithms, environments, and interfaces in Badger are all managed through a plugin system, and could be developed and maintained separately. The application interfaces (API) for creating the plugins are very straightforward and simple, yet abstractive enough to handle various situations."),(0,o.kt)("p",null,"Badger offers 3 modes to satisfy different user groups:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"GUI mode, for ACR operators, enable them to perform regular optimization tasks with one click"),(0,o.kt)("li",{parentName:"ul"},"CLI mode, for the command line lovers or the situation without a screen, configure and run the whole optimization in one line efficiently"),(0,o.kt)("li",{parentName:"ul"},"API mode, for the algorithm developers, use the environments provided by Badger without the troubles to configure them")),(0,o.kt)("h2",{id:"important-concepts"},"Important concepts"),(0,o.kt)("p",null,"As shown in the Badger schematic plot above, there are several terms/concepts in Badger, and their meaning are a little different with regard to their general definitions. Let's briefly go through the terms/concepts in Badger in the following sections."),(0,o.kt)("h3",{id:"routine"},"Routine"),(0,o.kt)("p",null,"An optimization setup in Badger is called a routine. A routine contains all the information needed to perform the optimization:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"The optimization algorithm and its hyperparameters"),(0,o.kt)("li",{parentName:"ul"},"The environment on which the optimization would be performed"),(0,o.kt)("li",{parentName:"ul"},"The configuration of the optimization, such as variables, objectives, and constraints")),(0,o.kt)("p",null,"To run an optimization in Badger, the users need to define the routine. Badger provides several ways to easily compose the routine, so no worries, you'll not have to write it by hands:)"),(0,o.kt)("h3",{id:"interface"},"Interface"),(0,o.kt)("p",null,"An interface in Badger is a piece of code that talks to the underlying control system/machine. It communicates to the control system to:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"Set a process variable (PV) to some specific value"),(0,o.kt)("li",{parentName:"ul"},"Get the value of a PV")),(0,o.kt)("p",null,"An interface is also responsible to perform the configuration needed for communicating with the control system, and the configuration can be customized by passing a ",(0,o.kt)("inlineCode",{parentName:"p"},"params")," dictionary to the interface."),(0,o.kt)("p",null,"The concept of interface was introduced to Badger for better code reuse. You don't have to copy-n-paste the same fundamental code again and again when coding your optimization problems for the same underlying control system. Now you could simply ask Badger to use the same interface, and focus more on the higher level logic of the problem."),(0,o.kt)("div",{className:"admonition admonition-tip alert alert--success"},(0,o.kt)("div",{parentName:"div",className:"admonition-heading"},(0,o.kt)("h5",{parentName:"div"},(0,o.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,o.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"12",height:"16",viewBox:"0 0 12 16"},(0,o.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"}))),"tip")),(0,o.kt)("div",{parentName:"div",className:"admonition-content"},(0,o.kt)("p",{parentName:"div"},"Interfaces are ",(0,o.kt)("strong",{parentName:"p"},"optional")," in Badger -- an interface is not needed if the optimization problem is simple enough (say, analytical function) that you can directly shape it into an environment."))),(0,o.kt)("h3",{id:"environment"},"Environment"),(0,o.kt)("p",null,"An environment is Badger's way to (partially) abstract an optimization problem. A typical optimization problem usually consists of the variables to tune, and the objectives to optimize. A Badger environment defines all the interested ",(0,o.kt)("strong",{parentName:"p"},"variables")," and ",(0,o.kt)("strong",{parentName:"p"},"observations")," of a control system/machine. An optimization problem can be specified by stating which variables in the environment are the variables to tune, and which observations are the objectives to optimize. Furthermore, one can define the constraints for the optimization by picking up some observation from the environment and giving it a threshold."),(0,o.kt)("p",null,"Take the following case as an example. Assume that we have an accelerator control system and we'd like to tune the quadupoles ",(0,o.kt)("inlineCode",{parentName:"p"},"QUAD:1"),", ",(0,o.kt)("inlineCode",{parentName:"p"},"QUAD:2")," and minimize the horizontal beam size on a screen ",(0,o.kt)("inlineCode",{parentName:"p"},"BSIZE:X"),". We also want to keep the vertical beam size ",(0,o.kt)("inlineCode",{parentName:"p"},"BSIZE:Y")," below a certain value. To do this in Badger, we could define an environment that has variables:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},"QUAD:1")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},"QUAD:2"))),(0,o.kt)("p",null,"And observations:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},"BSIZE:X")),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("inlineCode",{parentName:"li"},"BSIZE:Y"))),(0,o.kt)("p",null,"Then define a ",(0,o.kt)("strong",{parentName:"p"},(0,o.kt)("a",{parentName:"strong",href:"#routine-config"},"routine config"))," to specify details of the optimization problem, as will be mentioned in the next section."),(0,o.kt)("div",{className:"admonition admonition-tip alert alert--success"},(0,o.kt)("div",{parentName:"div",className:"admonition-heading"},(0,o.kt)("h5",{parentName:"div"},(0,o.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,o.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"12",height:"16",viewBox:"0 0 12 16"},(0,o.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"}))),"tip")),(0,o.kt)("div",{parentName:"div",className:"admonition-content"},(0,o.kt)("p",{parentName:"div"},"One environment could support multiple ",(0,o.kt)("strong",{parentName:"p"},"relevant")," optimization problems -- just put all the variables and observations to the environment, and use routine config to select which variables/observations to use for the optimization."))),(0,o.kt)("h3",{id:"routine-config"},"Routine config"),(0,o.kt)("p",null,"A routine config is the counterpart of optimization problem abstraction with regard to environment. An optimization problem can be fully defined by an environment with a routine config."),(0,o.kt)("p",null,"On top of the variables and observations provided by environment, routine config tells Badger which and how variables/observations are used as the tuning variables/objectives/constraints."),(0,o.kt)("p",null,"Use the example from the last section, the routine config for the problem could be:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-yaml",metastring:'title="Routine Config"',title:'"Routine','Config"':!0},"variables:\n - QUAD:1\n - QUAD:2\nobjectives:\n - BSIZE:X: MINIMIZE\nconstraints:\n - BSIZE:Y:\n - LESS_THAN\n - 0.5\n")),(0,o.kt)("p",null,"The reasons to divide the optimization problem definition into two parts (environment and routine config) are:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"Better code reuse"),(0,o.kt)("li",{parentName:"ul"},"Operations in ACR usually require slightly changing a routine frequently, so it's good to have an abstraction for the frequently changed configurations (routine config), to avoid messing with the optimization source code")),(0,o.kt)("h2",{id:"features"},"Features"),(0,o.kt)("p",null,"One of Badger's core features is the ability to extend easily. Badger offers two ways to extend its capibility: making a plugin, or implementing an extension."),(0,o.kt)("h3",{id:"plugin-system"},"Plugin system"),(0,o.kt)("p",null,"Algorithms, interfaces, and environments are all plugins in Badger. A plugin in Badger is a set of python scripts, a YAML config file, and an optional README.md. A typical file structure of a plugin looks like:"),(0,o.kt)("pre",null,(0,o.kt)("code",{parentName:"pre",className:"language-shell",metastring:'title="Plugin File Structure"',title:'"Plugin',File:!0,'Structure"':!0},"|--\n |--__init__.py\n |--configs.yaml\n |--README.md\n |--...\n")),(0,o.kt)("p",null,"The role/feature of each file will be discussed in details later in the ",(0,o.kt)("a",{parentName:"p",href:"guides/create-a-plugin"},"create a plugin")," section."),(0,o.kt)("div",{className:"admonition admonition-tip alert alert--success"},(0,o.kt)("div",{parentName:"div",className:"admonition-heading"},(0,o.kt)("h5",{parentName:"div"},(0,o.kt)("span",{parentName:"h5",className:"admonition-icon"},(0,o.kt)("svg",{parentName:"span",xmlns:"http://www.w3.org/2000/svg",width:"12",height:"16",viewBox:"0 0 12 16"},(0,o.kt)("path",{parentName:"svg",fillRule:"evenodd",d:"M6.5 0C3.48 0 1 2.19 1 5c0 .92.55 2.25 1 3 1.34 2.25 1.78 2.78 2 4v1h5v-1c.22-1.22.66-1.75 2-4 .45-.75 1-2.08 1-3 0-2.81-2.48-5-5.5-5zm3.64 7.48c-.25.44-.47.8-.67 1.11-.86 1.41-1.25 2.06-1.45 3.23-.02.05-.02.11-.02.17H5c0-.06 0-.13-.02-.17-.2-1.17-.59-1.83-1.45-3.23-.2-.31-.42-.67-.67-1.11C2.44 6.78 2 5.65 2 5c0-2.2 2.02-4 4.5-4 1.22 0 2.36.42 3.22 1.19C10.55 2.94 11 3.94 11 5c0 .66-.44 1.78-.86 2.48zM4 14h5c-.23 1.14-1.3 2-2.5 2s-2.27-.86-2.5-2z"}))),"tip")),(0,o.kt)("div",{parentName:"div",className:"admonition-content"},(0,o.kt)("p",{parentName:"div"},"One unique feature of Badger plugins is that plugins can be nested -- you can use any available plugins inside your own plugin. Say, one could combine two environments and create a new one effortlessly, thanks to this nestable nature of Badger plugins. You could explore the infinity possibilities by nesting plugins together with your imagination!"))),(0,o.kt)("h3",{id:"extension-system"},"Extension system"),(0,o.kt)("p",null,"Extension system is another way to extend Badger's capabilities, and in a sense it's more powerful than the plugin system, since it could make a batch of existing algorithms available in Badger in a few lines of code!"),(0,o.kt)("p",null,"Let's assume that we already have an optimization platform/framework that provides a dozen of algorithms, and we'd like to use these algorithms to optimize on our machine environment. One way to do that is porting all these algorthms to Badger through the plugin system, and use Badger to perform the optimization. Extension system was designed just for this situation, since porting the algorithms one by one is tedious and inefficient. Extension system provides the APIs that are required to be implemented in order to \"port\" all the algorithms of another optimization framework/platform in one go. More details about extension system can be found in the ",(0,o.kt)("a",{parentName:"p",href:"guides/implement-an-extension"},"implement an extension")," section."),(0,o.kt)("p",null,"With the extension system, Badger could use any existing algorithms from another optimization package. Currently, Badger has the following extensions available:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://github.com/ChristopherMayes/Xopt"},"xopt"))),(0,o.kt)("p",null,"And more extensions are on the way (for example, ",(0,o.kt)("a",{parentName:"p",href:"https://teeport.ml/intro"},"teeport")," extension for remote optimization)!"))}c.isMDXComponent=!0},4879:function(e,t,n){t.Z=n.p+"assets/images/architecture-b0910240b36cb72a945230d415864f3a.png"}}]); \ No newline at end of file diff --git a/assets/js/runtime~main.025a1f4e.js b/assets/js/runtime~main.0ce2caf5.js similarity index 98% rename from assets/js/runtime~main.025a1f4e.js rename to assets/js/runtime~main.0ce2caf5.js index e48a10d..9385cd6 100644 --- a/assets/js/runtime~main.025a1f4e.js +++ b/assets/js/runtime~main.0ce2caf5.js @@ -1 +1 @@ -!function(){"use strict";var e,t,n,r,o,c={},a={};function f(e){var t=a[e];if(void 0!==t)return t.exports;var n=a[e]={id:e,loaded:!1,exports:{}};return c[e].call(n.exports,n,n.exports,f),n.loaded=!0,n.exports}f.m=c,f.c=a,e=[],f.O=function(t,n,r,o){if(!n){var c=1/0;for(d=0;d=o)&&Object.keys(f.O).every((function(e){return f.O[e](n[u])}))?n.splice(u--,1):(a=!1,o0&&e[d-1][2]>o;d--)e[d]=e[d-1];e[d]=[n,r,o]},f.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return f.d(t,{a:t}),t},n=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},f.t=function(e,r){if(1&r&&(e=this(e)),8&r)return e;if("object"==typeof e&&e){if(4&r&&e.__esModule)return e;if(16&r&&"function"==typeof e.then)return e}var o=Object.create(null);f.r(o);var c={};t=t||[null,n({}),n([]),n(n)];for(var a=2&r&&e;"object"==typeof a&&!~t.indexOf(a);a=n(a))Object.getOwnPropertyNames(a).forEach((function(t){c[t]=function(){return e[t]}}));return c.default=function(){return e},f.d(o,c),o},f.d=function(e,t){for(var n in t)f.o(t,n)&&!f.o(e,n)&&Object.defineProperty(e,n,{enumerable:!0,get:t[n]})},f.f={},f.e=function(e){return Promise.all(Object.keys(f.f).reduce((function(t,n){return f.f[n](e,t),t}),[]))},f.u=function(e){return"assets/js/"+({13:"01a85c17",53:"935f2afb",61:"5e2ad779",75:"6d4920cb",89:"a6aa9e1f",103:"ccc49370",104:"db84cbea",152:"54f44165",195:"c4f5d8e4",214:"7a8ea9cb",249:"13db8233",276:"e689722c",288:"a2b18811",489:"2a19b374",514:"1be78505",535:"814f3328",592:"common",608:"9e4087bc",610:"6875c492",618:"72b80372",653:"67b9383b",659:"e3ae7939",671:"0e384e19",769:"6eada910",918:"17896441",965:"b171606d",978:"c7e3ca8c"}[e]||e)+"."+{13:"0af78e0c",53:"d2fa5544",61:"5d0ffce7",75:"fcbe7e19",89:"37a21e01",103:"63b3eedb",104:"f3d00777",152:"bd72746d",195:"964462aa",214:"3a552fb0",249:"5a475061",276:"95133075",288:"5c11f824",489:"a7bdca31",514:"84f0b0c2",535:"4b1b2a12",592:"914f4003",608:"6ce78891",610:"73be0d48",618:"1d60fd4f",653:"69cb3bb8",659:"5669b728",671:"58ce0a6e",707:"5cb9c152",769:"fb2223d7",814:"b54f29fc",818:"8df777da",918:"3da4c305",965:"5fe2ce0e",978:"538084c4"}[e]+".js"},f.miniCssF=function(e){return"assets/css/styles.0b6aeb32.css"},f.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),f.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},r={},o="badger-home:",f.l=function(e,t,n,c){if(r[e])r[e].push(t);else{var a,u;if(void 0!==n)for(var i=document.getElementsByTagName("script"),d=0;d=o)&&Object.keys(f.O).every((function(e){return f.O[e](n[u])}))?n.splice(u--,1):(a=!1,o0&&e[d-1][2]>o;d--)e[d]=e[d-1];e[d]=[n,r,o]},f.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return f.d(t,{a:t}),t},n=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},f.t=function(e,r){if(1&r&&(e=this(e)),8&r)return e;if("object"==typeof e&&e){if(4&r&&e.__esModule)return e;if(16&r&&"function"==typeof e.then)return e}var o=Object.create(null);f.r(o);var c={};t=t||[null,n({}),n([]),n(n)];for(var a=2&r&&e;"object"==typeof a&&!~t.indexOf(a);a=n(a))Object.getOwnPropertyNames(a).forEach((function(t){c[t]=function(){return e[t]}}));return c.default=function(){return e},f.d(o,c),o},f.d=function(e,t){for(var n in t)f.o(t,n)&&!f.o(e,n)&&Object.defineProperty(e,n,{enumerable:!0,get:t[n]})},f.f={},f.e=function(e){return Promise.all(Object.keys(f.f).reduce((function(t,n){return f.f[n](e,t),t}),[]))},f.u=function(e){return"assets/js/"+({13:"01a85c17",53:"935f2afb",61:"5e2ad779",75:"6d4920cb",89:"a6aa9e1f",103:"ccc49370",104:"db84cbea",152:"54f44165",195:"c4f5d8e4",214:"7a8ea9cb",249:"13db8233",276:"e689722c",288:"a2b18811",489:"2a19b374",514:"1be78505",535:"814f3328",592:"common",608:"9e4087bc",610:"6875c492",618:"72b80372",653:"67b9383b",659:"e3ae7939",671:"0e384e19",769:"6eada910",918:"17896441",965:"b171606d",978:"c7e3ca8c"}[e]||e)+"."+{13:"0af78e0c",53:"d2fa5544",61:"5d0ffce7",75:"fcbe7e19",89:"37a21e01",103:"63b3eedb",104:"f3d00777",152:"bd72746d",195:"964462aa",214:"3a552fb0",249:"5a475061",276:"95133075",288:"5c11f824",489:"a7bdca31",514:"84f0b0c2",535:"4b1b2a12",592:"914f4003",608:"6ce78891",610:"73be0d48",618:"1d60fd4f",653:"69cb3bb8",659:"5669b728",671:"5cde339a",707:"5cb9c152",769:"fb2223d7",814:"b54f29fc",818:"8df777da",918:"3da4c305",965:"5fe2ce0e",978:"538084c4"}[e]+".js"},f.miniCssF=function(e){return"assets/css/styles.0b6aeb32.css"},f.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),f.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},r={},o="badger-home:",f.l=function(e,t,n,c){if(r[e])r[e].push(t);else{var a,u;if(void 0!==n)for(var i=document.getElementsByTagName("script"),d=0;d Blog | Badger - +
- + \ No newline at end of file diff --git a/blog/archive.html b/blog/archive.html index 2df1003..6bd94dc 100644 --- a/blog/archive.html +++ b/blog/archive.html @@ -6,13 +6,13 @@ Archive | Badger - +

Archive

Archive

2021

- + \ No newline at end of file diff --git a/blog/tags.html b/blog/tags.html index fb002f4..ac715fe 100644 --- a/blog/tags.html +++ b/blog/tags.html @@ -6,13 +6,13 @@ Tags | Badger - +

Tags

- + \ No newline at end of file diff --git a/blog/tags/badger.html b/blog/tags/badger.html index ecd6ae9..4db2ba2 100644 --- a/blog/tags/badger.html +++ b/blog/tags/badger.html @@ -6,13 +6,13 @@ One post tagged with "badger" | Badger - +

One post tagged with "badger"

View All Tags
- + \ No newline at end of file diff --git a/blog/tags/hello.html b/blog/tags/hello.html index a70eff2..2337ddf 100644 --- a/blog/tags/hello.html +++ b/blog/tags/hello.html @@ -6,13 +6,13 @@ One post tagged with "hello" | Badger - +

One post tagged with "hello"

View All Tags
- + \ No newline at end of file diff --git a/blog/tags/slac.html b/blog/tags/slac.html index 88de6a8..0bf7e1c 100644 --- a/blog/tags/slac.html +++ b/blog/tags/slac.html @@ -6,13 +6,13 @@ One post tagged with "SLAC" | Badger - +

One post tagged with "SLAC"

View All Tags
- + \ No newline at end of file diff --git a/blog/welcome.html b/blog/welcome.html index 3cf3efc..deb1eae 100644 --- a/blog/welcome.html +++ b/blog/welcome.html @@ -6,13 +6,13 @@ Welcome | Badger - +
- + \ No newline at end of file diff --git a/docs/getting-started/installation.html b/docs/getting-started/installation.html index b53f660..c3fad99 100644 --- a/docs/getting-started/installation.html +++ b/docs/getting-started/installation.html @@ -6,13 +6,13 @@ Installation | Badger - +

Installation

Badger is essentially a python package. It's recommended to install and test it in a separate python virtual environment before using it in a production env.

Requirements

  • Python version >= 3.6. Python 3.7 is recommended

Install core package

Badger has a core package (badger-opt) that can be extended by a set of plugins. Badger core package is available on both pip and conda. So you could install Badger with:

pip install badger-opt

Or

conda install -c conda-forge badger-opt

Install sample plugins

Clone the badger plugins repo to some directory on your computer:

git clone https://github.com/SLAC-ML/Badger-Plugins.git

Set up Badger

Once badger-opt is installed and you have the badger plugins ready, run the following command:

badger

Follow the instructions and configure several paths that are needed by Badger.

- + \ No newline at end of file diff --git a/docs/getting-started/tutorial.html b/docs/getting-started/tutorial.html index 7a143bc..dee02da 100644 --- a/docs/getting-started/tutorial.html +++ b/docs/getting-started/tutorial.html @@ -6,7 +6,7 @@ Tutorial | Badger - + @@ -16,7 +16,7 @@ optimal means minimal c1) at the evaluation time are highlighted.

In the example above, we use the silly algorithm (which is just a random search algorithm) to optimize the TNK environment, as shown in the reviewed routine. Environment TNK has 2 variables and 5 observations:

TNK environment
name: TNK
version: '0.1'
dependencies:
  - numpy
params: null
variables:
  - x1: 0 -> 3.14159
  - x2: 0 -> 3.14159
observations:
  - y1
  - y2
  - c1
  - c2
  - some_array

We specify in the config.yaml that we would like to tune varaible x2, and minimize observation c1 of environment TNK as objective. The configuration that could reproduce the whole optimization setup is called a routine in Badger. A routine contains the information of the algorithm, the environment, and the config of the optimization (the variables, the objectives, and the constraints).

We just saved the routine of the run as helloworld. Now you could view the routine again by:

badger routine helloworld

Rerun an optimization

We can rerun a saved routine in Badger. Let's rerun the helloworld routine that we just saved:

badger routine helloworld -r

Badger would behave exactly the same way as the first time you run the routine.

View the historical optimization data

You can cd to the Badger archive root (the one you setup during the initial configurations) and view the historical optimization data. The file structure is a tree-like one, with year, year-month, year-month-day as the first 3 levels of branches, and the optimization runs as leaves:

Badger archive root file structure
|--2021
    |--2021-11
        |--2021-11-24
            |--BadgerOpt-2021-11-24-133007.yaml
            |--BadgerOpt-2021-11-24-113241.yaml
            |--...
        |--...
    |--...
|--...

The yaml data file contains the routine information and the solutions evaluated during the run. The content would look like this:

BadgerOpt-2021-11-24-133007.yaml
routine:
  name: helloworld
  algo: silly
  env: TNK
  algo_params:
    dimension: 1
    max_iter: 10
  env_params: null
  config:
    variables:
      - x2:
          - 0.0
          - 3.1416
    objectives:
      - c1: MINIMIZE
    constraints: null
data:
  timestamp:
    - 24-Nov-2021 13:30:06
    - 24-Nov-2021 13:30:06
    - 24-Nov-2021 13:30:06
    - 24-Nov-2021 13:30:06
    - 24-Nov-2021 13:30:06
    - 24-Nov-2021 13:30:06
    - 24-Nov-2021 13:30:06
    - 24-Nov-2021 13:30:07
    - 24-Nov-2021 13:30:07
    - 24-Nov-2021 13:30:07
  c1:
    - 2.093905436806936
    - 2.6185501712620036
    - -0.8170601778601619
    - 7.869183841178197
    - -1.0945113202011
    - 0.514833333947652
    - -1.0331173238615994
    - 1.4523371516674013
    - 1.3610274948700156
    - -0.0042273815683477045
  x2:
    - 1.78715008793524
    - 1.9283542649788197
    - 0.5319208795862764
    - 2.9948595695254556
    - 0.07408562477903413
    - 1.2707609271407632
    - 0.2586168520000207
    - 1.5976035652399507
    - 1.5687662333407153
    - 1.0467915830917118

Create a simple environment

Now let's create a simple Badger environment and run optimization on it.

WIP

- + \ No newline at end of file diff --git a/docs/guides/api-usage.html b/docs/guides/api-usage.html index d0c5a87..4142295 100644 --- a/docs/guides/api-usage.html +++ b/docs/guides/api-usage.html @@ -6,13 +6,13 @@ API Usage | Badger - +

API Usage

Badger can be imported as a regular python package, and you could use the plugins/utils that Badger offers in your own python script.

Heads-up

Make sure you have Badger installed and setup.

Use an algorithm

Badger has a get_algo API to get a specific algorithm.

The following code gets an algorithm named silly (which is a random search algorithm) from Badger.

import numpy as np
from badger.factory import get_algo

# Define a test evaluate function
def evaluate(X):
    Y = np.linalg.norm(X, axis=1).reshape(-1, 1)  # objectives
    I = None  # inequality constraints
    E = None  # equality constraints

    # Show the progress
    print(Y)

    return Y, I, E

# Get the silly algorithm from Badger
optimize, configs = get_algo('silly')

# Optimize the test evaluate function
optimize(evaluate, configs['params'])

Use an interface

Badger has a get_intf API to get a specific interface.

The following code gets an interface named silly and constructs an instance of the interface.

from badger.factory import get_intf

# Get the silly interface from Badger
Interface, configs = get_intf('silly')
intf = Interface(configs['params'])

# Test get/set channels
intf.get_value('c1')
# Output: 0

intf.set_value('c1', 1.0)
intf.get_value('c1')
# Output: 1.0

Use an environment

Badger has a get_env API to get a specific environment.

The following code gets and instantiates an environment named silly from Badger. Note that it uses the silly interface instance intf from the last section.

from badger.factory import get_env

# Get the silly environment from Badger
Environment, configs = get_env('silly')
env = Environment(intf, configs['params'])

# Investigate the silly env
env.list_vars()
# Output: ['q1', 'q2', 'q3', 'q4']

env.list_obses()
# Output: ['l1', 'l2']

env.get_var('q1')  # q1 in env maps to c1 in intf
# Output: 1.0

env.get_obs('l2')  # l2 norm of (q1, q2, q3, q4)
# Output: 1.0

env.set_var('q2', 1)
env.get_obs('l2')
# Output: 1.4142135623730951

Now we can define an evaluate function based on the silly env, and use the silly algorithm from the use an algorithm section to optimize it.

# Define an evaluate function based on the env
def evaluate(X):
    # Note that X is a 2D array
    Y = []
    for x in X:
        env.set_vars(['q1', 'q2', 'q3', 'q4'][:len(x)], x)
        y = env.get_obs('l2')
        Y.append(y)
    Y = np.array(Y).reshape(-1, 1)
    I = None
    E = None

    # Show the progress
    print(Y)

    return Y, I, E

# Optimize the evaluate function with silly algorithm
optimize(evaluate, {'dimension': 4, 'max_iter': 42})
- + \ No newline at end of file diff --git a/docs/guides/cli-usage.html b/docs/guides/cli-usage.html index fe4d072..1657eb9 100644 --- a/docs/guides/cli-usage.html +++ b/docs/guides/cli-usage.html @@ -6,13 +6,13 @@ CLI Usage | Badger - +

CLI Usage

For all the implemented and planned CLI usage, please refer to these slides. We'll highlight several common CLI use cases of Badger in the following sections.

Get help

badger -h

Or shoot me an email!

Show metadata of Badger

To show the version number and some other metadata such as plugin directory:

badger

Get information of the algorithms

List all the available algorithms:

badger algo

Get the configs of a specific algorithm:

badger algo ALGO_NAME

You'll get something like:

name: silly
version: '0.1'
dependencies:
  - numpy
params:
  dimension: 1
  max_iter: 42

Note that in order to use this plugin, you'll need to install the dependencies listed in the command output. This dependency installation will be handled automatically if the plugin was installed through the badger install command, but that command is not available yet (it is coming soon).

The params part shows all the intrinsic parameters that can be tuned when doing optimization with this algorithm.

Get information of the environments

List all the available environments:

badger env

Get the configs of a specific environment:

badger env ENV_NAME

The command will print out something like:

name: dumb
version: '0.1'
dependencies:
  - numpy
  - badger-opt
interface:
  - silly
environments:
  - silly
  - naive
params: null
variables:
  - q1: 0 -> 1
  - q2: 0 -> 1
  - q3: 0 -> 1
  - q4: 0 -> 1
  - s1: 0 -> 1
  - s2: 0 -> 1
observations:
  - l2
  - mean
  - l2_x_mean

There are several important properties here:

  • variables: The tunable variables provided by this environment. You could choose a subset of the variables as the desicion variables for the optimization in the routine config. The allowed ranges (in this case, 0 to 1) are shown behind the corresponding variable names
  • observations: The measurements provided by this environment. You could choose some observations as the objectives, and some other observations as the constraints in the routine config

Run and save an optimization

badger run [-h] -a ALGO_NAME [-ap ALGO_PARAMS] -e ENV_NAME [-ep ENV_PARAMS] -c ROUTINE_CONFIG [-s [SAVE_NAME]] [-y] [-v [{0,1,2}]]

The -ap and -ep optional arguments, and the -c argument accept either a .yaml file path or a yaml string. The configs set to -ap and -ep optional arguments should be treated as "patch" on the default algorithm and environment parameters, respectively, which means that you only need to specify the paramters that you'd like to change on top of the default configs, rather than pass in a full config. The content of the ROUTINE_CONFIG (aka routine configs) should look like this:

variables:
  - x1: [-1, 0.5]
  - x2
objectives:
  - c1
  - y2: MINIMIZE
constraints:
  - y1:
      - GREATER_THAN
      - 0
  - c2:
      - LESS_THAN
      - 0.5

The variables and objectives properties are required, while the constraints property is optional. Just omit the constraints property if there are no constraints for your optimization problem. The names listed in variables should come from variables of the env specified by the -e argument, while the names listed in objectives and constraints should come from observations of that env.

All optimization runs will be archived in the $BADGER_ARCHIVE_ROOT folder that you initially set up when running badger the first time.

Several example routine configs can be found in the examples folder.

Below are some example badger run commands. They are assumed to run under the parent directory of the examples folder (you'll need to clone the examples folder from this repo to your computer first). You could run them from any directory, just remember to change the routine config path accordingly.

A simplest run command

badger run -a silly -e TNK -c examples/silly_tnk.yaml

Run without confirmation

Badger will let you confirm the routine before running it. You could skip the confirmation by adding the -y option:

badger run -a silly -e TNK -c examples/silly_tnk.yaml -y

Change verbose level

By default, Badger will print out a table contains all the evaluated solutions along the optimization run (with the optimal ones highlighted), you could alter the default behavior by setting the -v option.

The default verbose level 2 will print out all the solutions:

badger run -a silly -e TNK -c examples/silly_tnk.yaml -v 2

The table would look like:

|    iter    |     c1     |     x2     |
----------------------------------------
|  1         |  3.73      |  2.198     |
|  2         | -0.9861    |  0.3375    |
|  3         |  1.888     |  1.729     |
|  4         |  2.723     |  1.955     |
|  5         | -1.092     |  0.08923   |
|  6         |  1.357     |  1.568     |
|  7         |  4.559     |  2.379     |
|  8         |  8.757     |  3.14      |
|  9         |  2.957     |  2.014     |
|  10        |  0.1204    |  1.105     |
|  11        |  2.516     |  1.902     |
|  12        | -0.01194   |  1.043     |
|  13        |  7.953     |  3.009     |
|  14        | -1.095     |  0.07362   |
|  15        | -0.3229    |  0.8815    |
|  16        | -1.096     |  0.06666   |
|  17        |  2.662     |  1.94      |
|  18        |  6.987     |  2.844     |
|  19        | -0.9734    |  0.3558    |
|  20        |  3.694     |  2.19      |
|  21        | -1.032     |  0.2613    |
|  22        |  2.441     |  1.882     |
|  23        |  7.042     |  2.853     |
|  24        |  4.682     |  2.405     |
|  25        |  0.5964    |  1.302     |
|  26        |  0.3664    |  1.211     |
|  27        |  1.966     |  1.751     |
|  28        |  0.2181    |  1.148     |
|  29        |  7.954     |  3.009     |
|  30        | -0.8986    |  0.4488    |
|  31        | -0.7536    |  0.5885    |
|  32        |  3.602     |  2.168     |
|  33        |  0.5527    |  1.286     |
|  34        | -0.6969    |  0.6349    |
|  35        | -1.094     |  0.07974   |
|  36        | -0.8758    |  0.4735    |
|  37        |  5.995     |  2.664     |
|  38        |  3.638     |  2.177     |
|  39        |  2.489     |  1.895     |
|  40        |  0.8434    |  1.394     |
|  41        |  0.4919    |  1.262     |
|  42        | -0.4929    |  0.7792    |
========================================

Verbose level 1 only prints out the optimal solutions along the run:

badger run -a silly -e TNK -c examples/silly_tnk.yaml -v 1

The table would look like:

|    iter    |     c1     |     x2     |
----------------------------------------
|  1         |  1.96      |  1.749     |
|  2         | -1.037     |  0.2518    |
|  18        | -1.1       |  0.01942   |
========================================

Verbose level 0 turns off the printing feature completely:

badger run -a silly -e TNK -c examples/silly_tnk.yaml -v 0

The table would not be printed.

Configure algorithm/environment parameters

The following two commands show how to config parameters of the algorithm/environment.

badger run -a silly -ap "dimension: 4" -e dumb -c examples/silly_dumb.yaml
badger run -a silly -ap "{dimension: 4, max_iter: 10}" -e dumb -c examples/silly_dumb.yaml

Run with algorithms provided by extensions

In order to run the following command, you'll need to set up xopt on your computer (since the algorithms are provided by xopt).

badger run -a cnsga -ap "max_generations: 10" -e TNK -c examples/cnsga_tnk.yaml

Save a run

To save a routine to database in $BADGER_DB_ROOT, just add the -s [SAVE_NAME] option. This command will run and save the routine with a randomly generated two-word name:

badger run -a silly -e TNK -c examples/silly_tnk.yaml -s

The following command will run the routine and save it as test_routine:

badger run -a silly -e TNK -c examples/silly_tnk.yaml -s test_routine

Rerun a saved optimization routine

Say we have the routine test_routine saved. List all the saved routines by:

badger routine

To get the details of some specific routine (say, test_routine):

badger routine test_routine

To rerun it, do:

badger routine test_routine -r

badger routine also supports the -y and -v options, as badger run does.

Configure Badger

If you would like to change some setting that you configured during the first time you run badger, you could do so with badger config.

List all the configurations:

badger config

To config a property:

badger config KEY

Where KEY is one of the keys in the configuration list.

Launch the Badger GUI

Badger supports a GUI mode. You can launch the GUI by:

badger -g
- + \ No newline at end of file diff --git a/docs/guides/create-a-plugin.html b/docs/guides/create-a-plugin.html index 48f5c48..58cb4ab 100644 --- a/docs/guides/create-a-plugin.html +++ b/docs/guides/create-a-plugin.html @@ -6,13 +6,13 @@ Create a plugin | Badger - +

Create a plugin

Plugins have three types:

  • Algorithm: function
  • Interface: class
  • Environment: class

Create an algorithm plugin

Create an interface plugin

Create an environment plugin

- + \ No newline at end of file diff --git a/docs/guides/gui-usage.html b/docs/guides/gui-usage.html index 6e03354..9633da5 100644 --- a/docs/guides/gui-usage.html +++ b/docs/guides/gui-usage.html @@ -6,13 +6,13 @@ GUI Usage | Badger - +
- + \ No newline at end of file diff --git a/docs/guides/implement-an-extension.html b/docs/guides/implement-an-extension.html index f4c1737..a1547e2 100644 --- a/docs/guides/implement-an-extension.html +++ b/docs/guides/implement-an-extension.html @@ -6,13 +6,13 @@ Implement an extension | Badger - +
- + \ No newline at end of file diff --git a/docs/intro.html b/docs/intro.html index 161225e..6c63065 100644 --- a/docs/intro.html +++ b/docs/intro.html @@ -6,13 +6,13 @@ Introduction | Badger - +
-

Introduction

Badger is an optimizer specifically designed for Accelerator Control Room (ACR). It's the spiritual successor of Ocelot optimizer.

Badger architecture

Badger abstracts an optimization run as an optimization algorithm interacts with an environment, by following some pre-defined rules. As visualized in the picture above, the environment is controlled by the algorithm and tunes/observes the control system/machine through an interface, while the users control/monitor the optimization flow through a graphical user interface (GUI) or a command line interface (CLI).

Algorithms, environments, and interfaces in Badger are all managed through a plugin system, and could be developed and maintained separately. The application interfaces (API) for creating the plugins are very straightforward and simple, yet abstractive enough to handle various situations.

Badger offers 3 modes to satisfy different user groups:

  • GUI mode, for ACR operators, enable them to perform regular optimization tasks with one click
  • CLI mode, for the command line lovers or the situation without a screen, configure and run the whole optimization in one line efficiently
  • API mode, for the algorithm developers, use the environments provided by Badger without the troubles to configure them

Important concepts

As shown in the Badger schematic plot above, there are several terms/concepts in Badger, and their meaning are a little different with regard to their general definitions. Let's briefly go through the terms/concepts in Badger in the following sections.

Routine

An optimization setup in Badger is called a routine. A routine contains all the information needed to perform the optimization:

  • The optimization algorithm and its hyperparameters
  • The environment on which the optimization would be performed
  • The configuration of the optimization, such as variables, objectives, and constraints

To run an optimization in Badger, the users need to define the routine. Badger provides several ways to easily compose the routine, so no worries, you'll not have to write it by hands:)

Interface

An interface in Badger is a piece of code that talks to the underlying control system/machine. It communicates to the control system to:

  • Set a process variable (PVs) to some specific value
  • Get the value of a PV

An interface is also responsible to perform the configuration needed for communicating with the control system, and the configuration can be customized by passing a params dictionary to the interface.

The concept of interface was introduced to Badger for better code reuse. You don't have to copy-n-paste the same fundamental code again and again when coding your optimization problems for the same underlying control system. Now you could simply ask Badger to use the same interface, and focus more on the higher level logic of the problem.

tip

Interfaces are optional in Badger -- an interface is not needed if the optimization problem is simple enough (say, analytical function) that you can directly shape it into an environment.

Environment

An environment is Badger's way to (partially) abstract an optimization problem. A typical optimization problem usually consists of the variables to tune, and the objectives to optimize. A Badger environment defines all the interested variables and observations of a control system/machine. An optimization problem can be specified by stating which variables in the environment are the variables to tune, and which observations are the objectives to optimize. Furthermore, one can define the constraints for the optimization by picking up some observation from the environment and giving it a threshold.

Take the following case as an example. Assume that we have an accelerator control system and we'd like to tune the quadupoles QUAD:1, QUAD:2 and minimize the horizontal beam size on a screen BSIZE:X. We also want to keep the vertical beam size BSIZE:Y below a certain value. To do this in Badger, we could define an environment that has variables:

  • QUAD:1
  • QUAD:2

And observations:

  • BSIZE:X
  • BSIZE:Y

Then define a routine config to specify details of the optimization problem, as will be mentioned in the next section.

tip

One environment could support multiple relevant optimization problems -- just put all the variables and observations to the environment, and use routine config to select which variables/observations to use for the optimization.

Routine config

A routine config is the counterpart of optimization problem abstraction with regard to environment. An optimization problem can be fully defined by an environment with a routine config.

On top of the variables and observations provided by environment, routine config tells Badger which and how variables/observations are used as the tuning variables/objectives/constraints.

Use the example from the last section, the routine config for the problem could be:

Routine Config
variables:
  - QUAD:1
  - QUAD:2
objectives:
  - BSIZE:X: MINIMIZE
constraints:
  - BSIZE:Y:
      - LESS_THAN
      - 0.5

The reasons to divide the optimization problem definition into two parts (environment and routine config) are:

  • Better code reuse
  • Operations in ACR usually require slightly changing a routine frequently, so it's good to have an abstraction for the frequently changed configurations (routine config), to avoid messing with the optimization source code

Features

One of Badger's core features is the ability to extend easily. Badger offers two ways to extend its capibility: making a plugin, or implementing an extension.

Plugin system

Algorithms, interfaces, and environments are all plugins in Badger. A plugin in Badger is a set of python scripts, a YAML config file, and an optional README.md. A typical file structure of a plugin looks like:

Plugin File Structure
|--<PLUGIN_ID>
    |--__init__.py
    |--configs.yaml
    |--README.md
    |--...

The role/feature of each file will be discussed in details later in the create a plugin section.

tip

One unique feature of Badger plugins is that plugins can be nested -- you can use any available plugins inside your own plugin. Say, one could combine two environments and create a new one effortlessly, thanks to this nestable nature of Badger plugins. You could explore the infinity possibilities by nesting plugins together with your imagination!

Extension system

Extension system is another way to extend Badger's capabilities, and in a sense it's more powerful than the plugin system, since it could make a batch of existing algorithms available in Badger in a few lines of code!

Let's assume that we already have an optimization platform/framework that provides a dozen of algorithms, and we'd like to use these algorithms to optimize on our machine environment. One way to do that is porting all these algorthms to Badger through the plugin system, and use Badger to perform the optimization. Extension system was designed just for this situation, since porting the algorithms one by one is tedious and inefficient. Extension system provides the APIs that are required to be implemented in order to "port" all the algorithms of another optimization framework/platform in one go. More details about extension system can be found in the implement an extension section.

With the extension system, Badger could use any existing algorithms from another optimization package. Currently, Badger has the following extensions available:

And more extensions are on the way (for example, teeport extension for remote optimization)!

- +

Introduction

Badger is an optimizer specifically designed for Accelerator Control Room (ACR). It's the spiritual successor of Ocelot optimizer.

Badger architecture

Badger abstracts an optimization run as an optimization algorithm interacts with an environment, by following some pre-defined rules. As visualized in the picture above, the environment is controlled by the algorithm and tunes/observes the control system/machine through an interface, while the users control/monitor the optimization flow through a graphical user interface (GUI) or a command line interface (CLI).

Algorithms, environments, and interfaces in Badger are all managed through a plugin system, and could be developed and maintained separately. The application interfaces (API) for creating the plugins are very straightforward and simple, yet abstractive enough to handle various situations.

Badger offers 3 modes to satisfy different user groups:

  • GUI mode, for ACR operators, enable them to perform regular optimization tasks with one click
  • CLI mode, for the command line lovers or the situation without a screen, configure and run the whole optimization in one line efficiently
  • API mode, for the algorithm developers, use the environments provided by Badger without the troubles to configure them

Important concepts

As shown in the Badger schematic plot above, there are several terms/concepts in Badger, and their meaning are a little different with regard to their general definitions. Let's briefly go through the terms/concepts in Badger in the following sections.

Routine

An optimization setup in Badger is called a routine. A routine contains all the information needed to perform the optimization:

  • The optimization algorithm and its hyperparameters
  • The environment on which the optimization would be performed
  • The configuration of the optimization, such as variables, objectives, and constraints

To run an optimization in Badger, the users need to define the routine. Badger provides several ways to easily compose the routine, so no worries, you'll not have to write it by hands:)

Interface

An interface in Badger is a piece of code that talks to the underlying control system/machine. It communicates to the control system to:

  • Set a process variable (PV) to some specific value
  • Get the value of a PV

An interface is also responsible to perform the configuration needed for communicating with the control system, and the configuration can be customized by passing a params dictionary to the interface.

The concept of interface was introduced to Badger for better code reuse. You don't have to copy-n-paste the same fundamental code again and again when coding your optimization problems for the same underlying control system. Now you could simply ask Badger to use the same interface, and focus more on the higher level logic of the problem.

tip

Interfaces are optional in Badger -- an interface is not needed if the optimization problem is simple enough (say, analytical function) that you can directly shape it into an environment.

Environment

An environment is Badger's way to (partially) abstract an optimization problem. A typical optimization problem usually consists of the variables to tune, and the objectives to optimize. A Badger environment defines all the interested variables and observations of a control system/machine. An optimization problem can be specified by stating which variables in the environment are the variables to tune, and which observations are the objectives to optimize. Furthermore, one can define the constraints for the optimization by picking up some observation from the environment and giving it a threshold.

Take the following case as an example. Assume that we have an accelerator control system and we'd like to tune the quadupoles QUAD:1, QUAD:2 and minimize the horizontal beam size on a screen BSIZE:X. We also want to keep the vertical beam size BSIZE:Y below a certain value. To do this in Badger, we could define an environment that has variables:

  • QUAD:1
  • QUAD:2

And observations:

  • BSIZE:X
  • BSIZE:Y

Then define a routine config to specify details of the optimization problem, as will be mentioned in the next section.

tip

One environment could support multiple relevant optimization problems -- just put all the variables and observations to the environment, and use routine config to select which variables/observations to use for the optimization.

Routine config

A routine config is the counterpart of optimization problem abstraction with regard to environment. An optimization problem can be fully defined by an environment with a routine config.

On top of the variables and observations provided by environment, routine config tells Badger which and how variables/observations are used as the tuning variables/objectives/constraints.

Use the example from the last section, the routine config for the problem could be:

Routine Config
variables:
  - QUAD:1
  - QUAD:2
objectives:
  - BSIZE:X: MINIMIZE
constraints:
  - BSIZE:Y:
      - LESS_THAN
      - 0.5

The reasons to divide the optimization problem definition into two parts (environment and routine config) are:

  • Better code reuse
  • Operations in ACR usually require slightly changing a routine frequently, so it's good to have an abstraction for the frequently changed configurations (routine config), to avoid messing with the optimization source code

Features

One of Badger's core features is the ability to extend easily. Badger offers two ways to extend its capibility: making a plugin, or implementing an extension.

Plugin system

Algorithms, interfaces, and environments are all plugins in Badger. A plugin in Badger is a set of python scripts, a YAML config file, and an optional README.md. A typical file structure of a plugin looks like:

Plugin File Structure
|--<PLUGIN_ID>
    |--__init__.py
    |--configs.yaml
    |--README.md
    |--...

The role/feature of each file will be discussed in details later in the create a plugin section.

tip

One unique feature of Badger plugins is that plugins can be nested -- you can use any available plugins inside your own plugin. Say, one could combine two environments and create a new one effortlessly, thanks to this nestable nature of Badger plugins. You could explore the infinity possibilities by nesting plugins together with your imagination!

Extension system

Extension system is another way to extend Badger's capabilities, and in a sense it's more powerful than the plugin system, since it could make a batch of existing algorithms available in Badger in a few lines of code!

Let's assume that we already have an optimization platform/framework that provides a dozen of algorithms, and we'd like to use these algorithms to optimize on our machine environment. One way to do that is porting all these algorthms to Badger through the plugin system, and use Badger to perform the optimization. Extension system was designed just for this situation, since porting the algorithms one by one is tedious and inefficient. Extension system provides the APIs that are required to be implemented in order to "port" all the algorithms of another optimization framework/platform in one go. More details about extension system can be found in the implement an extension section.

With the extension system, Badger could use any existing algorithms from another optimization package. Currently, Badger has the following extensions available:

And more extensions are on the way (for example, teeport extension for remote optimization)!

+ \ No newline at end of file diff --git a/index.html b/index.html index 5b828fd..6d8da88 100644 --- a/index.html +++ b/index.html @@ -6,13 +6,13 @@ Badger the Optimizer | Badger - +

Badger

The Missing Optimizer in ACR

Get Started

Easy to Use

Badger was specifically designed for operators. You could re-run an optimization routine with just one command/click.

Fast to Extend

Badger can be extended through its plugin system. Shape your algorithm/problem into a plugin in 5 minutes.

Multiple Mode

Badger can be used as a library, a command line tool, or a GUI application. Use Badger the way you want.

- + \ No newline at end of file