7 El Modelo Predador Presa

7.1 Descripcion del Modelo

Introducción

Este taller tiene la intención de llevarlo desde el primer paso de diseñar una pregunta (hipótesis) de un área que se desea explorar, a través del diseño y la construcción del modelo y finalmente a refinar la pregunta revisar el modelo y analizar estadísticamente el modelo para responder a la pregunta (hipótesis).
Esta secuencia se presenta en este documento en orden lineal, pero en realidad estos pasos se entremezclan entre sí y forman parte de una exploración iterativa de refinamiento del modelo y de la pregunta (hipótesis) motivadora inicial. Trabajaremos todo lo anterior dentro del contexto de un modelo particular, pero al mismo tiempo discutiremos cuestiones generales relacionadas con el diseño y construcción de modelos. Para facilitar el proceso, este taller está dividido en tres secciones principales:

• El diseño : que lo llevará a través del proceso de determinar qué elementos incluir en su modelo.
• La construcción : le mostrará cómo tomar un modelo conceptual y crear un objeto computacional
• El análisis: se ocupará de cómo ejecutar su modelo, crear algunos resultados y analizar esos resultados para proporcionar una respuesta a su pregunta inicial.

Pregunta Básica

A lo largo de este taller estaremos diseñando, construyendo y examinando un modelo simple de un sistema ecológico. La pregunta básica que vamos a abordar es:

“¿Cómo los niveles de población de dos especies animales que comparten un hábitat cambian con el tiempo?”

Llamaremos a este modelo el modelo Predador-Presa. Aunque discutiremos este modelo en el contexto de dos especies biológicas, el modelo podría ser generalizado a otras situaciones como empresas que compiten por los consumidores, partidos políticos que compiten por los votos, o virus que evolucionan en un sistema informático. Más importante aún, los conceptos y componentes que vamos a desarrollar en este modelo son fundamentales y de hecho son utilizados en la mayoría de los modelos basados en agentes (ABM)

Diseñando el Modelo

Hay muchas maneras de diseñar un modelo basado en agentes. La que se elija depende de muchos factores incluyendo el tipo de fenómeno a ser modelado, el nivel de conocimiento del dominio de contenido, su comodidad con la codificación y su personal estilo de modelado. Consideramos dos grandes categorías de modelos:

* Modelación basada en el fenómeno 
*  Modelación exploratoria. 

En la modelación basada en el fenómeno, se comienza con un fenómeno conocido que tiene un comportamiento característico. Algunos ejemplos podrían incluir patrones comunes de segregación de vivienda en las ciudades, galaxias en forma de espiral en el espacio, patrones de disposición de las hojas en las plantas, o niveles oscilantes de población en especies que interactúan. El objetivo de la modelación basada en el fenómeno es crear un modelo que capture de alguna manera el comportamiento. En ABM, esto se traduce a encontrar un conjunto de agentes, y reglas para esos agentes, que lo generan. Una vez constituido el modelo , se tiene un mecanismo para explorar el comportamiento. Variando los parámetros del modelo , se puede observar si emergen otros patrones o comportamientos encontrando esos nuevos patrones en un conjunto específico de valores de los parámetros del modelo o realizando experimentos con los datos.

La segunda categoría es la modelación exploratoria, en esta categoría la idea es crear un conjunto de agentes, definir su comportamiento y explorar los patrones o comportamientos que emergen. Pero para que tenga sentido este tipo de modelado, debemos encontrar similitudes de nuestro modelo con algunos fenómenos en el mundo. A continuación, refinamos nuestro modelo con destino a las similitudes percibidas con estos fenómenos y de esa manera llegamos a converger hacia un modelo explicativo del fenómeno.

Una distinción importnate entre ambas metodologías es hasta qué punto especificamos una pregunta a ser contestada por un modelo. En un extremo del espectro (Modelación basada en el fenómeno) , formulamos una investigación específica, pregunta (o conjunto de preguntas) como:

“¿Cómo una colonia de hormigas hace para buscar alimentación?”¿Cómo una bandada de estroninos hace para volar en forma de V? "

En el otro extremo (Modelación exploratoria) simplemente comenzamos con una noción básica de querer modelar hormigas o comportamiento de aves, pero sin una pregunta clara a ser contestada. A medida que exploramos a través del modelo, gradualmente vamos refinando nuestra pregunta hacia una que pueda ser abordado por un modelo específico.

Sin embargo, una tercera dimensión tiene que ver con el el grado en que el proceso de diseño del Modelo se combina con la codificación del modelo. En algunos casos, es aconsejable realizar todo el diseño del modelo conceptual antes de cualquier codificación del modelo. Esto es la metodología de arriba hacia abajo (top-down), el diseñador del modelo decide los tipos de agentes del modelo, el entorno en el que residen y sus reglas de interacción antes de escribir una sola línea de código. En otros casos, el diseño del modelo conceptual y la codificación del modelo co-evolucionan, influyendo cada uno en la evolución del otro. Esto es a menudo referido como diseño de abajo hacia arriba.(bottom-up) . En el diseño de abajo hacia arriba, se selecciona un dominio o fenómeno de interés con o sin especificar una pregunta formal, Utilizando este enfoque, se comenzaría a escribir el código relevante a ese dominio, construyendo el modelo conceptual de abajo para arriba, acumulando los mecanismos, las características y las entidades necesarias, y quizás formulando algunas preguntas formales de la investigación a lo largo del camino. Por ejemplo, en un diseño de abajo hacia arriba, puede comenzar con una pregunta sobre cómo evolucionaría un mercado económico,se podrían codificar comportamientos de algunos compradores y vendedores y, al hacerlo, darse cuenta de que se tendrían que agregar corredores como agentes en el modelo.

Estas dimensiones de diseño del modelo se pueden combinar . Usted podría comenzar con una pregunta de investigación muy específica y diseñar todos los agentes y reglas antes de codificar, o puede comenzar con algunos agentes, jugar con varias reglas para ellos y sólo obtener su pregunta de modelado cerca del final del proceso. En la práctica, los autores de modelos rara vez usan exclusivamente un estilo al construir sus modelos, pero usan una combinación de estilos, y a menudo cambian entre formas y estilos a medida que cambian sus necesidades e intereses de investigación. En los casos en que un investigador está colaborando con un programador que codifique el modelo, el estilo de diseño de arriba hacia abajo es normalmente el que se emplea, ya que separa los roles de los dos miembros del equipo. NetLogo fue diseñado para facilitar a los científicos la codificación de sus propios modelos. A menudo, a medida que los constructores de modelos se sienten más cómodos con la codificación, usan el código NetLogo como una herramienta para construir el modelo conceptual, presentaremos nuestro modelo de construcción utilizando una mezcla de enfoques, pero para mayor claridad de la exposición, haremos hincapié en el enfoque de arriba hacia abajo. El proceso de diseño de arriba hacia abajo comienza eligiendo un fenómeno o situación que desea modelar o proponiendo una pregunta que quiera responder, y luego diseñar agentes y reglas de comportamiento que modelan los elementos de la situación. A continuación, se refina ese modelo conceptual y se revisar hasta que esté en un nivel de detalle lo suficientemente adecuado para que se puede comanzar a escribir el código para el modelo. A lo largo del proceso de diseño hay un principio muy importante que usaremos. Llamamos a este el principio de diseño de ABM:

Comienza simple y construye hacia la pregunta que deseas contestar

Hay dos componentes principales de este principio. La primera es comenzar con el conjunto más simple de agentes y reglas de comportamiento que pueden usarse para explorar el sistema que se desea modelar. Esta parte del principio se ilustra con una cita de Albert Einstein:

“El objetivo supremo de toda teoría es hacer que los elementos básicos irreductibles sean tan simples y pocos como sea posible sin tener que dejar de representar adecuadamente ningún dato de experiencia” (1933),

O en otra frase que se dice que también dijo:

“Todo debe ser lo más simple posible, pero no más simple.”

En el caso de ABM, esto significa hacer el modelo tan simple como sea posible dado que debe proporcionarle un escalón hacia su destino final. El estadístico George Box proporciona una cita que ilustra este punto:

“Todos los Modelos son incorrectos, pero algunos modelos son útiles”(1979).

