Estados.

La solapa Estados permite especificar algunas características que involucran a la función de Costo Futuro (CF) y del dominio de dicha función, es decir del espacio de estados del sistema.

En la Fig.20 se muestra el contenido de esta solapa.

Fig. 20: Solapa Estados.

En el panel superior “Costo Futuro Auxiliar- CFaux” es posible definir una función CF auxiliar (CFaux) para la Simulación. Para poder seleccionar el archivo debe previamente agregarlo al conjunto de archivos de la Sala como se explicó en la sec. 1.3.e).

El Costo Futuro ( CF(X,k) ) representa el valor presente esperado de la operación del sistema con una Política de Operación dada, partiendo desde el estado X en el paso de tiempo k. La información que define la Política de Operación (esto es como será el Despacho en cada paso de tiempo) está contenida en la función CF y por eso a veces se utilizan como sinónimos.

La funcionalidad de definir un CFaux, puede utilizarse durante la simulación del sistema a los efectos de dar una evaluación “auxiliar” del Costo Futuro de operación. Si bien la simulación se realiza siempre usando la función CF obtenida durante la optimización para decidir la operación óptima, la función CFaux se puede utilizar para analizar la evaluación del Costo Futuro que haría otro Operador utilizando una política de operación diferente (contenida en CFaux). Es una forma de poder comparar dos políticas de operación. Permite analizar cómo sería vista la operación del sistema por un Operador diferente, informando cual es el valor de CFaux(X,k) para cada estado X por los que va evolucionando el sistema (X representa el estado del sistema resultante de la simulación paso a paso). El valor CFaux(X,k) es exportado como variable disponible durante la Simulación. (ver Tomo 4 SimRes3 ).

Como ejemplo, esta funcionalidad se utilizó para comparar una política de operación del sistema que incluya información del Niño 3.4 en la previsión de aportes hidráulicos, con otra que no considere dicha información. Para más detalle sobre este ejemplo de aplicación puede consultarse el trabajo de Chaer R., Terra R., Diaz A., Zorrilla J., “Considering the information of the Niño 3.4 index in the operation of the Electrical System of Uruguay”, 33º IAEE Rio de Janeiro 2010.

http://iie.fing.edu.uy/publicaciones/2010/CTDZ10/CTDZ10.pdf

 

El panel inferior “Inicialización de Costo Futuro” permite especificar la forma en que queremos inicializar los valores de la función CF al final del último paso de tiempo del horizonte de Optimización. El algoritmo de optimización dinámica estocástica realiza el cálculo de CF en los demás pasos de tiempo a partir de esa inicialización.

Las opciones son:

• “Ceros”: esto implica poner a cero el CF sobre todo el espacio de estado al final del último paso de tiempo del horizonte de optimización. Es la opción que se utiliza por defecto cuando no se va a “enganchar” la corrida con otra, esto es, los valores de costo futuro se comienzan a calcular desde cero, y no se toman valores iniciales provenientes de otra corrida.

• “Desde archivo CF.bin”: esto implica que la Sala actual “engancha” en otra corrida de más largo plazo cuya optimización ya fue realizada. En este caso hay que usar el selector para seleccionar el archivo (formato binario) de la corrida de más largo plazo desde la que queremos inicializar la corrida actual. El encadenamiento de corridas es útil para poder ir agregando detalle al modelado en el corto plazo y poder realizar optimizaciones en un tiempo de cálculo razonable.

El uso más común de esta opción es para realizar la valorización escalonada del agua de los embalses de las centrales hidroeléctricas. Por ejemplo, en el sistema uruguayo, las corridas que involucran horizontes superiores al año se realizan con paso de tiempo semanal y solamente se considera el embalse de la represa de Rincón del Bonete, por ser el único con capacidad de embalse de algunos meses. De esa forma se obtiene la valorización del agua del mayor embalse del país. Ese tipo de Sala es útil a los efectos de estudios de planificación. Para propósitos de la programación del despacho de corto plazo es necesario un modelado más detallado, por lo que se construyen Salas que consideran los embalses cuya capacidad de embalse es de unas 2 semanas. Estos embalses semanales no tienen relevancia al considerar períodos plurianuales, pero sí cuando se analiza el mediano o corto plazo.

