Simulacion en Vensim

GUIA DE USUARIO VENSIM
http://www.dinamica-de-sistemas.com/
Vensim
http://www.atc-innova.com/
14 Reality Check
Se construyen modelos para solucionar problemas. Una vez construdos, existen varias
pruebas que se pueden hacer para confrontarlos con la realidad. Las pruebas deben ser
explcitas y tomar la forma de exmenes de comportamiento del modelo, o de partes del
modelo, bajo diferentes suposiciones, o pueden ser simulaciones mentales implcitas y
anlisis basados en el entendimiento de los modelos y del proceso de modelado. En ambos
casos estas pruebas son muy importantes para asegurarse de que el modelo que se
desarroll puede representar adecuadamente los problemas a los que es aplicado.
Los Reality Check dan una va directa para plantear pautas que se piensa deben ser
verdaderas acerca del modelo para ser til, y las herramientas para verificar
automticamente la conformidad del modelo a esas pautas. Reality Check es una nueva
tecnologa que se agrega para validar y defender los modelos que se construyen. Puede
focalizar las discusiones a partir de ciertas suposiciones hechas en los modelos hacia
convicciones ms slidamente fundadas acerca de la naturaleza de la realidad.
Este captulo:
Introduce el concepto de un Reality Check.
Muestra como crear Constraints (Restricciones) y Test Inputs (Entradas de prueba)
Muestra como controlar la coherencia de un modelo con las ecuaciones de Reality

Check.
Muestra como construir un modelo usando Reality Check.
Copyright 1998-2007 Ventana Systems, Inc.

Traducido al espaol con autorizacin
Copyright de la traduccin (c) 2007 Juan Martin Garcia
Causal Tracing, Reality Check, Vensim and Ventana
son marcas registradas de Ventana Systems, Inc.
Gua del Usuario de Vensim
http://atc-innova.com
Los modelos y la realidad
Los modelos son representaciones de la realidad, o bien percepciones personales de la

realidad. Para validar la utilidad de un modelo, es importante determinar si las cosas que se
observan en la realidad tambin se mantienen verdaderas en el modelo. Esta validacin se
puede hacer usando mtodos formales o informales para comparar las mediciones y los
comportamientos del modelo. La comparacin se puede hacer observando series
temporales de datos, observando si las condiciones corresponden a descripciones
cualitativas, controlando la sensibilidad de las suposiciones en el modelo, y desarrollando
explicaciones correctas para los comportamientos generados por el modelo y los patrones
de comportamiento.
Otro importante componente en la validacin de un modelo es la consideracin detallada de
los supuestos acerca de la estructura. Los usuarios no requerirn informacin que no est
disponible para tomar decisiones. Es necesario reforzar las relaciones causales. Los
materiales se deben conservar.
Entre los detalles de la estructura y la abrumadora riqueza de comportamiento, hay muchas
cosas que se pueden decir acerca de un modelo y que raramente lo influencian. Si se tuviera
que completar la frase Para que un modelo o submodelo sea correcto
cuando__________debera________, se vera que hay muchas cosas que se pueden hacer
a un modelo para encontrar problemas y desarrollar confianza en l.
En la mayora de los casos, algunas de las condiciones para que un modelo sea correcto son
tan importantes que se las verifica. En otros casos, las condiciones no se expresan acerca
del modelo completo sino acerca de un pequeo componente del modelo, o una ecuacin.
En tales casos, como constructor de modelos, se puede disear sobre las experiencias
propias y el trabajo de otros relacionado al comportamiento de estructuras genricas y
formulaciones especficas.
Sin embargo, la mayora de las condiciones que necesitan cumplirse para que un modelo
sea correcto nunca se verifican. Usando las tcnicas tradicionales de modelado, los
procedimientos de verificacin requieren separar partes del modelo, ejecutarlos con
diferentes entradas, cambiar la estructura bsica en ubicaciones preseleccionadas, hacer
muchas de simulaciones, y revisar los resultados. An cuando se haga esto, se efecta a
menudo sobre una versin del modelo que posteriormente es revisada, sin verificar el
efecto de las revisiones.
Las ecuaciones de Reality Check proporcionan un lenguaje para indicar lo que es necesario
que se cumpla para que un modelo sea correcto, y las herramientas para verificar
automticamente la conformidad con tales requerimientos. Las especificaciones que se
hacen a un modelo no estn atadas al modelo. Estn separadas de las ecuaciones normales
del modelo y no interfieren con su funcionamiento normal. Presionando un botn es
posible ver en que puntos un modelo viola o no las restricciones que impone la realidad.
El dominio de la experiencia
Aunque las ecuaciones de Reality Check en Vensim se escriben como una extensin del
lenguaje de modelado, las herramientas y la experiencia requeridas para escribir ecuaciones
de Reality Check son diferentes que las requeridas para escribir el modelo. Las ecuaciones
de Reality Check son afirmaciones acerca de la naturaleza del comportamiento en la
realidad. No requieren la creacin de una estructura capaz de generar un comportamiento
particular. Las ecuaciones de Reality Check crean condiciones de comportamiento y luego
verifican si la estructura del modelo ofrece una respuesta de comportamiento apropiada.
Debido a que las ecuaciones de Reality Check se formulan en un entorno de
comportamientos, las personas ms apropiadas para formularlas son aquellas que mayor
conocimiento tienen del comportamiento, en general, expertos en el tema en estudio. Por
este motivo, las ecuaciones de Reality Check permiten mucho ms que encontrar errores
sintcticos en el modelo. Las ecuaciones de Reality Check permiten al usuario de un
modelo tener confianza en la calidad de los resultados que obtiene.
Definir las ecuaciones de Reality Check
Las ecuaciones de Reality Check se escriben de la misma manera que las ecuaciones en
Vensim. Se pueden usar las herramientas de esquema (Sketch Tool) para definir entradas a
las ecuaciones de Reality Check, o simplemente escribir las ecuaciones directamente en el
Editor de Ecuaciones o en el editor de Texto. Estructuralmente las ecuaciones de Reality
Check no son entradas a ninguna ecuacin del modelo, pero usan variables del modelo en
sus definiciones. Cuando se efecta un ejercicio de Reality Check, pueden cambiar el valor
de las variables del modelo tanto como las ecuaciones usadas para computarlas. Sin
embargo, se enfatiza que las ecuaciones de Reality Check no son proposiciones acerca de la
estructura causal sino acerca del comportamiento-Si pasa esto, entonces debe ocurrir
esto-.
Las convenciones acerca de nombres apropiados para ecuaciones Reality Check son
diferentes de aquellas para variables de modelo. Las variables de modelo deberan tener
nombres con significado ms o menos obvio Mano de obra, productividad,
capacidad, determinacin, propensin al ahorro y similares. Por otra
parte, las ecuaciones de Reality Check deberan ser frases que describen la naturaleza de la
verificacin sin trabajadores no hay produccin, lluvia implica
inundacin. La mejor gua para definir nombres en Reality Check es pensar en ellas
como verdaderas o falsos, y nombrar el Reality Check con la proposicin que debera
verificarse cuando resulta verdadera.
Hay dos tipos de ecuaciones que pueden ser definidas en Vensim para hacer uso de las
funciones de Reality Check: Constraints (Restricciones) y Test Inputs (Entradas de
prueba). Las Restricciones hacen proposiciones acerca de las consecuencias que podran
resultar de un determinado conjunto de condiciones. Se llaman as porque especifican la
manera en que las Entradas de Prueba podran restringir el comportamiento. La violacin
de una Restriccin indica un problema en el modelo. Las Entradas de Prueba son una
manera de especificar condiciones o circunstancias bajo las cuales surgen las Restricciones.
Dado que las Entradas de Prueba pueden ser usadas con las Restricciones, se describen
primero.
Test Inputs
Los Tests Inputs permiten definir condiciones alternativas cambiando las ecuaciones para
una variable en el modelo. Su forma bsica es:
nombre :TEST INPUT: variable = expresin
Donde nombre es el nombre de un Test Input. Lo que aparece a la izquierda de un :TEST
INPUT: es exactamente el mismo formato de ecuacin que normalmente se usa para definir
una variable auxiliar y slo puede contener variables del modelo. La ecuacin que escribe
est tambin restringida porque no se pueden usar funciones dinmicas (tal como
SMOOTH), funciones de definicin (como ACTIVE INITIAL) ni usar Macros. Si se
necesitara este tipo de funcionalidad, se pueden crear variables extras en el modelo para
usar en Test Inputs.
Los Test Inputs solo se pueden usar en la parte condicional de las ecuaciones de
Restriccin. La razn ms importante para definir Test Inputs es dar un nombre a la
experiencia que se est desarrollando. Esto se puede hacer ms fcilmente leyendo la
Restriccin. Si no se definen Test Inputs, se pueden definir Constraints usando la parte
variable = expresin de la ecuacin de Test Input. Se aplican los mismos formatos de
restriccin de las ecuaciones.
Test Inputs dinmicos