Lo que quería decir Box era que todos los modelos son por necesidad incompletos porque simplifican aspectos del mundo. Sin embargo, algunos de ellos son útiles porque están diseñados para responder a preguntas particulares y las simplificaciones en el modelo no interfieren con la obtención de esa respuesta. Este principio básico de diseño ABM es útil de varias maneras. En primer lugar, nos obliga a examinar cada agente y cada regla y eliminar elementos si el progreso se puede hacer sin ella. No es raro que los modeladores principiantes construyan un modelo en el que ciertos componentes no tengan ningún efecto. Al comenzar simple y lentamente agregar elementos a su modelo, puede asegurarse de que estos componentes extraños nunca se desarrollan. Al examinar la necesidad de cada componente adicional con respecto a la pregunta que se está persiguiendo, se reduce la tentación de, parafraseando a Guillermo de Occam, “multiplicar las entidades innecesariamente”Al hacerlo, se reduce la posibilidad de introducir ambigüedades, redundancias e inconsistencias en el modelo. Otra virtud del principio de diseño es que, al mantener el modelo simple, lo hace más comprensible y más fácil de verificar. La verificación es el proceso de asegurar que un modelo computacional implemente fielmente su modelo conceptual objetivo. Un modelo conceptual más simple conduce a una implementación más sencilla del modelo, lo que facilita la verificación del modelo. En cada punto del proceso de desarrollo del modelo, el modelo debe ser capaz de proporcionarle algunas respuestas a su pregunta de investigación. Esto no solo le ayuda a hacer un uso productivo de su modelo desde el principio, sino que también le permite empezar a cuestionar las suposiciones de modelo y examinar sus resultados desde el principio en el proceso de modelado. Esto puede evitar que usted vaya demasiado lejos por un camino improductivo. Menos componentes también significan menos combinaciones para “validar”.

Predador-Presa

Para aplicar nuestro principio al contexto del modelo Predador-Presa , debemos comenzar nuestro diseño reflexionando sobre dos especies animales que comparten un hábitat e identificando agentes y comportamientos simples para nuestro modelo. Comenzaremos identificando una pregunta que queremos explorar, Después de eso vamos a discutir que agentes debemos definir y cómo pueden interactuar. Luego nos trasladamos al medio ambiente y a sus características. Como parte de este proceso, necesitamos discutir lo que sucede con el modelo a lo largo del tiempo. Finalmente, discutimos qué medidas vamos a utilizar para responder a nuestra pregunta.

Comencemos reflexionando sobre dos especies animales que comparten un hábitat e identificando agentes y comportamientos simples para nuestro modelo. Comenzaremos identificando una pregunta que queremos explorar, Después de eso vamos a discutir que agentes debemos definir y cómo pueden interactuar. Luego nos trasladamos al medio ambiente y a sus características. Como parte de este proceso, necesitamos discutir lo que sucede con el modelo a lo largo del tiempo. Finalmente, discutimos qué medidas vamos a utilizar para responder a nuestra pregunta

** Encontrando las preguntas

La elección de una pregunta puede parecer una cuestión aparte del diseño del modelo. Después de todo, la progresión natural parece ser: primero escoja una pregunta y construya un modelo para responder a esa pregunta. A veces, ese puede ser el procedimiento que seguimos, pero en muchos casos tendremos que refinar nuestras preguntas cuando comencemos a pensar en ello de una manera basada en agentes. Nuestra pregunta original para el modelo Lobos-Ovejas puede ser:

“¿Cómo cambian los niveles de población de dos especies con el tiempo cuando coexisten en un hábitat compartido?”

Ahora vamos a evaluar si esta pregunta es una que es susceptible para usar ABM y en caso afirmativo tendremos que refinar nuestra pregunta dentro del paradigma ABM. El modelado basado en agentes es particularmente útil para dar sentido a los sistemas que tienen un número de entidades que interactúan, y por lo tanto tienen resultados impredecibles. Hay ciertos problemas y preguntas que son más susceptibles a las soluciones ABM. Si nuestra pregunta principal de interés viola nuestras directrices, puede ser una indicación de que debemos considerar un método de modelado diferente. Por ejemplo, podríamos estar interesados en examinar la dinámica de dos poblaciones muy grandes bajo el supuesto de que las especies son homogéneas y bien mezcladas (sin componentes espaciales o propiedades heterogéneas) y que el nivel de población de cada especie depende simplemente del nivel de población de las otras especies. Si este es el caso entonces podríamos haber usado un modelo basado en ecuaciones en lugar de un modelo basado en agentes ya que el trabajo de EBM (Modelos basados en ecuaciones ) es bueno para grupos homogéneos grandes y existe un EBM clásico para esta situación conocida como as ecuaciones diferenciales de Lotka-Volterra (Lotka, 1925, Volterra, 1926) ABM será más útil para nosotros si pensamos en los agentes como heterogéneos y con ubicaciones espaciales. Un aspecto de los animales que es probable que sea relevante para nuestra pregunta es cómo hacen uso de sus recursos. Los animales hacen uso de los recursos al convertirlos en energía, por lo que queremos asegurarnos de que nuestros agentes tienen diferentes cantidades de energía y ocupan diferentes lugares en el mundo. Una tercera directriz es considerar si los resultados “agregados” dependen de las interacciones de los agentes y de la interacción de los agentes con su entorno. Por ejemplo, si una especie está consumiendo otra, entonces los resultados dependerán de la interacción del agente. Las interacciones predador-presa suelen establecerse en ambientes abundantes. Manteniendo el principio de diseño ABM en mente, comenzamos con el ambiente más simple:

Enriquecemos el ambiente un poco más allá de los depredadores y las presas e incluyendo los recursos del medio ambiente que consumen las especies de presa de nivel más bajo. Otra directriz es que el modelado basado en agentes es más útil para modelar procesos dependientes del tiempo. En el modelo Predador-Presa, nuestro interés central radica en examinar cómo los niveles de población cambian con el tiempo. Por lo tanto, podemos refinar nuestra pregunta para centrarnos en las condiciones que conducen a las dos especies a coexistir durante algún tiempo. De esta forma, nuestras pautas nos ayudan a evaluar si nuestra pregunta es adecuada para ABM y, en caso afirmativo, enfocar nuestra pregunta y nuestro modelo conceptual. Habiendo evaluado la relevancia de nuestra pregunta para ABM, estamos ahora en posición de decirlo más formalmente:

** “¿Podemos encontrar parámetros del modelo para dos especies tal que sostengan niveles de población positivos en un área geográfica limitada cuando una especie es un depredador del otro y la segunda especie consume recursos del medio ambiente?”**

Ahora, teniendo en cuenta esta pregunta, procederemos a diseñar el modelo conceptual.

7.2 Diseño del Modelo

Concretando el Modelo

Ahora que hemos identificado nuestra pregunta de investigación en detalle, puede ser útil considerar un contexto particular para esta pregunta de investigación.
Anteriormente, discutimos los patrones de referencia como una fuente de modelos basados en fenómenos A veces ese patrón de referencia es la inspiración original para el modelo. Otras veces, como ahora, hemos refinado nuestra pregunta de investigación lo suficiente como para buscar un patrón de referencia que nos ayude a probar si nuestro modelo es una respuesta válida a la pregunta. En el caso de las relaciones depredador-presa, hay un caso famoso de cohabitación de pequeñas poblaciones de depredadores-presas en un área geográfica pequeña. Este es el caso de poblaciones fluctuantes de lobos y alces en Isle Royale, Michigan.

La figura muestra las poblaciones de lobos y alces en la Isla Royale desde 1959 hasta 2009. Esta gráfica puede servir como patrón de referencia para nuestro modelo. Nuestro modelo ya completado deberá ser capaz de generar un gráfico “similar” como posible comportamiento del Modelo.
Como podemos ver en los datos de la Isla Royale, las poblaciones de lobos y alces de la Isla Royale se han mantenido durante más de cincuenta años sin que ninguna de las especies se extinga. Las poblaciones también exhiben una oscilación, con el alce en un punto bajo cuando los lobos están en altos y viceversa. Estos datos pueden servir como patrón de referencia para nuestro modelado y nos permite refinar aún más nuestra pregunta de investigación:

“¿Podemos encontrar parámetros de modelo para dos especies que sostengan los niveles poblacionales positivos oscilantes en un área geográfica limitada cuando una especie es un depredador del otro y la segunda especie consume recursos del medio ambiente?”

Para nuestro modelo en vez de modelar lobo y alce, modelaremos lobos y ovejas. El conjunto de datos de lobos y alces está bien establecido, pero nuestro objetivo en este capítulo no es coincidir con estos datos en particular, sino presentarles ejemplos clásicos del modelado predador-presa y tratar de reproducir el patrón sostenido oscilante de los niveles poblacionales.