La posibilidad de enganchar Salas permite reducir tiempo de cálculo sin perder precisión, permitiendo “refinamientos sucesivos” según el horizonte de tiempo que se desee observar.

Para realizar el enganche, SimSEE identifica la fecha del fin del último paso de la Sala y se interpolan los valores en la función CF a la que se engancha la Sala. Esto resuelve el enganche temporal, no importando si los pasos de tiempo son diferentes, basta solo que la fecha de fin del último paso de tiempo del horizonte de optimización de la Sala actual esté comprendida en el horizonte de tiempo de optimización de la corrida a la que la estamos enganchando. También se interpola en las variables de estado, por lo cual no es necesario que las discretizaciones de las diferentes variables coincidan en ambas corridas.

Al estar enganchando dos funciones CF(X,k), puede darse el caso de que los espacios de estado sean diferentes (de hecho ese es el caso del ejemplo antes comentado). Puede ocurrir que en la corrida actual existan nuevas variables de estado (volumen del embalse agregado, en el ejemplo mencionado). En ese caso no existe información del comportamiento de CF sobre esa dimensión del estado en la corrida a la que estamos enganchando la actual, pues en esa corrida no existía esa dimensión del estado del sistema. Para inicializar el CF en el primer cuadro de cálculo sobre las nuevas dimensiones que se agregan al espacio de estado lo que se hace es suponer que la derivada del CF respecto de esa dirección es cero (esto significa asignar un costo nulo al uso de la variable de estado).

Otro caso que se puede dar es que en la nueva corrida desparezca una variable de estado de las que estaban definidas en la corrida a la que nos enganchamos. En ese caso hay que decidir qué valor se le fija en el CF de la corrida a la que nos enganchamos a esa variable de estado. Para ello está el botón “Definir Enganches”. Por defecto, los enganches se definen con el punto medio de los intervalos de las variables de estado, pero usando este botón es posible cambiar el valor. Un ejemplo de uso de esto puede ser la consideración de la aleatoriedad del precio del petróleo. En corridas de largo plazo no es posible considerar el precio del barril de petróleo como una constante y puede ser relevante entonces considerarlo como una fuente aleatoria con estado (modelo CEGH). Pero al ir a la corrida semanal, con paso horario no tiene sentido mantenerla como una variable de estado y se puede suponer que se conoce su valor: en este caso habría que usar el botón “definir enganches” para fijar el valor del precio del barril de petróleo al valor que estimamos podemos considerar razonable para la semana considerada.

 

El botón “Vaciar” le permite eliminar por completo el enganche y volver la definición por defecto “Ceros”.

 

 

El botón “Definir Enganches” le permite acceder al Editor de Enganches que se muestra en la Fig.21. De lo que se describió en los párrafos anteriores, el Enganche entre de la Sala A con el resultado de la optimización de la Sala B, implica definir valores para la función de Costo futuro al final del Horizonte de optimización de la Sala A a partir de la información obtenida del costo futuro, resultado de la optimización de la sala B, para el mismo instante temporal. Si el vector \( X \) describe el espacio de estado de la Sala A y el vector \( Y \) describe el espacio de estado de la sala B, el mapeo que define el enganche se puede expresar como: \( Y=F(X) \)  y la inicialización como: \( CF_A( X, t_{final_{H_A}} ) = CF_B( F(X), t_{final_{H_A}} ) \)

Para la definición de \( Y = M(X) \), el formulario permite dos opciones en el panel “Tipo de mapeo”. Si se selecciona “Simple”, vale lo que se muestra en el Panel “Mapeo Simple” en el panel izquierdo en la parte superior. Si se selecciona “\( Y = F(X) \)” vale lo que se muestra en el panel derecho de la parte superior.