Adicionalmente a una expresin alternativa para un Test Input, es a menudo deseable
forzar un cambio en una variable despus de un perodo de tiempo de simulacin. Por
ejemplo, se puede desear que la produccin caiga en forma de rampa a 0 en el lapso de 10
a 12, pero antes del tiempo 10 dejar la produccin tal como era anteriormente. Este tipo de
cambio es usual para escribir Reality Checks completos para el estudio de la respuesta del
modelo a Test Inputs de inters.
Para crear Test Inputs con un cierto perfil de tiempo hay una serie de funciones que
comienzan con RC RC COMPARE, RC DECAY, RC GROW, RC RAMP y RC
STEP (detalles en el Captulo 4 del Reference Manual). Todas se comportan de una
manera similar. Por ejemplo:
TI Produccion a cero :TEST INPUT:
produccion = RC RAMP(produccion,0,2,10)
Este Test Input causar que la produccion caiga de su valor a tiempo 10 hasta cero a
tiempo 12.
Todas las funciones RC.toman dos argumentos opcionales: un tiempo de comienzo y una
duracin. Si se omite duracin Test Input contina en estado de cambio hasta el final de la
simulacin. Si se especifica una duracin el Test Input continuar cambiando hasta el
tiempo especificado, y luego la variable revierte hasta su valor normalmente computado.
Si el tiempo de comienzo (10 en el presente ejemplo) se omite, y el modelo contiene la
constante RC START TIME, el cambio comienza a este tiempo especifico Si RC START
TIME no est en el modelo, el cambio empezar a INITIAL TIME + TIME STEP. Usando
RC START TIME de esta forma es conveniente porque permite cambiar globalmente el
tiempo al cual los cambios producen efecto y permite eliminar argumentos adicionales en
las funciones RC. Tener Test Inputs que comienzan durante la simulacin es til porque
previene la interferencia entre el comportamiento del modelo y su verificacin, y permite
ejecutar simulaciones de prueba con valores relativos diferentes para las variables.
Constraints (Restricciones)
Las Constraints toman la forma:
nombre :THE CONDITION: condicin :IMPLIES: consecuencia
:THE CONDITION: y :IMPLIES: son palabras clave especiales en Vensim. Condicion y
consecuencia son expresiones lgicas que se describen abajo. El nombre de una Constraint
debe usar letras y nmeros tal como otras variables en Vensim. Las Constraints no
necesitan unidades de medida, aunque si se est usando el Editor de Texto se debe poner el
smbolo ~ como un separador. Se pueden adicionar comentarios a las Constraints tal como
se hace con otras variables en Vensim.
Expresiones lgicas
Las Constraints usan una condicin y una consecuencia que son definidas como
expresiones lgicas. Un ejemplo de esto podra ser:
sin capital no hay
produccin :THE CONDITION: Capital = 0
:IMPLIES: produccin = 0
Cuando se prueban las ecuaciones de Reality Check, Vensim fuerza una condicin a ser
cierta aunque el modelo genere valores que sugieren que podra o no ser cierta, y controla
la veracidad de la consecuencia. Si la condicin es cierta, pero la consecuencia no lo es,
Vensim muestra el problema como un error del Reality Check. Vensim tambin hace
verificaciones pasivas, como se describe a continuacin. Las expresiones lgicas puede ser
ms complicadas que la anterior. Se construyen usando comparaciones =, >, <, and <>
junto a :OR:, :AND: y :NOT:. Una expresin lgica podra ser:
Poblacin > 8E9 :AND: (disponibilidad de alimentos < .75 :OR:
Polucin > polucin crtica)
Aqu se comparan varias situaciones, y esta expresin ser cierta si Poblacin > 8E9 y
tambin (disponibilidad de alimentos < .75 o Polucin > polucin crtica, o ambas.
Las expresiones lgicas pueden hacerse difciles de entender y se recomienda no combinar
demasiadas cosas en una condicin. En el segmento consecuencias, es a menudo usual
tener muchos puntos combinados con :AND: (para verificar varias consecuencias partiendo
de una condicin simple), pero raramente son tiles estructuras ms complicadas.
El segmento correspondiente a la condicin de una Constraint est restringido a la
comparacin de variables con variables y variables con nmeros. La nica excepcin es
que se puede usar variable = expresin ., o un Test Input con nombre como componente de
una de las condiciones lgicas. Esto es:
pop lt cc :THE CONDITION : Poblacin < Capacidad de carga * 1.1
:IMPLIES: muertes por sobrepoblacin < 1000
es errnea porque toma la forma de variable < expresin, donde:
pop lt cc :THE CONDITION : Poblacin = Capacidad de carga * 1.1
usa variable = expresin
y es una expresin legtima. Las expresiones includas
directamente en las condiciones de Constraint en esta forma pueden usar TIME
TRANSITION y deben ajustarse a las reglas para formar Test Inputs.
Los Test Inputs se deben usar como condicin de una Constraint, como en:
pop lt cc :THE CONDITION : pop at cc plus 10
Donde pop at cc plus 10 es un Test Input. Observar que los Test Inputs son
tratados como variables lgicas que toma un valor de verdad si estn activos, o falso si no
lo estn. Todos los componentes de una Constraint estn limitados a usar funciones simoles
(MIN, MAX, SUM, etc). Para otras funciones, no hay restricciones en las expresiones
lgicas del segmento consecuencias de la definicin de una Constraint.
No es usual verificar igualdad en las consecuencias porque las pruebas de igualdad son
muy propensas a fallar an cuando no hay nada errneo en el modelo. Esto es debido a que
conceptos equivalentes por definicin, pero computados de diferentes maneras, suelen ser
levemente diferentes en valor numrico, lo cual ser evidenciado durante un test de
igualdad.
Pruebas Dinmicas en las Consecuencias
Las ecuaciones Reality Check que tienen Test Inputs con funciones del tipo
RCnormalmente usan una funcin RC.CHECK en el segmento consecuencia. Las
funciones RCCHECK trabajan de una manera anloga a las funciones RCde los Test
Inputs. Mientras que los Test Inputs cambian el valor de una variable, el segmento
consecuencia de una Constraint hace una comparacin del valor de la variable. Las
funciones RC.CHECK toman un argumento ms que la correspondiente funcin RC.
Este argumento es el perodo de gracia y permite un retraso despus que se produce el Test
Input y antes de que las consecuencias sean verificadas. Por ejemplo:
TI Produccin a cero :TEST INPUT: produccin =
RC STEP(production,0)
RC Sin produccin no hay despachos :THE CONDITION: TI Produccin
a cero :IMPLIES: ventas <= RC RAMP CHECK(.5, ventas,.0001)
El Test Input hace que produccin caiga a cero a RC START TIME. Despus de un
perodo de gracia de 0.5 se verifica si las ventas son iguales o menores a 0.0001 por el
valor que tenan a RC START TIME. El uso de 0.0001 en lugar de 0 previene violaciones
que podran ocurrir con formulaciones contnuas y es una buena prctica.
El perodo de gracia es el primer argumento de todas las RC.CHECK excepto para RC
COMPARE CHECK, el cual toma primero el nombre literal de un archivo.
:CROSSING:
En el segmento de las consecuencias de un Reality Check se puede usar :CROSSING: y
:AT LEAST ONCE: con > y < para buscar relaciones del tipo por arriba/debajo, como en:
... :IMPLIES:
Inventario > :CROSSING: RC STEP CHECK(0,Inventario,1)
Esto verificar que a RC START TIME, Inventario es primero mayor que su valor de
base y luego se hace menor y permanece menor. Si hubiera dos :CROSSING: en una lnea
como en:
Inventario > :CROSSING: :CROSSING: RC STEP CHECK(0,Inventario,1)
Inventario necesita comenzar mayor, luego se hace menor, luego vuelve a hacerse mayor y
permanece as.
Si se usa ms de un :CROSSING:, se puede finalizar la secuencia con :IGNORE: para
indicar que una vez realizado el nmero requerido de cruzamientos, no preocupa si se
producen nuevos cruces. Por ejemplo:
Inventario > :CROSSING: :IGNORE: RC STEP CHECK(0,Inventario,1)
Esto dice que Inventario necesita comenzar mayor, luego hacerse menor, luego no importa
lo que ocurra.
:AT LEAST ONCE:
Anlogo a :CROSSING: , la palabra clave :AT LEAST ONCE: simplemente requiere que
una condicin sea verdad una vez despus de RC START TIME. Por ejemplo:
Inventario > :AT LEAST ONCE: RC STEP CHECK(0,Inventario,1)

dice que Inventario debe exceder su valor a RC START TIME por lo menos una vez
durante el resto de la simulacin. Debera estar siempre por encima, o cruzar de abajo a
arriba. Si el valor esta por encima al menos una vez, este puede cruzar nuevamente abajo y
la condicin permanecer verdadera.
Condiciones vacas (Empty Conditions)

La parte condicional de una Constraint puede estar vaca, como en:
dbito limitado :THE CONDITION: :IMPLIES: dbito < 4E6
Esta ecuacin establece que, sin importar lo que ocurra nunca habr un dbito mayor a
cuatro millones. Observar que Vensim no trata de verificar todas las condiciones posibles
del modelo si encuentra una condicin vaca. Las Constraints con condiciones vacas se
verifican pasivamente para cualquier perodo en el que se est usando la funcin Reality
Chef, y detectar un dbito alto. Para el ejemplo simple que se muestra aqu, usando 4 E6
como el valor mximo que el dbito debera tomar en su ecuacin tambin resultar en un
mensaje cuando el dbito excede 4 E6 en la medida en que las advertencias no estn
suprimidas. La Condicin Vaca puede ser usada para evaluar expresiones mucho ms
generales.
Wildcard Tests (comodines) en las Consecuencias

Adems de verificar una variable, se puede verificar todas las variables para ver si
satisfacen una condicin. Para hacer esto usar un * en lugar del nombre de una variable.
Por ejemplo se puede escribir la restriccin:
Todo tranquilo :THE CONDITION: FINAL TIME=101 :IMPLIES:
* < 1E9 :AND: * >= -1E3
Lo cual verificar que todas las variables estn en el rango -1000 a 1000 000 000. La
condicin FINAL TIME = 101, que simplemente ejecuta la simulacin un ao extra, se usa
en lugar de la Condicin Vaca porque esta es una verificacin que consume tiempo y las
Constraints con condiciones vacas se verifican pasivamente cada vez que se ejecuta
cualquier Reality Check.
10
Simulacin y Reality Check
Antes de comentar la mecnica de ejecutar ecuaciones de Reality Check, es usual describir

muy brevemente que ocurre dentro del modelo. Las ecuaciones de Reality Check
involucran una intervencin sistemtica en la estructura bsica del modelo. Son
cualitativamente diferentes de los anlisis de sensibilidad en que estos no son vas de
influencia bien definidas. Los Test Inputs y las Constraints pueden generar la necesidad de
hacer cambios en casi cualquier punto de un modelo.
A efectos de cumplir los cambios indicados en la ejecucin de las ecuaciones de Reality
Check, Vensim reestructura el modelo, agregando ecuaciones y modificando la secuencia
en que las ecuaciones se computan. Despus de completar las ecuaciones de Reality Check,
Vensim retorna el modelo a su estructura original. Esto significa que efectuar el
seguimiento causal (causal tracing) en una simulacin hecha con uno o ms Test Inputs
activos puede dar resultados sorprendentes y aparentemente incorrectos.
En algunos casos, la reestructuracin y reordenamiento pueden dejar al modelo
deformado. El ms comn de los problemas es que el modelo podra contener ecuaciones
simultneas y por lo tanto, no se pueda simular. Si este es el caso, Vensim mostrar el
problema y no completar la simulacin. Debido a la naturaleza vinculada al
comportamiento de las ecuaciones Reality Check, la existencia de ecuaciones simultneas
no representa necesariamente un problema conceptual, pero impide la simulacin. De ser
posible, se deben reformular los Test Inputs que causan problemas para evitar ecuaciones
simultneas.
NOTA: las ecuaciones de Reality Check se ejecutan siempre usando simulaciones
interpretadas, no compiladas. Esto es porque requieren continuas reestructuraciones de las
ecuaciones.
11
Verificaciones Active Constraint
Durante las verificaciones activas con Constraints, Vensim fuerza la parte condicional de
una Constraint a ser verdadera, cambiando los valores de las variables o la estructura del
modelo cuando sea necesario.
Si la condicin es una igualdad o un Test Input, Vensim agrega la ecuacin a la

ecuacin existente en el modelo (recordar que la ecuacin debe referenciarse al valor
originalmente computado para la variable). El nuevo valor de la variable se utiliza
entonces cada vez que esta se usa.
Si la condicin usa una desigualdad, Vensim primero verifica para ver si la

desigualdad es verdadera.
Si es verdadera, el valor de la variable no cambia.
Si no es verdadera, Vensim la hace verdadera asignando el valor tal como si fuera

una condicin de igualdad.
Dado que forz las condiciones para que fueran verdad, Vensim verifica si las
consecuencias tambin son verdaderas.
12
Verificaciones Passive Constraint
Si efecta la verificacin pasiva de una Constraint, Vensim simplemente evala ambas

mitades de la ecuacin Constraint como si fueran una expresin lgica. Si la consecuencia
es falsa mientras la condicin es verdadera, muestra un error. Siempre que se ejecute un
Reality Check, Vensim verifica la conformidad pasiva de todas las Constraints que no son
explcitamente activas . Esta verificacin no se hace durante las simulaciones normales.
13
Informe de errores
La violacin de Constraints se muestran de la misma manera que cuando se exceed una
tabla Lookup. La primera vez que se viola una Constraint se muestra un error. Luego se
enva un mensaje cuando la Constraint no es ms violada, indicando un retorno a la
conformidad. Se muestra la siguiente violacin, y as siguiendo.
14
Escribiendo las ecuaciones de Reality Check
Las ecuaciones de Reality Check se escriben de la misma manera que una ecuacin en un
modelo normal. En el Editor de Texto simplemente se escriben. En el Editor de Esquema,
se pueden ingresar en diagramas mostrando todos los elementos a ser verificados como
causas de los Test Inputs y Constraints. Los Test Inputs y Constraints no son parte de la
estructura causal del modelo. Adems, el lado derecho de las ecuaciones en Test Inputs no
se muestran como causas de la variable del Test Input. As la ecuacin:
Inventario = INTEG(produccin-despachos , INVENTARIO_INICIAL) ~~|
siempre hay stock :TEST INPUT: Inventario = 3*demanda final ~~|
llenar ordenes si hay stock :THE CONDITION: siempre hay stock
:IMPLIES: despachos >= demanda final ~~|
aparecer en el diagrama como:
INVENTARIO INICIAL
produccin
Inventario
despachos
siempre hay stock

demanda final
llenar ordenes si hay
stock
Es comn que se desee mantener las ecuaciones y la estructura causal usadas en la

definicin de Reality Check separadas de las ecuaciones normales del modelo. Una va
conveniente para hacerlo es ponerlas en grupos separadas e incluirlas en vistas separadas.
En el diagrama la mezcla de diferentes tipos de nombres puede ser confusa. Cuando se
buscan flechas entrando a llenar ordenes si hay stock , no es qu causas
determinan llenar ordenes si hay stock, sino qu necesitamos saber para determinar si es
verdad.
15
Dada la dificultad para entender los diagramas que slo muestran las relaciones causales y
los flujos, se desea omitir esta complejidad adicional al diagrama de trabajo. Es
probablemente ms fcil colocar las ecuaciones de Reality Check en vistas separadas as no
se las confunde con la estructura del modelo.
Tambin puede ser muy conveniente adoptar una convencin para nombrar las
proposiciones de Reality Check. Por ejemplo se puede empezar todos los Test Inputs con
TI y todas las Constraints con RC.
16
Editor de ecuaciones
Se escriben las ecuaciones de Reality Check igual que las otras ecuaciones. As, se crea una
variable, se abre el Editor de Ecuaciones, se selecciona el tipo Reality Check y el Subtipo
Constraint o Test Input y se escribe la ecuacin.
Cuando se selecciona el tipo Reality Check, se ver que la etiqueta Range cambia a
TypPrio (este aparece cerca del fondo, justo a la derecha de Group). Este es un mecanismo
para filtrar las proposiciones Reality Check en el dilogo Reality Check Control y ser
discutido a continuacin. Se puede entrar un nmero tanto para Type como Priority. Los
valores que puede tomar Priority son arbitrarios, pero 1-10 son prioridades comunes. Type
debera tomar un valor entero entre 0 y 64. Estos parmetros no estn disponibles en PLE o
PLE Plus.
17
Ejecutar Reality Check
La aplicacin Reality Check se ejecuta estableciendo primero una simulacin y luego

verificando las ecuaciones de Reality Check que fueron ingresadas.
Se puede comenzar un Reality Check desde la barra de Tareas o desde el dilogo
Simulation Control (ver Captulo 8 del Referente Manual para mayores detalles). Se
pueden hacer cambios y ajustar otras opciones del mismo modo que se hace en una
simulacin normal. Despus de haberlo hecho pulsar en Reality Check
Simulation Control o en el botn Reality Check de la barra de Tareas.
en el dilogo
NOTA: Cualquier cambio que se haya efectuado a los valores constants o datos a ser
usados previo a comenzar un Reality Check se mantendr a travs de toda la sesin.
Cuando se comienza un Reality Check, aparece el dilogo de Control:
Test type (no en PLE o PLE Plus) permite especificar que tipo de Reality Check se desea
ejecutar. Si est en blanco se verifican todos los tipos. El tipo de Reality Check se indica
en el campo TypPrio del Editor de Ecuaciones. En Text Editor Type, Priority se encierra
entre corchetes [ ] en el campo (~[type,priority]). Este campo slo es aplicable cuando se
usa el botn Test All para comenzar.
Priority >= (no en PLE o PLE Plus) restringir la verificacin a aquellas Constantes cuya
prioridad es mayor o igual a la especificada. Este campo slo es aplicable cuando se usa el
botn Test All para comenzar.
NOTA: Si las Constraints no tienen una prioridad especificada, son tratadas con la
mxima prioridad. Si no tienen un tipo especificado, se equiparan a todos los tipos. Para
mostrar un grfico de una variable que est siendo verificada en el segmento
Consecuencias contra el comportamiento que esa variable debe cumplirr, se usa Show
18
Graphs. Esto se hace usando una seleccin especial en Graph Tool y puede ser de mucha
ayuda para entender la manera en que ocurri una falla.
Always, si est tildada, genera un grfico para cada Constraint verificada.
Never, si est tildada, suprime la salida de un grfico.
Sim/Fail, si est tildada, produce la aparicin de un grfico siempre que falla una
Reality Check , y tambin cuando se hace una simulacin simple usando Sim Active o los
botones Highlighted .
On Fail, si est tildada, hace que el grfico solo aparezca si Reality Check fallas.
Cuando se usa el botn Test All es lo mismo que Sim/Fail. Para Sim Active y botones
Highlighted suprime el grfico a menos que realmente se produzca una falla.
Constraints es una lista de las Constraints que fueron ingresadas. Pulsando en una de ellas
resaltara los correspondientes Test Inputs. Se puede entonces activar uno o ms de estos
Test Inputs.
Test Inputs es una lista de los Test Inputs en los modelos. Esta lista incluye todo lo que se
ha definido explcitamente como Test Input, y todas las comparaciones en las expresiones
lgicas que constituyen los componentes condicionales de las ecuaciones Constraint . Las
comparaciones se muestran directamente y no es necesario dar un nombre.
>> mueve los items resaltados en la lista de Test Inputs a la lista Active Test Inputs .
<< borra los items resaltados en la lista Active Test Inputs .
Pulsar en un elemento de la lista lo resalta. Control-pulsar cambia el estado agregando o
borrando la seleccin de elementos resaltados. Pulsar dos veces mueve el elemento a la
lista Test Inputs .
Active Test Inputs muestra una lista de los Test Inputs, explcitos e implcitos, que estn
activos. Se usan si se pulsa el botn Simulate . Pulsar en un elemento lo resalta, y
desmarca cualquier otra cosa resaltada. Control-pulsar cambia el estado de un elemento
resaltado. Pulsar dos veces borra un elemento de la lista.
Clear All Active borra todos los elementos de la lista Active Test Inputs.
Sim Active simula el modelo usando los Test Inputs activos en la lista. Todas las otras
Constraints se verifican pasivamente. Si la simulacin se completa bien, los resultados son
almacenados como una simulacin normal, y pueden ser revisados con las herramientas de
trabajo. Se debe ser cuidadoso en observar que el seguimiento de causas no siempre da los
resultados esperados dado que la estructura del modelo ha sido modificada durante la
simulacin.
19
Highlighted simula el modelo usando el elemento que esta resaltado en la lista de

Constraint . Debido a la estructura lgica de la parte condicional de una Constraint, esta
realmente requiere ms que una simulacin. La simulacin ser almacenada igual que la
simulacin normal.
Test All verifica todas las Constraints en el modelo a un tiempo formando la coleccin de
Test Inputs necesaria para activar cada Constraint. Debido a la estructura lgica de la
parte condicional de una ecuacin Constraint, puede tomar ms de una simulacin verificar
una Constraint. Esta verificacin puede consumir tiempo; los errores se muestran en una
ventana separada. Ejecutar Test All no almacena ninguna simulacin, simplemente
muestra los resultados de Reality Check.
Close cierra el dilogo Reality Check Control.
20
La herramienta Reality Check

Se puede agregar la herramienta Reality Check al conjunto de herramientas de Anlisis, (
no applica en PLE o PLE Plus). Esta herramienta es un atajo para comentar Reality Check,
resaltando una Constraint y pulsando en Highlighted. La herramienta trabaja en la
Constraint que est seleccionada dentro del esquema de Trabajo. Si la variable de trabajo
no es una Constraint se muestra un mensaje de error.
21
Resultados de un Reality Check

Los resultados de un Reality Check se muestran en una ventana de texto. La ventana
muestra que Constraints fueron verificadas y si alguna Constraint fue violada. Se abre una
nueva ventana cada vez que se pulsa en Sim Active, Highlighted o Test All. A
continacin se dan ejemplos.
Aparecen uno o ms grficos. Estos grficos tienen por objeto mostrar el segmento de
consecuencias de una Constraint:
Aqu la lnea azul muestra lo que hace despachos, mientras la lnea roja muestra a que
est siendo comparado.
22
Repasar los resultados de una Simulation

Cada vez que se pulsa en Sim Active o Highlighted se efecta una nueva simulacin. Esta
simulacin recibe el nombre especificada en el recuadro Runname (en la barra de
Herramientas o en el dilogo Simulation Control). Se puede, mientras est abierto el
Control de Reality Check, mirar los resultados de una simulacin tal como se hara con
cualquier otra simulacin. Se puede entonces hacer otra simulacin y revisar estos
resultados. Si se desea comparar dos simulaciones Reality Check, se puede cerrar el Reality
Check control y luego comenzar de nuevo poniendo un nombre diferente en el recuadro
Runname.
NOTA: Si se cambian las constantes en el dilogo Simulation Control o en la pantalla
usando Set Up a Simulation de la barra de tareas, esos cambios se conservarn durante la
sesin de Reality Check.
23
Reality Check y el crecimiento de las levaduras

Para demostrar los mecanismos para escribir y usar las ecuaciones de Reality Check, es til
hacerlo a travs de un ejemplo muy simple. Se desea modelar el crecimiento de levadura en
un recipiente con agua. El agua se mantiene a temperatura constante que se puede fijar, y
tiene una cantidad fija de azcar al comienzo.
Primero se listar algunas de las ecuaciones de Reality Check que se deben cumplir:
Si la temperatura baja de 50 grados, el crecimiento de levadura debera detenerse,

y la levadura queda latente.
Si la temperatura supera los 100 grados la levadura muere.
Si no hay azcar y las levaduras no estn latentes, mueren.
Si no hay agua y las levaduras no estn latentes, mueren.
Si la levadura contina creciendo, consumir todo el azcar.
Si la levadura continua creciendo, consumir todo el agua.
La otra cosa que sabemos es que las levaduras se reproducen por divisin y cuando las
condiciones son adecuadas se pueden reproducir con un tiempo de duplicacin de
aproximadamente 10 minutos.
24
Ecuaciones de Test Input y Constraint
Comenzaremos el proceso de modelado definiendo las variables que necesitamos para

efectuar los Reality Check y luego entrando las ecuaciones correspondientes. Las
ecuaciones de Reality Check que fueron comentadas hablan acerca de cantidad de levadura,
cantidad de agua, cantidad de azcar, el nmero de divisiones de la levadura y la
temperatura. Identificando los niveles, se ubican en el esquema del modelo de la siguiente
manera.
Azcar
Agua
divisiones
Cantidad de
levadura
muertes
vida promedio
tasa de division
temperatura
Por claridad, se desea construir las ecuaciones de Reality Check en una segunda vista. Si se
est usando Vensim PLE necesitar ubicarlas en la misma vista que la estructura del
modelo. La primera etapa es ubicar todos los elementos del modelo como variables
shadow. El uso de este tipo de variables permite que la estructura del modelo cambie sin
requerir modificaciones del diagrama de Reality Check.
<divisiones>
gran crecimiento
hambre por crecimiento
<Azcar>
<INITIAL
TIME>
<Agua>
<Cantidad de levadura>
<temperatura>
sed por crecimiento

come o muere
frio adormece
calor es mortal
bebe o muere
No hay reglas fijas para estructura los diagramas de Reality Check. La experiencia muestra
que hacer una columna para las variables normales, Test Inputs y Constraints es la manera
ms fcil. Puede ser til un cdigo de colores (por ejemplo azul para Test Inputs y rojo por
Constraints). Las flechas pueden quedar un poco desordenadas de esta forma, pero si se
organiza la informacin para Reality Check por las variables que son afectadas, no es
normalmente un gran problema. Se pueden ingresar las Constraints y Test Inputs en el
Editor de Ecuaciones:
25
Se necesitar seleccionar Type Reality Check y subtype Constraint. Las condiciones y

consecuencias se dividen en dos ventanas separadas.
Las ecuaciones de Reality Check son:
frio adormece :THE CONDITION: temperatura < 50 :IMPLIES:
divisiones = 0
calor es mortal :THE CONDITION: temperatura = RC STEP(120,1)
:IMPLIES: Cantidad de levadura <= RC DECAY CHECK(1,Cantidad de
levadura,2)
Para calor es mortal hemos usado un escaln en la temperatura y luego se uso
una funcin RC DECAY CHECK para verificar la Cantidad de levadura. Para este
modelo es adecuada una cada para mirar el comportamiento de Cantidad de
levadura puesto que estamos focalizando en la situacin de muerte.
come o muere :THE CONDITION: azcar = RC STEP(azucar,0)
:AND: temperatura > 65 :IMPLIES: Cantidad de levadura <= RC DECAY
26
CHECK(1,Cantidad de levadura,15)
Aqui la Constraint require que la Cantidad de levadura decline hacia cero con un tiempo
promedio de muerte de 15.
Bebe o muere :THE CONDITION: Agua = RC STEP(Agua,0)
:AND: temperatura > 65 :IMPLIES: Cantidad de levadura <= RC DECAY
gran crecimiento :TEST INPUT: divisiones = 1e+022
hambre por crecimiento :THE CONDITION: gran crecimiento :IMPLIES
:azcar <= RC DECAY CHECK (1,azcar,0.5,INITIAL TIME)
sed por crecimiento :THE CONDITION: gran crecimiento :IMPLIES:
Agua <= RC DECAY CHECK(1,Agua,0.5,INITIAL TIME)
Notar que para las dos ltimas Constraints la funcin RC DECAY CHECK comienza
verificando a INITIAL TIME ya que el Test Input comienza desde el inicio de la
simulacin. Si el Test Input ha usado una funcin RC STEP para comenzar durante la
simulacin, el argumento INITIAL TIME puede obviarse en los dos ltimos RC DECAY
CHECK .
Finalmente se tiene:
RC START TIME = 10
El tiempo es arbitrario. Podra ocurrir que comenzando temprano hubiera unas pocas
levaduras y cantidades de azcar, mientras que empezando ms tarde habra ms levaduras
y menos azcar. Cuando un modelo pasa el Reality Check es una buena idea cambiar RC
START TIME y reverificar.
27
Un modelo inicial
Hay una breve lista de cosas que sern necesarias en el modelo para hacer posible la
utilizacin de las ecuaciones de Reality Check. Contando con una comprensin muy bsica
del crecimiento exponencial, se puede llenar el esquema ya preparado para construir un
modelo. Se comienza con el ms simple de los modelos (levadura1_guia.mdl)
Azcar
Agua
divisiones
Cantidad de
levadura
muertes
vida promedio
tasa de division
temperatura
Agua =
100
Units: ml
La cantidad de agua en el recipiente
Azcar =100
Units: g
La cantidad de azcar en el recipiente.
bebe o muere:THE CONDITION:Agua = RC STEP(Agua,0) :AND:
temperatura > 65:IMPLIES: Cantidad de levadura <= RC DECAY
Units: **undefined**
calor
es
mortal:THE
CONDITION:temperatura
=
RC
STEP(120,1):IMPLIES: Cantidad de levadura <= RC DECAY CHECK
(1,Cantidad de levadura,2)
Cantidad de levadura= INTEG ( divisiones-muertes, 100)
Units: Celulas
El nmero de levaduras.
come o muere:THE CONDITION:Azcar = RC STEP(Azcar,0) :AND:
temperatura > 65:IMPLIES:Cantidad de levadura
<= RC DECAY CHECK(1,Cantidad de levadura,15)
divisiones = Cantidad de levadura*tasa de division
Units: Celulas/Minuto
28
FINAL TIME = 300

Units: Minute
frio adormece:THE CONDITION:temperatura < 50:IMPLIES:
divisiones = 0
gran crecimiento:TEST INPUT:divisiones = 1e+022
hambre por crecimiento:THE CONDITION:
gran
crecimiento:IMPLIES:Azcar
(1,Azcar,0.5,INITIAL TIME)
<=
RCDECAY
CHECK
INITIAL TIME = 0
Units: Minute
The initial time for the simulation.
Muertes = Cantidad de levadura/vida promedio
Units: Celulas/Minuto
La velocidad de muerte de levaduras.
RC START TIME = 10
Units: Minute
SAVEPER = 1
Units: Minute
La frecuencia a la cual se almacenan los datos de salida.
sed
por
crecimiento:THE
CONDITION:
gran
crecimiento:IMPLIES:Agua <= RC DECAY CHECK(1,Agua,0.5,INITIAL
TIME)
tasa de division = 0.08
Units: 1/Minuto
La tasa de division de las levaduras.
Temperature = 85
Units: grados farenheit
La temperatura del agua en el recipiente.
TIME STEP = 1
Units: Minute
El intervalo de simulacin.
29
vida promedio = 250

Units: Minuto
El tiempo promedio que una levadura sobrevive.
En este modelo no estamos hacienda uso de Azcar, Agua o temperatura, los
cuales se han fijado a constantes utilizando el recuadro descolgable Type del editor de
ecuaciones.
A continuacin, se ejecuta el Reality Check de este modelo. Pulsar en el botn Reality
Check de la barra de herramientas, o abrir el dilogo Simulation Control y pulsar en el
botn Reality Check.
En el dilogo de control de Reality Check se ve una lista de Constraints para el modelo.

Debajo de sta est la lista de Test Inputs. Uno, gran crecimiento, fue explcitamente
nombrado, mientras los otros son simplemente derivados de la parte condicional de las
diferentes Constraints.
Pulsando en Test All comienza una serie de simulaciones. Se muestran las siguientes
violaciones:
30
El informe resumido es:

Starting testing of Constraint- fro adormece
Test inputs :
temperatura<50
Starting to test the constraint fro adormece

The constraint fro adormece- violated at time 0
-------------The constraint bebe o muere- violated at time 11
-------------The constraint come o muere- violated at time 11
-------------The constraint calor es mortal- violated at time 11
-------------The constraint hambre por crecimiento- violated at time 1
-------------The constraint sed por crecimiento- violated at time 1
-------------Todas las Constraints han sido violadas. No es una gran sorpresa ya que los elementos
involucrados en las Constraints no fueron conectados en el modelo. Este modelo slo
representa un mecanismo bsico de crecimiento. No se ha dado atencin al control o
contencin a las cuales estn relacionadas las Constraints. Adicionalmente a la ventana de
error habr 6 grficos tales como:
31
frio adormece
40 B
30 B
20 B
10 B
0
0
30
60
90
120
150 180
Time (Minute)
"divisiones"=
210
240
270
300
La lnea superior muestra lo que hacen las divisiones, mientras que la lnea inferior muestra
a que se debe.
La ventana de reporte finalice con un sumario de lo que ha pasado.
*****************
0 successes and 6 failures testing 6 Reality Check equations
The Reality Check Index as run is 0
Closeness score is 0.0% on 6 measurements
La primera lnea es un resumen estadstico. La segunda lnea muestra el Reality Check

Index. Este se define como el nmero de xitos dividido por el producto del nmero de
variables dinmicas en el modelo con el total de variables en el modelo. Dado que por cada
par de variables hay un potencial de uno o ms ecuaciones Reality Check este ndice es
algo que debera estar siempre presente para un modelo con un conjunto completo de
Reality Checks. Finalmente se muestra un grado de robustez (closeness score). Este grado
es un promedio de la robustez del Reality Check. Si un Reality Check tiene xito, este
grado es 1. Si falla es 1 menos el promedio del error absoluto promedio dividido por la
cantidad de variacin en la variable que est siendo verificada. Por lo tanto un Reality
Check que slo falla poco tiene un grado cercano a 1, por lo que Closeness score es una
medida continua cuanto, en promedio, son violadas las Constraints.
32
Temperatura, divisiones y muertes

Dos condiciones relacionan la temperatura al crecimiento. Si la temperatura es baja todo
pasa a estado de latencia. Si la temperatura es alta las levaduras mueren. Se reemplazan las
ecuaciones para divisiones y muerte con este concepto en mente, y se crea
Levadura2_guia.mdl
Azcar
Agua
division con temp lookup
Cantidad de
levadura
divisiones
muertes
vida promedio
tasa de divisin
temperatura
tasa de division normal

temperatura normal
vida normal
vida con temp lookup
divisiones = Cantidad de levadura * tasa de division

division rate = tasa de division normal * division con temp
lookup ( temperature / norm temperature )
tasa de division normal = 0.08
temperatura normal = 80
division con temp lookup ( (0,0),(0.8,0),(1,1),(2,1) )
muertes = Cantidad de levadura / vida promedio
vida promedio = vida normal * vida con lookup ( temperatura /
temperature normal )
vida normal = 250
vida con temp lookup ((0,1),(1,1),(1.25,0.02),(2,0.001) )
Ahora verificar las Constraints mostrar es respetada. Las Constraints son violadas porque
las levaduras no se mueren lo suficientemente rpido cuando la temperatura se incrementa.
En este caso, se puede reestructurar el modelo para alcanzar la Constraint, o suavizar
levemente la Constraint, dependiendo en que es ms realista. Una manera de aliviar la
restriccin es cambiar el tiempo de transicin para permitir ms tiempo para la muerte de
las levaduras (se cambia el argumento RC DECAY CHECK de 2 a 5):
Calor es mortal :THE CONDITION: temperatura = RC STEP(120,1)
:IMPLIES: Cantidad de levadura <= RC DECAY CHECK(1,Cantidad de
levadura,5)
Ahora verificar las Constraints mostrar que fro adormece y calor es mortal son ambas
respetadas. Este tipo de interaccin, pactando la rigurosidad de las Constraints y haciendo
ajustes a las ecuaciones es vlido. Proporciona un medio de focalizar la atencin sobre las
Constraints que pueden ser violadas.
33
Influencia del Agua y el Azcar en las Divisiones

Las dos siguientes ecuaciones Constraint establecen que el agua y el azcar son necesarios
para sobrevivir. Se model el impacto de falta de agua y azcar tanto en la tasa de
divisin como la vida promedio de las levaduras. El nuevo modelo
(levadura3_guia.mdl) se ve:
divisiones con azcar lookup

divisiones con temp lookup
divisiones con agua lookup
Azcar

Azcar promedio
Cantidad de
levadura
tasa de division
divisiones
vida con agua lookup

vida con azcar lookup
vida normal
vida promedio
muertes
Agua promedio
Agua
temperatura
temperatura normal
agua normal
azcar normal
Las ecuaciones estn disponibles con el modelo. Observar que los Test Inputs elegidos
causan condiciones extremas para la existencia en Agua y Azcar, y la forma en que el
modelo est formulado hace que las muertes crezcan explosivamente. Usando integracin
por Euler, el sistema muestra oscilaciones con la Cantidad de Levadura hacindose
negativa. Para evitar esto puede usarse otras tcnicas de integracin, o cambiar las
ecuaciones para muertes.
muertes = MIN(Cantidad
levadura/vida promedio)
de
levadura/TIME
STEP, Cantidad
de
Esta formulacin evita dinmicas no esperadas, pero tambin pueden fijar la Cantidad
de levadura en cero. Esto significa que Azcar promedio y Agua promedio
necesitan ser computadas como:
Azcar promedio = ZIDZ(Azcar, Cantidad de levadura)
Agua promedio = ZIDZ(Agua, Cantidad de levadura)
Para prevenir errores numricos cuando Cantidad de levadura es 0.
Con la estructura cambiada, el modelo supera con xito cuatro de las seis Constraints.
34
Agua y Azcar influenciadas por las Divisiones

An no se logr ajustar el modelo a las dos ltimas Constraints. El problema es que no
hemos hecho la conexin entre lo que las levaduras estn haciendo y cuanta agua y azcar
hay. La manera ms simple de hacerlo es considerar el proceso de divisin como un
consumidor de recursos de agua y azcar. As tenemos el modelo levadura4_guia.mdl
azcar por division
divisiones con azcar lookup
divisiones con temp lookup
divisiones con agua lookup
Azcar
Consumo de azcar

Azcar promedio
tasa de division
divisiones
agua por division
Cantidad de
levadura
vida con agua lookup

vida con azcar lookup
vida normal
vida promedio
muertes
agua promedio
Agua
consumo de agua
temperatura
temperatura normal
agua normal
azcar normal
Este modelo cumple todas las Constraints que se escribieron. Pero, es un buen modelo?
En este caso la respuesta probablemente es no todava. Para una representacin detallada
y segura del crecimiento de las levaduras necesitaramos algunos datos experimentales, y
calibrar el modelo para efectos de temperatura y falta de recursos. El punto es que este
modelo no viola las Reality Checks mas obvias que surgen del sentido comn. Se han
mostrado varios modelos diferentes. Qu pas con las ecuaciones Reality Check?
Excepto por los pequeos cambios efectuados a calor es mortal, no hay cambios y
tienen exactamente el mismo diagrama.
Conclusin
El uso de Reality Check sirve a dos propsitos. Primero, es un registro escrito de aspectos
que asumimos deben ser verdaderos para que el modelo tenga sentido. Estos aspectos
quedan normalmente sin documentar, an cuando debieran ser el producto ms importante
del ejercicio de modelado. Cuestiones muy simples, como la nocin de que si la levadura se
mantiene en crecimiento podra quedarse sin agua, son muy importantes para entender el
sistema.
35
Recursos de Vensim en espaol

http://dinamica-de-sistemas.com
CURSOS ONLINE
Universitat Politcnica de Catalunya

http://www.dinamica-de-sistemas.com/cursos/sis.htm
ATC-Innova. Distribuidor Oficial Vensim

http://atc-innova.com/
LIBROS
Teora y ejercicios prcticos de Dinmica de Sistemas

http://www.dinamica-de-sistemas.com/libros/sistemas.htm
Sysware, la toma de decisiones en un mundo complejo

http://www.dinamica-de-sistemas.com/libros/sysware.htm
Ejercicios avanzados en Dinmica de Sistemas

http://www.dinamica-de-sistemas.com/libros/ca_sistemas.htm
Informacin: info@atc-innova.com
36

Simulacion en Vensim

Cargado por

Copyright:

Formatos disponibles

Simulacion en Vensim

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Simulacion en Vensim

Cargado por

Copyright:

Formatos disponibles

GUIA DE USUARIO VENSIM

Introduce el concepto de un Reality Check.

Muestra como crear Constraints (Restricciones) y Test Inputs (Entradas de prueba)

Muestra como controlar la coherencia de un modelo con las ecuaciones de Reality

Muestra como construir un modelo usando Reality Check.

Copyright 1998-2007 Ventana Systems, Inc.

Gua del Usuario de Vensim

Los modelos y la realidad

Los modelos son representaciones de la realidad, o bien percepciones personales de la

Gua del Usuario de Vensim

Gua del Usuario de Vensim

Definir las ecuaciones de Reality Check

Gua del Usuario de Vensim

Test Inputs dinmicos

Gua del Usuario de Vensim

Gua del Usuario de Vensim

Gua del Usuario de Vensim

Gua del Usuario de Vensim

Inventario > :AT LEAST ONCE: RC STEP CHECK(0,Inventario,1)

Condiciones vacas (Empty Conditions)

Wildcard Tests (comodines) en las Consecuencias

Gua del Usuario de Vensim

Simulacin y Reality Check

Antes de comentar la mecnica de ejecutar ecuaciones de Reality Check, es usual describir

Gua del Usuario de Vensim

Verificaciones Active Constraint

Si la condicin es una igualdad o un Test Input, Vensim agrega la ecuacin a la

Si la condicin usa una desigualdad, Vensim primero verifica para ver si la

Si es verdadera, el valor de la variable no cambia.

Si no es verdadera, Vensim la hace verdadera asignando el valor tal como si fuera

Gua del Usuario de Vensim

Verificaciones Passive Constraint

Si efecta la verificacin pasiva de una Constraint, Vensim simplemente evala ambas

Gua del Usuario de Vensim

Gua del Usuario de Vensim

Escribiendo las ecuaciones de Reality Check

siempre hay stock

Es comn que se desee mantener las ecuaciones y la estructura causal usadas en la

Gua del Usuario de Vensim

Gua del Usuario de Vensim

Gua del Usuario de Vensim

Ejecutar Reality Check

La aplicacin Reality Check se ejecuta estableciendo primero una simulacin y luego

Always, si est tildada, genera un grfico para cada Constraint verificada.

Never, si est tildada, suprime la salida de un grfico.

Gua del Usuario de Vensim

Highlighted simula el modelo usando el elemento que esta resaltado en la lista de

Gua del Usuario de Vensim

La herramienta Reality Check

Gua del Usuario de Vensim

Resultados de un Reality Check

Gua del Usuario de Vensim

Repasar los resultados de una Simulation

Gua del Usuario de Vensim

Reality Check y el crecimiento de las levaduras

Si la temperatura baja de 50 grados, el crecimiento de levadura debera detenerse,

Si la temperatura supera los 100 grados la levadura muere.

Si no hay azcar y las levaduras no estn latentes, mueren.

Si no hay agua y las levaduras no estn latentes, mueren.