Seleccionando los Agentes

Ahora que hemos identificado nuestra pregunta de investigación, podemos comenzar a diseñar los componentes que nos ayudarán a responderla. La primera pregunta que debemos hacernos es: ¿Cuáles son los agentes en el modelo? Al diseñar nuestros agentes, queremos elegir aquellos componentes de nuestro modelo que sean autónomos y que tengan propiedades, estados y comportamientos que puedan tener relación con nuestra pregunta. Pero debemos tener cuidado de evitar la sobrecarga del agente. Dependiendo de la perspectiva que se tome, casi cualquier componente del modelo podría ser considerado un agente. Sin embargo, un modelo que está diseñado con un exceso de clases de agentes puede llegar a ser rápidamente inmanejable. Al elegir los agentes en un modelo, es importante concentrarse en aquellas entidades autónomas que son más relevantes para nuestra pregunta de investigación.
Un problema relacionado es la “granularidad” del agente. Cada entidad está compuesta de múltiples entidades más pequeñas. ¿Cuál es el nivel adecuado de entidad para elegir? ¿Deberían nuestros agente ser moléculas o átomos? ¿Órganos o células del cuerpo? . Si queremos modelar un campo de pasto, tal vez no queramos modelar cada hoja de pasto, sino que en lugar de eso, elegir “grumos” de pasto como nuestros agentes. Es importante que la granularidad de cada agente esté aproximadamente al mismo nivel.

Teniendo en cuenta lo anterior, comenzamos eligiendo tres tipos de agente. Modelamos los depredadores, que llamaremos lobos, las presas que llamaremos ovejas, y los recursos que las ovejas consumen, el pasto.

Nosotros podríamos tener muchos otros agentes en este modelo. Por ejemplo, podríamos modelar un cazador o los niveles de precipitación o de nutrición del suelo. Sin embargo, al elegir sólo lobos, ovejas y pasto, nos atenemos al principio de diseño ABM (keep it simple). Tenemos dos tipos de agentes móviles simples y un tipo de agente estacionario para modelar el ambiente, y éstos son el conjunto mínimo de agentes necesarios para responder a nuestra pregunta de qué parámetros permitirán que coexistan dos poblaciones en un área geográfica limitada.

Seleccionando Propiedades de los Agentes

Los agentes tienen propiedades que los distinguen de otros agentes. Es importante determinar estas propiedades con antelación para que podamos conceptualizar el agente y diseñar las interacciones entre ellos y con el medio ambiente. En el modelo Predador-Presa damos a las ovejas y a los lobos tres propiedades :

1. un nivel de energía, que define el nivel de energía del agente.
2. un lugar, que es un lugar en el área geográfica donde el agente está-
3. una dirección, que indica hacia donde está mirando y la dirección que el agente tomaría en caso de que se mueva.

La propiedad energética no describe meramente energía temporal (como si un animal está fresco o fatigado). Más bien, la “energía” incorpora alguna noción de la cantidad de “vitalidad” en una criatura, abstrayendo los detalles del metabolismo, el almacenamiento de calorías o el hambre y condensándolo todo en una sola medida. Podríamos agregar propiedades adicionales y algunas de ellas podrían ser útiles para futuras extensiones, por ejemplo, podríamos añadir una velocidad de movimiento y permitir que agentes se muevan a distintas velocidades, o una capacidad de ofensa / defensa que afecte la capacidad del individuo resistirse a la depredación. Sin embargo, estas propiedades adicionales no parecen necesarias para responder a nuestra pregunta más simple, y por lo tanto, resistimos a la tentación de incluirlas innecesariamente. Si las ovejas y los lobos tienen exactamente las mismas propiedades, ¿qué los hace diferentes unos de otros? Discutiremos esto más adelante, donde hablamos sobre el comportamiento que cada uno de estos dos tipos de agentes exhiben.

Características del ambiente y parcelas

Ahora que definimos los agentes móviles y sus comportamientos ,pensemos en elñentorno en el que vivirán estos agentes móviles y cómo pueden interactuar con ese entorno. En el modelo Predador-Presa, el primer atributo ambiental obvio es la presencia o ausencia de pasto, ya que es lo que consumen las ovejas. Podríamos modelar muchos otros atributos tales como la elevación, el agua, los bosques y otras características que podrían afectar el movimiento de los animales o la depredación de las ovejas. Sin embargo, de acuerdo con nuestro principio de diseño, comenzamos con un entorno que consiste en un gran campo de pasto. Usamos los tipos de agente llamados parcelas (típicas de Modelos Basados en Agentes) para modelar el pasto.

Como se mencionó, no tendría sentido modelar cada hoja de pasto, por lo que el modelo podría dar a las parcelas una propiedad “cantidad de pasto” que tendrá un valor numérico. Esto es efectivamente utilizar las parcelas para modelar montones de pasto, que es nuestro tipo de agente estacionario. El valor numérico de esta propiedad debe ser proporcional al comportamiento alimenticio de las ovejas, ya que así lo utilizaremos en el modelo. Con el fin de evitar tratar con las condiciones de frontera (como lobos que superan los límites del mundo modelado), el mundo se “envolverá” horizontal y verticalmente, por lo que un lobo saliendo del borde derecho del mundo aparecerá a la izquierda. Esta topología en forma de toro es a menudo muy conveniente para ABMs. También vale la pena señalar que en algunas ABMs el entorno también controla los procesos de nacimiento y muerte de los agentes. En este modelo el nacimiento y la muerte serán modelados endógenamente dentro de las acciones de los agentes, pero es posible tener nacimiento y muerte de agentes controlados por el ambiente . Esta es una forma menos “emergente” de modelar el ciclo de vida, pero a veces es una simplificación útil.

Comportamiento de los agentes

Además de definir las propiedades de los agentes es importante determinar qué tipo de comportamiento pueden exhibir los agentes. Estos comportamientos son necesarios para describir cómo los agentes interactúan entre sí y con el medio ambiente.
En el modelo Predador-Presa, las ovejas y los lobos comparten muchos comportamientos comunes, ambos tienen la capacidad de girar al azar, avanzar, reproducirse y morir. Sin embargo, ovejas y lobos difieren en que las ovejas tienen la capacidad de consumir pasto y lobos tienen la capacidad de consumir ovejas. Esto diferencia las dos especies (breeds) ó tipos de agente entre sí. Por supuesto, una vez más hay muchos otros comportamientos que podríamos prescribir para estos agentes. Por ejemplo, podríamos dar a las ovejas la capacidad de esconderse en los rebaños para defenderse contra ataques de lobo, o la capacidad de luchar. Los lobos podrían tener la capacidad de moverse a diferentes velocidades para perseguir ovejas. Lobos y ovejas también pueden tener comportamientos comunes como: dormir, digerir los alimentos y buscar refugio durante una tormenta. Sin embargo, nuevamente los comportamientos que hemos descrito (Mover, reproducir, comer y morir) son opciones razonables para un modelo simple que pueden abordar nuestra pregunta de investigación. Para los agentes herbáceos (pasto) , damos un simple comportamiento, la capacidad de crecer.

Manejo del Tiempo

Ahora que hemos establecido los componentes básicos del modelo,podemos diseñar el paso de tiempo en el modelo. Para ello necesitamos pensar en los comportamientos que serán exhibidos por los agentes de nuestro modelo y decidir cómo y en qué orden se deben realizar. En el mundo real, los animales se comportan concurrentemente y el tiempo parece continuo. Para construir nuestro ABM, simplificaremos esto dividiendo el tiempo en pasos discretos ticks, además dividimos cada paso en fases ordenadas y serializadas. Haciéndolo de esta manera, estamos haciendo un supuesto implícito de que al definir un orden para realizar las acciones esto no afectará sustancialmente nuestros resultados. Esto es un supuesto de trabajo y puede que tenga que ser reexaminado más tarde.
En general, la determinación del orden en que los agentes muestran comportamientos puede ser complicado.

En el modelo hay cuatro comportamientos animales básicos:

• mover
• morir
• comer
• reproducir

y un comportamiento del pasto:

• crecer

Otra hipótesis de trabajo que podemos mirar, es decidir qué el orden en que los animales realizan estos comportamientos puede ser arbitrario. Cualquier orden para los comportamientos sería razonable y es mucho más fácil trabajar con unorden fijo de comportamientos. Elegimos ordenar los comportamientos como en la primera oración de este párrafo (mover, morir, comer,reproducir), podríamos chequear y asegurarnos si este orden tiene sentido.