Fig. 21: Editor de engaches.

En el mapeo simple, las variables que con igual nombre en ambos espacios de estado son asignadas directamente, las variables “nuevas” esto es presentes en \( X \) y no disponibles en \( Y \) son ignoradas en el mapeo (lo que implica imponer \( {{\partial} \over {\partial x_k}} CF_A = 0 \) para cada variable nueva \( x_k \)) y las variables “desaparecidas”, esto es presentes en \( Y \), pero no disponibles en \( X \)son fijadas en un valor que por defecto es la mitad del intervalo de la variable pero que puede especificarse utilizando el panel “Mapeo Simple”.

Si se selecciona “Mapeo Y=F(X)” es posible escribir la expresión en forma explícita en el panel correspondiente. La sintaxis es la siguiente:

Dos barras “//” indican que lo que sigue hasta el final de la línea es un comentario y no será interpretado.

Cada variable del espacio de estado X correspondiente a la Sala que estamos editando se identifica como “$X_Nombre”, siendo “Nombre” el nombre con que la variable es publicada en SimSEE. Cada variable del espacio de estado , correspondiente a la función de Costo Futuro a la que estamos enganchando la Sala en edición, es identificada como “$Y_Nombre”. La asignación Y=F(X) se define entonces por varias sentencias de asignación del tipo “$Y_Nombre := expresión;”, utilizando como operador de asignación “:=” y pudiendo la expresión tener definiciones en base a los operadores estándar de suma producto y funciones estándar como log(), exp(), cos(), etc.

En el formulario de la Fig.20, el casillero “Enganchar Promediando Desaparecidas” se aplica solo en el caso de “Mapeo Simple” y si dicho casillero está marcado, se fija para la variable desaparecida el promedio del costo futuro en el rango de discretización de la variable.

En el formulario del a Fig.20, en el campo “Uniformizar promediando” es posible introducir una lista de variables de estado (separadas por “;” punto y coma) para las que se quiere imponer un valor de CF constante e igual al promedio de los valores en la dirección de cada variable. Esta uniformización se ejecuta al final de realizado el enganche en cualquier de los tipos de mapeo. Esta opción es raramente usada y se incorporó con propósitos de investigación.

 

Por último, abajo a la izquierda en la Fig.20, se tiene un casillero “Estabilizar Frame Inicial”. Si se marca este casillero, el algoritmo de programación dinámica estocástica se corre varias veces sobre el último paso de tiempo, tratando de estabilizar la función CF. El procedimiento consiste en calcular el valor de CF al inicio del último paso de tiempo del horizonte de optimización a partir del valor de CF al final de dicho paso de tiempo, luego copiar el valor obtenido sobre los valores de inicio de cálculo y así repetidas veces hasta que se logre estabilizar las derivadas de CF respecto de las diferentes direcciones del estado. Este procedimiento es alternativo a definir un horizonte de optimización más amplio que el de simulación para dejar un “tiempo de guarda” para que el algoritmo se estabilice. Como el resultado es aproximadamente el mismo, es preferible optar por dejar el “tiempo de guarda” y dejar desmarcado este casillero, ya que de esa forma en el archivo de salida de la optimización se registrarán todos los valores de CF, comenzando por el cuadro de inicio del cálculo e incluyendo el tramo de guarda. Esto permite visualizar mejor el transitorio de estabilización. Si se opta por marcar el casillero y usar así la estabilización del primer cuadro de cálculo, se pierde la posibilidad de inspeccionar el transitorio en el archivo de salida de la optimización. Por otra parte, si se utilizan años de guarda, es necesario realizar las proyecciones de futuro pertinentes para el sistema (p.ej. demanda, generación disponible, etc.) que abarquen dicho horizonte “ampliado”.