El movimiento es el acto de girar y luego dar un paso adelante. Dado que la acción de movimiento cambia la ubicación de los agentes y por lo tanto cambia el entorno local de cada agente, tiene sentido moverse primero, el movimiento cuesta energía y así programaremos la muerte a continuación, porque debemos comprobar para ver si alguno de los agentes ha gastado tanta energía mientras se mueve que ya se queda sin energía. Después de esto, programaremos a los agentes para que intenten obtener nueva energía, si hay algo en su entorno local que puedan comer. Ya que ahora tienen nueva energía y los agentes pueden reproducirse (ya que esto también requiere energía).Por lo tanto, cada agente verifica si tienen suficiente energía para crear un nuevo agente. Finalmente, dado que el modelo ha hecho todo lo demás, los agentes de pasto crecen. Y el ciclo de la vida termina

Seleccionando los parámetros del modelo

Podríamos decidir escribir un conjunto de reglas completamente especificas para controlar el comportamiento de todos estos agentes y sus interacciones ambientales durante un paso de tiempo, pero tiene más sentido crear algunos parámetros que nos permitan controlar el modelo, para que podamos fácilmente examinar diferentes condiciones. Un paso siguiente es definir qué atributos del modelo podremos controlar a través de parámetros.

Existen varios parámetros posibles de interés en el modelo, por ejemplo, queremos ser capaces de controlar el número de ovejas y lobos iniciales. Esto nos permitirá ver cómo los diferentes valores de los niveles de población inicial afectan los niveles finales de población. Otro factor a controlar es la cantidad de energía que cuesta a un agente para moverse. Usando este parámetro, podemos hacer que el paisaje sea más o menos difícil de recorrer, y así simular diferentes tipos de terreno. Relacionado con el costo de movimiento tenemos la energía que cada especie gana de lo que consume. Así, elegimos tener parámetros para controlar la energía que se obtiene del pasto.

Por último, dado que las ovejas consumen pasto, para mantener a la población en el tiempo queremos que el pasto vuelva a crecer. Así que necesitaremos un parámetro para la tasa de rebrote del pasto.
Hay muchos otros parámetros que podríamos haber incluido en este modelo. Por ejemplo, los parámetros que elegimos son homogéneos en todo el modelo. En otras palabras, una oveja ganará la misma energía del pasto que cualquier otra oveja. Sin embargo, podríamos hacer este modelo más heterogéneo al extraer la ganancia de energía para cada oveja de una distribución estadística y tener dos parámetros de modelo que controlan la media y la varianza. También podríamos agregar parámetros para controlar aspectos que actualmente estamos considerando como valores constantes, Por ejemplo, no creamos un parámetro para controlar la velocidad de los agentes. Tener la capacidad de modificar esas velocidades y (particularmente la relación entre las tasas de movimiento de lobos y ovejas) podría afectar dramáticamente al modelo. Sin embargo, guiado por nuestro principio de diseño ABM (KISS), esta complicación no parece necesaria en esta etapa del proceso de modelado. Permitir diferentes velocidades de movimiento para lobos y ovejas es una expansión en este modelo que se deja para que el estudiante avanzado.

Las mediciones

Siimplementamos todos los componentes anteriores, tendríamos un primer modelo de trabajo. Sin embargo, todavía no tendríamos nada para responder a nuestra pregunta. Para ello debemos decidir qué medidas recogeremos del modelo. Crear medidas puede ser muy simple a veces, pero a menudo algunas de los resultados más interesantes de un modelo no se perciben hasta después de que se hayan diseñado las mediciones del modelo, cuando se considera qué medidas incorporar en el modelo es entonces útil revisar la pregunta de investigación.
Es aconsejable incluir sólo las medidas más relevantes, porque un exceso de medidas puede ser abrumador y asfixiante y puede hacer lenta la ejecución del modelo. En nuestro modelo, las medidas más relevantes son:

la población de lobos y ovejas en el tiempo

ya que lo que nos interesa es qué conjuntos de parámetros nos permitirá mantener niveles positivos de ambas poblaciones a lo largo del tiempo. Podríamos construir medidas de muchos otros datos en este modelo, tales como la energía promedio de ovejas o lobos. Esto podría afectar a nuestra pregunta, ya que podría indicar la probabilidad de que persistan las poblaciones actuales, pero no se dirige directamente a la pregunta y entonces esta medida no la incluiremos. A veces es útil incluir medidas como ésta para propósitos de depuración. Por ejemplo, si vemos que los niveles de energía de ovejas estaban aumentando a pesar de que no había crecimiento de pasto, entonces nos gustaría ver si hubo un error en la parte donde convertimos pasto en energía para la oveja.

Resumen

1. Pregunta Orientadora:

“¿Bajo que condiciones dos especies pueden mantener niveles poblacionales positivos oscilantes en un área geográfica limitada cuando una especie es un depredador del otro y la segunda especie consume recursos del medio ambiente?”

2. Tipos de agentes Ovejas, lobos, pasto

3. Propiedades de los agentes:

• Energía, ubicación, dirección (lobos y ovejas), cantidad de pasto (pasto).

4. Comportamiento de los agentes:

• Mover, morir, reproducir (lobos y ovejas), comer ovejas (solo lobos), comer pasto (solo ovejas), Reproducir (pasto).

5. Parámetros

Número de ovejas, Número de lobos, Costo del movimiento, Ganancia de energía del pasto, Ganancia de energía de las ovejas, tasa de crecimiento del pasto

6. Tiempo

En cada tick :

1. Movimiento de ovejas y lobos

2. Ovejas y lobos mueren

3. Las ovejas y los lobos comen

4. Las ovejas y los lobos se reproducen

5. El pasto vuelve a crecer

6. Mediciones:

• población de ovejas versus tiempo
• población de lobos versus tiempo.

Al diseñar un modelo es bastante útil escribir notas para usted mismo, como lo hemos hecho en esta sección. Encontrará estas notas invaluables después de haber dejado el modelo por un tiempo, ya que usted podrá regresar y recordar por qué tomó ciertas decisiones y opciones alternativas. Además, para explicar su modelo a otras personas, es muy útil tener dicha documentación sobre el modelo. Finalmente, se recomienda poner fechas a sus notas a medida que las crea para poder seguirle el paso a su modelo.
Por ejemplo, si está utilizando el proceso de diseño de arriba hacia abajo (top-down) que acabamos de discutir, entonces puede revisar el siguiente conjunto de preguntas y escribir las respuestas a ellas como guía provisional sobre cómo construir su modelo:

7.2.1 Siete Criterios de Diseño:

1. ¿De qué parte de tu fenómeno te gustaría construir un modelo? (Alcance / Pregunta)
2. ¿Cuáles son los principales tipos de agentes involucrados en este fenómeno? (Agentes)
3. ¿Qué propiedades tienen estos agentes (por tipo de agente)? (Propiedades)
4. ¿Qué acciones o comportamientos pueden tomar estos agentes (por tipo de agente)? ¿Como interactúan entre sí o con el medio ambiente? (Comportamientos)
5. ¿En qué tipo de entorno operan estos agentes? Hay agentes estacionarios? (Ambiente)
6. Si tuviera que definir el fenómeno como pasos de tiempo discretos(ticks), qué eventos ocurrirían en cada paso de tiempo y en qué orden?
7. ¿Qué esperas observar de este modelo? (Entradas y salidas)

7.3 Cinco modelos incrementales

7.3.1 Version Uno

Introducción

Concluido el proceso de diseño conceptual debemos ahora entrar en el proceso de construcción del modelo, en esta etapa continuaremos aplicando los principios de diseño de un MOBA. Aunque nuestro modelo es bastante simple, lo dividiremos en una serie de submodelos que implementaremos en cinco iteraciones. Los submodelos serán ejecutables y nos permitirán construir y completar el modelo paso por paso, verificando nuestro progreso en el camino y asegurándonos de que el modelo funciona como lo esperamos.
Muchas veces, en modelos basados en agentes (MOBAs), los resultados finales no son los que esperamos, esto puede suceder por un error la implementación del modelo pero a menudo no es nuestra implementación ni que nuestro diseño esté mal, sino que surge de una propiedad fundamental de los sistemas complejos: el comportamiento emergente que es difícil de predecir. Al construir nuestro modelo de manera gradual, podremos observar comportamientos inusuales pronto y determinar más fácilmente su causa que si hubiéramos construido el modelo completo de una vez. Por lo tanto, el principio de diseño MOBAs (KISS:Keep It Simple Stupid) todavía se aplica a lo largo de toda la construcción del modelo.

Primera Versión

¿Cuál es el modelo más simple que podemos crear que muestre algún tipo de comportamiento?

Una simplificación que podemos hacer del modelo total es mirar solo una especie e ignorar la otra especie y el medio ambiente. Dadas estas simplificaciones,el modelo más simple tendría, por ejemplo, algunas ovejas deambulando por el paisaje. Para hacer esto, vamos a crear dos procedimientos, un procedimiento de setup, que crea las ovejas, y un Procedimiento go que las hace moverse en el paisaje.

Antes de ello, crearemos una raza de ovejas :

breed[ovejas oveja]

Esto define una clase de agentes móviles (en NetLogo, tortugas) llamada ovejas, Primero se da la forma plural “ovejas”, seguida de la forma singular “oveja”. Casi siempre se usará la forma plural (ovejas), pero es útil proporcionar la forma singular para poder referirse a una oveja en particular y además para que NetLogo pueda darle mensajes de error más significativos, entre otras cosas. Una última cosa a tener en cuenta es que, aunque estamos creando la raza “ovejas”, el conjunto de agentes turtles todavía existe. Todos los agentes móviles en un modelo NetLogo petenecen a la calse “turtles” independiente de su raza. Entonces, si desea pedir a todos los tipos de agentes de un modelo que hagan algo,es decir, tanto OVEJAS como LOBOS, entonces puedes colocar “ask turtles”. Si solo quieres que hagan algo las ovejas, entonces coloca “ask ovejas”.

  to setup
  clear-all
  ask patches [ ;; colorea de verde el mundo
   set pcolor green
  ]
  create-ovejas 100 [ ;; crea algunas ovejas
   setxy random-xcor random-ycor
   set color white
   set shape “sheep”
  ]
  reset-ticks
  end

Descripción del setup

Este procedimiento setup terminará siendo el procedimiento más largo del modelo terminado, pero su descripción es bastante sencilla. Primero, se limpia el mundo. El mundo de nuestro modelo es la representación de todos los agentes, incluidos los agentes móviles (por ejemplo, tortugas, ovejas,lobos), así como los agentes estáticos (por ejemplo, parcelas, pasto), el comando clear-all relimpia el mundo y lo prepara para una nueva ejecución.
Después de esto, se les pide a todas las parcelas que establezcan su color de parcela (pcolor) a verde para representar el pasto. Aunque nuestro modelo aún no incluye ninguna propiedad para el pasto ni ninguna regla para que las ovejas interactúen con el, cambiar el color ayuda a la visualización.
Finalmente, creamos cien ovejas, uando creamos las ovejas les definimos algunas propiedades iniciales: * Les asignamos una coordenada x aleatoria y un coordenada y aleatoria para extenderlas por todo el mundo. * Establecemos su color en blanco y su forma a la forma de “oveja” (“sheep”) para que se vean un poco más como ovejas reales.

La linea final,(reset-ticks) , inicia el reloj en 0 para que el modelo esté listo para comenzar su ejecución.

Documentación

Documentar los procedimientos dentro de su modelo (use punto y coma para comentar el código) es muy útil. Cualquier texto escrito después de un punto y coma se ignora cuando el modelo se encuentra en ejecución, agregar texto de esta manera se llama “comentar” su código. Sin estos comentarios,no solo es bastante difícil para otra persona leer y entender el modelo, sino que también se volverá cada vez más difícil, a medida que pasa el tiempo, que ud mismo entienda su propio código. Un modelo sin comentarios (u otra documentación) no es muy útil, ya que será difícil que otros descubran el comportamiento del modelo.

Validando el setup

Para verificar que el procedimiento setup hace lo que esperamos, vamos a correr el modelo, para ello vaya a la pestaña interfaz, cree un botón llamado “setup” y oprima el botón debe observar lo siguiente:

7.3.1.1 Procedimiento go

Después de haber creado las ovejas, pasamos a escribir el procedimiento “go” que indicará a las ovejas como deben comportarse en el mundo Mirando hacia atrás en nuestro documento de diseño, uno de los principales comportamientos de las ovejas es su movimiento, así que haremos simplemente que se muevan. Dividiremos el movimiento en dos partes giro y avance. Creemos los dos procedimeintos (wiggle) y (muevase):

to go
 ask ovejas [
  wiggle ;; gire al azar en cierta dirección
  muevase  ;; luego muevase
 ]
 tick
end

Esto pide a todas las ovejas (ask) que realicen dos acciones:

• wiggle
• luego muevase

El orden en el que las ovejas realizan estos dos comandos, uno después del otro, es aleatorio, cada oveja completará ambas acciones antes de que la próxima oveja tome su turno. Después de que todas las ovejas hayan terminado, el comando (tick) incrementa el reloj del modelo , lo que indica que ha pasado una unidad de tiempo. Por supuesto, para que el código funcione, debemos definir wiggle y muevase.

;; procedimiento de ovejas, la oveja cambia de dirección
to wiggle    ;; gira derecha luego izquierda,  pero en promedio apunta hacia adelante
 right random 90
 left random 90
end

;; procedimiento de ovejas, la oveja se mueve una unidad 
to muevase
 forward 1
end

Estos dos procedimientos los documentaremos como “procedimientos de ovejas”, es decir que están escritos con el supuesto implícito de que el procedimiento que los llame solicitará al conjunto de agentes adecuado (en este caso las ovejas) que los realice.

wiggle

El primer procedimiento simplemente gira a la derecha una cantidad aleatoria entre 0 y 90, y luego de vuelta a la izquierda una cantidad aleatoria entre 0 y 90. La idea detrás de este giro es hacer que las ovejas cambien la dirección en que se dirigen, sin sesgos de izquierda o derecha. Este tipo de giro aleatorio es muy común en los MOBAS,y el nombre adoptado en la comunidad MOBA es este.

muevase

El segundo procedimiento simplemente mueve la oveja hacia adelante una unidad (el ancho de una parcela)

La distancia a la que se mueve la oveja podría controlarse más tarde por un parámetro , pero por ahora lo mantendremos en una sola unidad constante, puede ejecutar este modelo ahora mismo.Cree un botón llamado go activela opción “continuamente” del botón y oprimalo. Debe observar a las ovejas moviendose de manera continua, sin cansarse, dentro del paisaje verde.

Ovejas luego de 5435 ticks

7.3.2 Version dos

Introducción versión dos

Ahora que tenemos nuestras ovejas moviéndose, tenemos una primera verificación de que nuestro modelo funciona como pretendemos que funcione, es muy importante verificar los MOBAs tan frecuentemente como sea posible.

Parametrizando el Modelo (Deslizadores)

En la versión Uno el número de ovejas es 100. Sin embargo para poder responder nuestra pregunta de investigación deberíamos poder considerar diferentes poblaciones de ovejas, la mejor manera para variar el número de ovejas es creando un deslizador (que llamaremos num-ovejas) Esto nos permitirá cambiar el número de ovejas en el modelo fácilmente desde la interfaz.Al crear el deslizador, necesitamos darle algunas propiedades, un valor mínimo , un valor máximo y un incremento, que es la cantidad que el deslizador cambiará cuando se haga clic en él. En este caso, podemos establecer el mínimo en 1 (ya que menos de una oveja no tiene sentido), el número máximo en 1,000 y el incremento a 1, ya que no tiene sentido tener, por ejemplo, 2.1 ovejas.

Ahora debemos cambiar el procedimiento setup para amarrar el deslizador al procedimiento, el cambio es el siguiente:

to setup
 clear-all
 ask patches [ ;; colorea el mundo de verde 
 set pcolor green
 ]
   ;; crea ovejas y sus porpiedades iniciales
create-ovejas num-ovejas [  ; Nuevo número de ovejas controladas por  deslizador
 setxy random-xcor random-ycor
 set color white
 set shape “sheep”
 ]
 reset-ticks
end

Extendiendo el Modelo

A continuación, debemos considerar cuál es la extensión más simple que podemos hacerle a nuestro modelo. Mmmmmmm!!! Ok, Tenemos a las ovejas moviéndose, pero !!! el movimiento no les cuesta nada !!!, En el mundo real, el movimiento requiere energía. por lo tanto, el siguiente paso es incluir un “costo” al movimiento. Recordemos que las ovejas tienen tres propiedades:

• dirección, ubicación y energía.

En la primera versión ya las dotamos de dirección y ubicación ( de hecho estas propiedades son inherentes a cualquier agente de NetLogo), pero la propiedad de energía de un agente no es una propiedad predefinida de un agente (existen muchos MOBAs donde no es obligatorio definir la energía de un agente como una propiedad de estos). ¿Cómo podemos dotar de energía a cada oveja? muy sencillo, tenemos que definir una nueva propiedad (variable) para la energía, esto lo podemos hacer agregando la siguiente linea al modelo:

ovejas-own [ energía ]  ;; las ovejas tienen una propiedad llamada energía

Con esta linea estamos declarando que las ovejas tienen una nueva propiedad (su energía) pero simplemente declarar que las ovejas tienen energía no es suficiente, necesitamos inicializar dotar a cada oveja de una energía inicial y también hacer que cambie (de hecho que disminuya) cuando las ovejas se mueven.

El procedimiento setup modificado es el siguiente:

to setup
 clear-all
 ask patches [ ;; colorea el mundo de verde 
  set pcolor green
 ]
    ;; crea ovejas y sus porpiedades iniciales
 create-ovejas num-ovejas [
  setxy random-xcor random-ycor
  set color white
  set shape “sheep”
  set energía 100  ; Nuevo energía inicial para cada oveja
 ]
 reset-ticks
 end

También necesitamos modificar (añadiendo una linea) el procedimiento muevase para asignarle un costo energético al movimiento:

to muevase
  forward 1
  set energía energía - 1 ; Nuevo reducir una unidad de energía en cada movimiento
end

El costo es de una unidad de energía, pero es posible que a medida que ampliamos el modelo,este costo se convierta en un parámetro del modelo. Agregar un costo para moverse no significa nada si no hay penalidad por gastar energía.

¿En que penalidad se podría pensar?" (Mmmmm!!)

….En una drástica, queremos que las ovejas mueran si tienen muy poca energía, por lo tanto debemos verificar si las ovejas han gastado toda su energía, para ello usaremos un procedimiento llamado verifique-si-hay-muertes:

to go
 ask ovejas [
 wiggle ;; gire al azar en cierta dirección
 muevase ;; luego muevase
 verifique-si-hay-muertes ; Nuevo elimina ovejas sin energía
]
tick
end

to verifique-si-hay-muertes   ; procedimiento oveja : mínima energía --> al papayo
  if energía < 0 [die]
end

Vayamos a la pestaña interfaz y oprimamos setup y luego go el modelo se ejecutará por un tiempo y en cierto instante todas las ovejas desaparecerán al mismo tiempo.(¿Por qué?) Lamentablemente, el modelo seguirá funcionando ad-eternum (visualmente esto es cierto usted porque el botón go sigue presionado y los ticks siguen aumentando). Sería muy bueno si nuestro modelo se detiene cuando ya no hay seres vivientes en el paisaje. implementarlo es muy fácil, se agrega una linea al comienzo del go: P

to go
 if not any? ovejas [stop]  ;; Nuevo si noa hay ovejas pare el modelo
 ask ovejas [
  wiggle ;; gire al azar en cierta dirección
  muevase ;; luego muevase
  verifique-si-hay-muertes
 ]
 tick
end

Ahora, si vuelve a ejecutar el modelo, cuando desaparezcan todas las ovejas, el modelo deja de funcionar.

Construyendo las Gráficas

Será muy útil saber cuántas ovejas hay en cada instante de tiempo (tick), por lo que podemos agregar una gráfica que muestre cuál es la población de ovejas en cualquier momento.Hay dos formas de manejar gráficas (plots):

1. El método basado en widgets, ya que hace uso de un widget gráfico.
2. El método programático o basado en código.

En ambos métodos, el código es escrito para actualizar las gráficas, pero en el método basado en código, el código se encuentra en la pestaña Código de NetLogo. En el método basado en widgets, el código se encuentra dentro del widget que hará el trazado de la gráfica.
Los dos métodos son equivalentes, por lo que depende del modelador decidir qué método usar. Ambos tienen ventajas y desventajas. La ventaja de usar widgets es que no se necesita “saturar” la pestaña de Código con código adicional para trazar las gráficas, y que para trazados simples, es más rápido de configurar, sinembargo para gráficas complejas puede ser más difícil configurar un diagrama con el método de widgets. Además, si hay errores en la gráfica del widget, puede ser difícil darse cuenta, ya que no se mostrará como un error en la pestaña de Código. El método de trazado de la pestaña Código tiene las ventajas y desventajas inversas.
Nuestra recomendación general es usar widgets para gráficos relativamente simples y la pestaña de código para gráficos complejos.

Usaremos para nuestro modelo, el método basado en la pestaña de Código. Todo lo que haremos aquí también puede ser realizado usando el método de widgets:

• primero se crea un diagrama (Widget) en la interfaz y se establecen sus propiedades

En este caso colocaremos solo el título al Widget, ver la siguiente figura:

• luego agregamos una llamada al diagrama desde el go

to go
 if not any? ovejas [stop]
 ask ovejas [
 wiggle ;; gire al azar en cierta dirección
 muevase ;; luego muevase
 verifique-si-hay-muertes
]
tick
actualice-gráficas   ; Nuavo llamado a actualizar gráficas
end

Necesitamos definir el procedimiento actualice-gráficas:

;; actualica gráficas en la interfaz
to actualice-gráficas  
  plot count ovejas  ; Gráfica el número de ovejas dado el tiempo (tick)
end

(Nota Importante: Podríamos haber usado “plot count ovejas” directamente al final del procedimiento go, pero sabemos que es probable que tengamos que trazar otras gráficas (por ejemplo más adelante de número de lobos y de cantidad de pasto), Entonces podemos usar este procedimiento para otras gráficas también)

Ejecutemos el modelo (setup luego go):

la gráfica nos muestra que hubo un población completa de ovejas hasta el final y luego todas murieron al tiempo, la muerte de todas las ovejas en el tick 101 es el resultado de la energía inicial y el costo del movimiento que le hemos definido a las ovejas.

Costo del Movimiento como parámetro

Recordemos que queríamos que el costo del movimiento fuera un parámetro del modelo. Necesitamos entonces:

• Agregar otro deslizador para controlar el costo del movimiento
• Modificar el procedimiento muevase para tomar en cuenta el valor del deslizador.

Entonces: 1. Cree un deslizador llamado costo-movimiento de la siguiente manera:

Modifique el procedimiento muevase:

to muevase
 forward 1
 set energía energía - costo-movimiento ; Nuevo reducir energía por deslizador
end

¡¡¡ ufff !!!! Listo tenemos la versión 2 de nuestro modelo!!!

Modelo Versión Dos, con dos deslizadores,una Gráfica y Ovejas muertas

7.3.3 Version tres

Introducción versión tres

En este momento, el modelo exhibe un comportamiento muy predecible. Cada vez el modelo funciona durante (100 / costo-movimiento) ticks, luego todas las ovejas desaparecen y el modelo se detiene. La razón es porque las ovejas actualmente gastan energía (moviéndose) pero no tienen forma de adquirir energía. Por lo tanto, necesitamos dar a las ovejas la capacidad de comer pasto y de esta manera ganar energía. Sin embargo, primero debemos crear el pasto!!!

¿Cómo hacer esto?

Vamos a definirle a las parcelas (que funcionaran como manojos de pasto para este modelo), una propiedad llamada cantidad-de-pasto, que mide la cantidad de pasto que hay disponible en esa parcela, debemos entonces agregar a nuestro modelo la siguiente línea (después de la línea ovejas-own[energía]):

patches-own[cantidad-de-pasto]  ;; las parcelas contienen pasto, cantidad variable

Ahora tenemos que colocar el pasto, pero mientras estamos en ello, modificaremos el color de las parcelas para que indiquen cuánto pasto tienen. Hacemos esto configurando la cantidad inicial de pasto a un número aleatorio real entre 0.0 y 10.0.Usaremos números reales para el pasto, ya que a diferencia de las ovejas, que son individuos, cada parcela contiene un “manojo” de pasto, no hojas individuales. Esto asegura cierta variabilidad en la cantidad de pasto y crea cierta heterogeneidad. Luego establecemos el color del pasto a un tono verde tal que si no hay pasto en absoluto, la parcela será negra, y si hay mucho pasto en la parcela, está será de color verde brillante.

to setup
 clear-all

 ask patches [
 ;; parcelas se habitan con un  número aleatorio de pasto
 set cantidad-de-pasto random-float 10.0  ;; colorear las parcelas  con la cantidad de pasto
 set pcolor scale-color green cantidad-de-pasto 0 20
]

 create-ovejas num-ovejas [ ;; crea ovejas y sus propiedades iniciales
  setxy random-xcor random-ycor
  set color white
  set shape "sheep"
  set energía 100
 ]
 reset-ticks
end

Ahora necesitamos modificar el procedimiento go para que las ovejas puedan comer pasto. Como mencionamos en el diseño, colocamos este procedimiento después del procedimiento de verificación de muerte, llamaremos al procedimiento comer:

to go
 if not any? ovejas [stop]
 ask ovejas [
 wiggle ;; gire al azar en cierta dirección
 muevase ;; luego muevase
 verifique-si-hay-muertes
 comer ; Nuevo las ovejas comen pasto
 ]
 tick
 actualice-gráficas
end

to comer
 if cantidad-de-pasto >= 1 [
  set energía energía + 1  ; incremente energía de la oveja
  set cantidad-de-pasto cantidad-de-pasto - 1  ; reduzca el pasto de la parcela donde está
  set pcolor scale-color green cantidad-de-pasto 0 20  ; actualiza el color del pasto
 ]
end

Se verifica, para cada oveja, si hay suficiente pasto en la parcela donde está. Si hay suficiente para comer, la oveja convierte el pasto en energía , y se disminuye la cantidad de pasto en la parcela.Al mismo tiempo, recoloreamos la parcela para reflejar la nueva cantidad de pasto, el comportamiento del modelo todavía no es muy interesante. Las ovejas deambulan, comen tanto pasto como pueden, y eventualmente todos se extinguen. La única variación en el modelo es el nivel de pasto en las parcelas. Debido a la distribución aleatoria de pasto originalmente y debido a que las ovejas se muevan al azar alrededor del paisaje, habrá algunas áreas de pasto que son completamente consumidas por las ovejas y otras áreas que serán solo parcialmente consumidas.

Para que el modelo sea un poco más interesante, agregaremos un procedimiento para que el pasto vuelva a crecer. Al permitir que el pasto vuelva a crecer, debería ser posible mantener la población de ovejas a lo largo del tiempo, ya que existirá una fuente renovable de energía para ellos. Empezamos modificando el procedimiento go, añadiendo el procedimiento renace-pasto:

to go
 if not any? ovejas [stop]
 ask ovejas [
 wiggle ;; gire al azar en cierta dirección
 muevase ;; luego muevase
 verifique-si-hay-muertes
 comer
 ]
 renace-pasto   ; nuevo  el pasto vuelve a crecer
 tick
 actualice-gráficas
end

;; renace el pasto
to renace-pasto
 ask patches [
  set cantidad-de-pasto cantidad-de-pasto + 0.1
  if cantidad-de-pasto > 10 [
  set cantidad-de-pasto 10
 ]
  set pcolor scale-color green cantidad-de-pasto 0 20
 ]
end

Este procedimiento dice a todos las parcelas que aumenten la cantidad de pasto que tienen en una décima parte. También nos aseguramos de que el pasto nunca exceda de 10 unidades, que sería la cantidad máxima para cualquier parcela. Luego se recolorea el pasto, con este pequeño cambio las oveja deberían sobrevivir a una corrida del modelo. ¡¡¡¡pruébelo!!!!!

Ahora tenemos recoloración de pastoen tres lugares diferentes del modelo, por lo que también sería bueno colocar un procedimiento. A menudo, cuando comenzamos a duplicar código, vale la pena colocarlo en un procedimiento separado; de esa manera tenemos que modificar el código en una sola ubicación si necesitamos cambiarlo más tarde (por ejemplo, si queremos que el césped sea de color amarillo en lugar de verde).Mantener el código más conciso y colocar nombres apropiados ayuda a que su código sea más legible para otros. Entonces definimos un procedimiento recolorear-pasto:

to recolorear-pasto
set pcolor scale-color green cantidad-de-pasto 0 20
end

(Nota:Coloque este procedimiento en el modelo y coloque en los sitios donde se recolorea el pasto el nombre de este procedimiento)

Reflexion en torno al modelo

Al ejecutar el modelo varias veces con cien ovejas iniciales, queda claro que cien ovejas no pueden consumir todo el pasto y, por lo tanto, eventualmente todo el mundo se convierte en un sólido tono verde. Sin embargo, si aumenta el número de ovejas iniciales a un número mayor, digamos setecientos, y luego se corre el modelo, las ovejas consumirán casi todo el pasto en el modelo, y luego muchas de ellos morirán. Sin embargo, algunas de ellas, que tenían una gran cantidad de energía antes de que desapareciera todo el pasto sobrevivirán y eventualmente el pasto volverá a crecer, lo que les permitirá persistir, ya que ya hay muchas ovejas compitiendo por el pasto. Otro parámetro que queremos introducir y que puede afectar la dinámica del modelo es la velocidad a la que el pasto vuelve a crecer. Vamos a agregar un deslizador llamado rata-crecimiento-pasto, le damos valores límite de 0 y 2 y un incremento de 0.1:

modifiquemos el procedimiento renace-pasto para reflejar el uso de este nuevo parámetro:

;; renace el pasto
to renace-pasto
  ask patches [
   set cantidad-de-pasto cantidad-de-pasto + rata-crecimiento-pasto  ;; Nuevo : deslizador
   if cantidad-de-pasto > 10 [
   set cantidad-de-pasto 10
 ]
 recolorear-pasto
 ]
end

Si colocamos rata-crecimiento-pasto en un valor lo suficientemente alto (por ejemplo 2.0), entonces incluso con setecientas ovejas en el modelo, se puede mantener la población total de ovejas. Esto se debe a que las ovejas pueden obtener una unidad completa de energía del pasto, y si este vuelve a crecer esta cantidad en un solo tick, las ovejas gastan esa energía cuando se mueven, pero esa energía se reemplaza inmediatamente. Sin embargo, si se cambia el deslizador costo-movimiento a un valor mayor que uno, las ovejas eventualmente morirán, esto se debe a que están gastando energía más rápido de lo que pueden recolectar del medio ambiente( incluso si no hay escasez de pasto).

Para que nuestro modelo sea más flexible,podemos agregar otro parametro (deslizador), llamado cantidad-energía-pasto, que controla la cantidad de energía que las ovejas pueden obtener al comer pasto, al igual que con los deslizadores anteriores, tendremos que establecer límites razonables y un incremento para este nuevo deslizador.

Para usar este nuevo deslizador necesitamos modificar el procedimiento comer:

to comer  ; Nuevo : Deslizador cantidad-energía-pasto
 if cantidad-de-pasto >= cantidad-energía-pasto [
  set energía energía + cantidad-energía-pasto  ; incremente energía oveja
  set cantidad-de-pasto cantidad-de-pasto - cantidad-energía-pasto  ; decrementa el pasto de la   parcela donde está
 recolorear-pasto  ; actualiza color del pasto
]
end

Tenga en cuenta que utilizamos el parámetro cantidad-energía-pasto tanto para incrementar la enegía de las ovejas como para disminuir el valor del pasto. Podríamos haber usado dos diferentes parámetros para estas dos funciones, pero podemos pensar en el sistema " ovejas / pasto" como un sistema de conversión de energía, donde la energía del pasto fluye hacia las ovejas.
En este momento podemos observar una dinámica interesante:

Comenzando con setecientas ovejas, duran alrededor de trescientos ticks, Pero luego hay una hambruna masiva, que se hace cada vez más más gradual, hasta que alrededor de quinientos ticks, la población se mantiene estable con un poco más de cuatrocientas ovejas. Luego de que han muerto suficientes ovejas, el pasto se regenera, mantiene a las ovejas vivas y el sistema alcanza un estado de equilibrio. Como el movimiento de las ovejas es aleatorio,es posible que una gran cantidad de ovejas se agrupen en las mismas pocas parcelas durante mucho tiempo, y por lo tanto mueran de hambre, pero esto no es probable.

Dependiendo de la selección de los parámetros del modelo, también son posibles muchos otros comportamientos.

¡¡ Siéntase libre de experimentar y explorar antes de pasar a la próxima versión del modelo!!

7.3.4 Version cuatro

Introducción versión cuatro

El modelo tiene ovejas moviéndose en un paisaje, consumiendo recursos y muriendo. Sin embargo, no hay forma de que la población de ovejas aumente!!!, de hecho solo puede bajar. Por lo tanto, para que vuelva a subir, agregaremos reproducción al modelo.Construir un modelo reproductivo completo con parejas sexuales y tener una oveja embarazada tomaría mucho tiempo, y no está claro de que seviría para responder nuestra pregunta inicial.
En cambio, haremos dos simplificaciones:

1. Una sola oveja puede producir nuevas ovejas!!!. Se puede ver esto como reproducción asexual o se puede pensar que cada oveja representa a un par de ovejas macho y hembra unidas. Esta suposición puede parecer extraña al principio y ciertamente es obviamente contraria a la realidad. Este es un buen momento para recordar las palabras de George Box: “todos los modelos están equivocados, pero algunos son útiles”. Está bien errar en nuestro modelo sobre un hecho tan básico si el modelo simplificado sigue siendo útil para nuestros propósitos. Pero si luego vemos que con esta simplificación se ha perdido alguna utilidad del modelo, siempre podremos agregar verdadera reproducción sexual más tarde.

2. La segunda simplificación es esta: en lugar de preocuparse por el proceso de gestación, asumiremos que las ovejas dan a luz de manera inmediata a una ovejita, cuando alcanzan un cierto nivel de energía. Esta energia puede verse como una aproximación a tener la capacidad de reunir suficientes recursos para sobrevivir durante todo el período de gestación. Para implementar esto, comenzamos agregando código al procedimiento go:

to go
 if not any? ovejas [stop]
ask ovejas [
  wiggle ;; gire al azar en cierta dirección
  muevase ;; luego muevase
  verifique-si-hay-muertes
  comer
  reproducirse  ; Nuevo: procedimiento de reproducción de las ovejas
 ]
 renace-pasto   ; nuevo  el pasto vuelve a crecer
 tick
 actualice-gráficas
end

to reproducirse
 if energía  > 200 [
  set energía energía - 100  ;; reproducción transfiere energía
  hatch 1 [ set energía 100 ] ;; energía de la nueva oveja
 ]
 end

Se verifica si la oveja actual tiene suficiente energía para reproducirse (dos veces la cantidad original de energía (100)). Si la oveja lo cumple, entonces disminuye su energía en 100, y crea una nueva ovejita (hatch crea un clon del agente en la misma parcela) y establece su energía también a 100.
Ahora, si ejecutamos el modelo con un bajo costo-movimiento en comparación con la cantidad-energía-pasto, y lo arrancamos con 700 ovejas, la población aumenta con el tiempo, y finalmente se nivela cerca de 1.300 ovejas, como se muestra en la figura :

Modelo con Reproducción (Aumento de 700 a 1300 ovejas)

7.3.5 Version cinco

Introducción versión cinco

Tenemos a las ovejas comportándose de la manera que describimos en nuestro diseño pero nuestro objetivo original era tener dos especies. Entonces ahora necesitamos agregar a los lobos. Lo primero que debemos hacer es crear una segunda raza (breed) llamada lobos. Al mismo tiempo necesitamos dar a loslobos energía.
Podríamos hacer esto agregando un comando lobos-own como nuestro ovejas-own, pero dado que los únicos agentes de tortuga en el modelo son ovejas y lobos, podemos hacer de energía una propiedad genérica de todas las tortugas. Hacemos esto cambiando la declaración: ovejas-own[energía] por turtles-own[energía], entonces añadamos la nueva raza lobos y hagamos esta modificación :

breed[ovejas oveja]
breed[lobos lobo]

turtles-own[energía]

Después de esto, necesitamos crear los lobos, tal como lo hicimos con las ovejas. Primero, agregamos un deslizador llamado num-lobos:

Ahora modificamos el procedimiento SETUP:

to setup
 clear-all

 ask patches [
  set cantidad-de-pasto random-float 10.0 ;; parcelas se habitan con num aleatorio de pasto
  recolorear-pasto ;; colorear las parcelas de acuerdo con la cantidad de pasto
 ]


 create-ovejas num-ovejas [ ;; crea ovejas y sus propiedades iniciales
  setxy random-xcor random-ycor
  set color white
  set shape "sheep"
  set energía 100
 ]

;; NUEVO : CREACIÓN DE LOBOS
 create-lobos num-lobos [ ;; crea lobos y sus propiedades básicas
  setxy random-xcor random-ycor
  set color brown
  set shape "wolf"
  set size 1.5
  set energía 100
 ]
  
 reset-ticks
end

Ahora que hemos agregado lobos al modelo, también necesitamos agregar sus comportamientos. Observe que todos los comportamientos son comunes tanto para los lobos como para las ovejas, incluso si los detalles exactos difieren (por ejemplo, los lobos comen ovejas, mientras que las ovejas comen pasto, pero ambos “comen”). Entonces simplemente debemos reemplazar “ovejas” por “turtles” en las dos primeras lineas de nuestro procedimiento go :

to go
 if not any? turtles [stop]   ;; NUEVO: CAMBIAR ovejas POR turtles
 ask turtles [    ; cambiar ovejas por turtles
  wiggle ;; gire al azar en cierta dirección
  muevase ;; luego muevase
  verifique-si-hay-muertes
  comer
  reproducirse  
 ]
 renace-pasto   ; nuevo  el pasto vuelve a crecer
 tick
 actualice-gráficas
end

Todos los comportamientos que le dimos a las ovejas se aplican igualmente bien a los lobos, entonces el modelo correrá como está. Sin embargo:

¡¡¡los lobos comen pasto en este modelo tal y como está!!!!!!

Pero el comportamiento alimenticio de los lobos es diferente del comportamiento alimenticio de las ovejas, por lo que tendremos que modificar nuestro procedimiento de “comer”:

to comer
ifelse breed = ovejas [
  comer-pasto
]
[
  comer-oveja
]
end

Ahora nuestro comportamiento alimentario será diferente para las ovejas y los lobos. Las ovejas comerán pasto y los lobos comerán ovejas

• Cambiemos el nombre de nuestro antiguo procedimiento “comer” por “comer-pasto” ya que ese es el comportamiento que definimos para las ovejas. Ahora falta definir el comportamiento de “comer-ovejas”.

• Agregue un deslizador cantidad-energía-oveja

coloquemos el procedimiento comer-oveja:

to comer-oveja
if any? ovejas-here [ ;; si hay ovejas coma
let target one-of ovejas-here ;; seleccione una oveja al azar de la parcela
ask target [ ;; coma la oveja seleccionada
die
]
;; incremente energía de acuerdo con deslizador
set energía energía + cantidad-energía-oveja
]
end

En este procedimiento, el lobo primero verifica si hay ovejas disponibles para comer en la parcela donde se encuentra. Si las hay, entonces consume a una de ellas (elige una al azar de la parcela) y obtiene un aumento de energía de acuerdo con el deslizador de energía que acabamos de definir.

Actualizando las graficas

Ahora nuestro modelo tiene todos los agentes, comportamientos e interacciones que nos propusimos crear. Sin embargo, nuestro gráfica (plot) aún no contiene toda la información. Seria útil si también el gráfico muestra la población de lobos, y al mismo tiempo podemos agregar una visualización de cantidad de pasto en el mundo. Para hacer esto, primero agregamos dos “esferos”(pen) adicionales a la gráfica (lobos y pasto). También cambiamos el nombre del lápiz de trazado predeterminado a oveja.
Para que quede claro, la modificación al procedimiento actualice-gráficas es la siguiente:

to actualice-gráficas
set-current-plot-pen "ovejas"
plot count sheep
set-current-plot-pen "lobos"
plot count wolves * 10 ;; se escala para que se vea bien la gráfica
set-current-plot-pen "pasto"
plot sum [cantidad-de-pasto] of patches / 50
;; se escala para que se vea bien la gráfica
end

Este código es bastante sencillo. El “* 10” y “/ 50” son solo factores de escala para que la gráfica sea legible cuando todos los datos se trazan en el mismo eje. (Pero tenga en cuenta que al leer el número de lobos fuera de la gráfica, el recuento real de la población es diez veces más pequeño.) A menudo también es útil agregar monitores para estas variables para poder leer por fuera de la gráfica los valores exactos.
Ahora podemos experimentar el modelo con una variedad de configuraciones de parámetros. Muchos ajustes de parámetros provocarán la extinción de una o ambos especies. Pero podemos encontrar parámetros que den como resultado un ecosistema autosostenible ( en donde los niveles de población de las especies varían de manera cíclica) Se muestra uno de estos conjuntos de parámetros en la siguiente figura:

Con esos parámetros, las poblaciones de lobos y ovejas se mantienen en el tiempo de manera cíclica.