7 Analizando Modelos Basados en Agentes

7.1 Transcripción Janssen

Cuando se habla de usar modelos en investigación , tipicamente queremos usar un modelo para ganar entendimiento de un pregunta especiífica de investigación. Construir una buena pregunta de investigación es uno de los aspectos más difíciles en el ciclo de modelaje. Una manera común de hacerlo es comenzar con teoría y definir que pregunta puede ser contestada con el modelo basado en agentes,una pregunta como:

¿Por qué no más personas usan los carros eléctricos?

es difícil de contestar con un modelo basado en agentes ya que es una pregunta empírica para lo cual lo mejor es realizar aondeos y encuestas con compradores potenciales de carros. Sin embargo podríamos formular una pregunta como:

¿ Basados en nuestro entendimineto del comportamiento de los consumidores y en las tendencias de ventas de carros, cuáles pueden ser las proyecciones de bentas de carros eléctricos hacia el futuro?

Esta pregunta puede ser abordada por una variedad de modelos incluyendo modelos estadísticos. Una pregunta más enfocada a la metodología de los MOBAs podría enfocarse en el rol de la influencia social y la estrudtura de las redes sociales , asumiendo que se tienen dato relevantes de este aspecto. ¿Cuáles son las estrategias que podrían ayudar a la formulación de una pregunta de investigación apropiada? Una es leer publicaciones de implementación de modelos basados en agentes en el área de interés y ver que tipo de preguntas tratan de resolver. Buenas preguntas de invectigación quen usan MOBAs se concentran en como diferentes mecanismos que afectan el comportamiento de agentes y su entorno impactan los resultados que se quieren investigar. Esto no sorprende ya que los modelos basados en agentes funcionan de esa manera. Una vez se define la pregunta de investigación, se pueden definir hipótesis, que ayudan a formular que nresultados hay que investigar y que mecanismos incluir en el modelo, por ejemplo:

*¿ Es la discriminación racial la única causa para la segregación?

Para probar esto podriamos derivar la segregación en un agente donde los agentes son “felices” si la mayoría de sus vecinos lo son. El modelo de Schelling demuestra que la segregación solo suscede si los agentes se sienten bien viviendo en vecindarios donde la mayoría es diferente a ellos. Una vez teneos una idea clara de las preguntas de investigación, podemos comenzar a trabajar en el modelo, también es útil mirar publicaciones de trbajos sobre modelos parecidos. De hecho,es conveniente replicar uno o varios de estos modelos para tener un amejor idea de como funcionan estos tipos de modelos y que retos y desafíos han tenido sus autores. No es inusual que los que los que construyen modelos sean sobreoptimistas en sus ambiciones , entonces observar estos modelos alternativos ayuda a ser más realista sobre el alcance de este tipo de modelos. Un aspecto importante al construir un modelo MOBA es construrilo de la maera más simple posible, pero no tan simple. Esto es más fácil decirlo que hacerlo, De hecho, modelos simples son difíciles y dispendiosos de construir mientras que modelos complicados son más fáciles de crear. Modelos simples, que capturan la esencia de un tema de interés son el resultado de mucha iteraciones y ensayos con el modelo, el modelaje es un arte, como crear una escultura o una pintura, en donde el producto final termina siendo unos pocos brochazos que muestran la esencia de la obra de arte. Use diagrmas de flujo para establecer conexiones entre los diferentes componentes de un modelo:

¿Cuáles son los procesos de retroalimentación?
¿Cuáles son las escalas espaciales y temporales?
¿Qúe tipo de agnetes incluir y cuales son sus interacciones?

Sabiendo que el modelaje es un proceso, no demre todo su tiempo diseñando el modelo. El replicar otros modelos relacionados ayuda a no comenzar de ceros. Implemente sus primeras ideas y encontrará que sus ideas son menos brillantes d elo que pensaba. El proceso de modelación y el observar los resultados de las supocisones del modelo, es un proceso de aprendizaje que le ayudará a redefinir la estructura del modelo. Una vez se tiene una versión inicial del modelo, haga un análisis adecuado. Se dará cuenta que se utilizará mucho más timepo en el análisis que en la construcción del modelo, explore condiciones extremas del modelo y pruebe si el modleo todavía produce resultados relevantes. Cuando empieze a tener confianza en el funcionamiento del modelo puede comenzar a hacer un análisis más formal. Un análisis básico puede ser un análisis de sensibilidad donde se varían los parametros del modelo de manera sistemática. Puede comenzar a variar los parámetros uno a uno para identificar que parámetros impactan de mayor manera los resultados, luego varíe dos parámetros y obseve su covariación, el análisis de sensibilidad le ayudará a entender mejor el modelo y puede producir que se generen modificaciones al modelo e inclusive a reconsiderar la pregunta inicial que dió origen al modelo. Con datos cualitativos se puede construir unmodelo cuantitativo, como las feromonas impactan el movimiento de las hormigas, como se forman caminos de hormigas, como los patrones de vuelos de aves se forman,etc… Si se tiene información cuantitativa,esta se puede usar para definir valores de los parámetros del modelo y también se puede usar para evaluar el modelo, acá entramos en el importante tema de la calibración de un modelo que veremos mś adelante. Cuando se hace un análisis sistemático de un modelo hay que ser crítico acerca del modelo, desconfie de los resultados del modelo y preguntese siempre por qué se dan estos resultados, sobre todos si estos no son obvios ni intuitivos, es frecuente sorprenderse con algunos resultados del modelo, pero al final se debería entender porque los resultados a la,larga resultan no ser tan sorprendentes. Durante el proceso de implementación del modelo, es una buena práctica comenzar a documentarlo. La buena documentación de un modelo basado en agentes no es fácil de obtener ya que estos modelos van más alla de un conjunto de ecuaciones. Un protocolo quen puede ayudar a obtener una buena y sistematica documentación es elprotocolo ODD (ODD protocol) Cuando se tenga el modelo documentado, puede guardar su modelo y su documentación. Un repositorio recomendado es la Libreria de modelos computacionales COMSES NET, Guardar su modelo en la nube ayuda a otros a construir sobre su trabajo y se asegura que hacia el futuro lam documentación no se pierda. Finalmente, ¿Qué se aprende del proceso de modelado? Se pensará que ya no se necesita modelar más cuando ya se tiene un mejor entendimiento del problema, pero siempre es posible mejorar un modelo y aprender de el, cuando vaya a comunicar los resultados de su trabajo y escriba, por ejemplo, un artículo de investigación, haga énfasis en las preguntas de investigación y enfoque la discusión en el análisis del modelo y en como este responde a las preguntas. No tiene ue incluir todos los detalles en el artículo, mueva los detlles técnicos a un apéndice

7.2 Introducción

2364/5000 Un modelo, una vez que se ejecuta de manera confiable en una computadora, es como un laboratorio a la espera de ser utilizado. Anthony Starfield, Karl Smith y Andrew Bleloch, 1990 9.1 INTRODUCCIÓN Analizar un modelo de computadora significa estudiar el modelo, una vez que se ejecuta, para comprender y mejorar su rendimiento y luego resolver los problemas modelo fue diseñado para. Una consecuencia de que IBM sea menos simple que Los modelos clásicos son que los IBM no son tan fáciles de entender y aprender. De hecho, algunos ecologistas creen que los modelos de simulación y los IBM son tan difíciles de entiendo que no son útiles: si un modelo es tan complejo como la naturaleza en sí, ¿por qué no estudiar la naturaleza en su lugar? Evitar solo este problema fue nuestro Objetivo principal en la Parte 1: los lectores de los capítulos 1 a 4 saben que un bien diseñado IBM no es tan complejo como la naturaleza misma. Un IBM bien diseñado captura el esencia de un sistema ecológico con respecto a un problema particular y contiene poco más. Hay más razones por las cuales los IBM son más fáciles de analizar que los sistemas naturales. Tems. Todo en una IBM se puede observar completamente e incluso manipular. Lated Con los modelos de simulación podemos implementar cualquier diseño experimental que puede imaginar, incluida la manipulación de los “organismos” mismos, mientras recolectando cualquier dato que queramos. En comparación con la experiencia de campo y laboratorio. De hecho, los experimentos de simulación son fáciles y libres de ética y logística restricciones; nos permiten examinar escalas temporales y espaciales que son no es factible para sistemas reales (a menudo simulamos miles de años, repetimos- edly); y nos permiten examinar las condiciones (un cambio climático, tal vez) que son muy difíciles de imitar en sistemas físicos. Nuestro punto aquí es que comprender y aprender de IBM requiere esfuerzo especial, pero puede ser bastante eficiente y productivo. Los IBM son como el Microcosmos físicos utilizados en ecología de laboratorio. Se hace un gran esfuerzo en el plan y construir el microcosmos: el contenedor, la composición ambiental redes como el suelo y la luz, los organismos y la instrumentación necesaria para observar los procesos de interés a nivel individual y de sistema. Sin embargo, el ecolo- gist sabe que construir el microcosmos es solo el comienzo: los experimentos deben ser diseñado y realizado antes de que se aprenda algo. Cuando un IBM es construido, el modelador también está listo para comenzar a hacer ecología. Este capítulo trata sobre qué hacer en este momento.

1748/5000 Comenzamos con una descripción general de la fase de análisis del ciclo de modelado, identificando cuatro pasos principales en el análisis de un IBM. Luego describimos algunos estrategias generales para hacer un análisis eficiente y una serie de análisis específicos técnicas sis. En la Sección 9.4 discutimos técnicas que son exclusivas de IBM. Las secciones 9.5 a 9.9 abordan técnicas que también se usan para otros tipos de modelos; Recomendamos encarecidamente que los modeladores ecológicos se familiaricen con la literatura de simulación (por ejemplo, Ripley 1987; Kleijnen y Groenendaal 1992; Law y Kelton 1999; Fishman 2001) para una comprensión más completa ing de estas técnicas. Si bien hay relativamente poca literatura sobre análisis de IBM, el análisis de modelos de simulación en general es un campo altamente desarrollado; Casi todo lo que hacemos puede beneficiarse de los métodos y software establecidos. Antes de comenzar, debemos advertir a los principiantes en el modelado que no subestimen igualar la cantidad de trabajo que se necesita para analizar a fondo un IBM. Analizando un IBM puede tardar diez veces más, o más, que desarrollar el modelo. En el ciclo de modelado (Sección 2.3), las tareas que preceden al análisis son principalmente construcción de herramientas; la tarea de análisis es cuando comenzamos a conducir ciencia, aprender ing acerca de IBM y el sistema que representa y sacar conclusiones de interés general. El análisis debe comenzar tan pronto como un simple borrador de modelo se implementa y procede como un ciclo de prueba y revisión de partes del IBM, luego probando y revisando todo el IBM, y finalmente usando el IBM para abordar problemas ecológicos. Cada uno de estos pasos puede requerir mucho experimentación y, a menudo, el regreso a las tareas anteriores del ciclo de modelado. los La tarea de análisis debe ser la parte más larga, pero más emocionante y productiva. de un proyecto de IBM.

7.3 Pasos al analizar MOBAS

4019/5000 Para comprender todas las razones por las que necesitamos analizar un IBM, piense en todos los razones por las que los científicos son escépticos sobre un modelo de “caja negra” incluso si el modelo La formulación se describe con gran detalle. ¿El software realmente hace lo que la formulación dice? ¿Es la formulación “correcta”? ¿Por qué alguien debería creer? las predicciones del modelo: ¿produciría el modelo resultados similares (o conduciría a conclusiones similares) si se usaran diferentes valores de parámetros o supuestos? ¿Y cómo surgieron los resultados? ¿Qué hicieron los individuos que causaron las respuestas del sistema? En esta sección discutimos qué diferentes tipos de Se necesitan análisis para abordar este tipo de preocupaciones. Análisis, pruebas, y la revisión se describen en la Sección 2.3 como la penúltima de las seis tareas en el ciclo de modelado; aquí, dividimos esta tarea en pasos más pequeños que cada uno tiene Su propio objetivo. Los tipos exactos de análisis y los mejores métodos varían entre proyectos, por lo que proporcionamos pautas generales que los modeladores deben encontrar Fácil de adaptar a sus proyectos. Se pueden omitir algunos tipos de análisis para algunos proyectos, por ejemplo, si un IBM utiliza rasgos individuales o submodelos para procesos ambientales que ya están bien probados en contextos similares, entonces pueden no necesitar más análisis. Y algunas técnicas de análisis pueden ser útiles para diferentes objetivos de análisis: análisis de sensibilidad o robustez, por ejemplo, puede ayudar a validar la formulación de IBM, encontrar un buen parámetro valores y entender el ecosistema que se está modelando. Los siguientes son los cuatro objetivos de análisis que generalmente deben abordarse en el desarrollo de un IBM y su aplicación a un sistema ecológico teórico o aplicado problema. Estos objetivos pueden tratarse como pasos separados en el análisis de un IBM Verificación de software. Antes de poder analizar un IBM en sí, debemos analizar su software para verificar que el programa de computadora implemente fielmente Menciona la formulación del modelo. Este tipo de análisis, a menudo llamado “software verificación”: se trata ampliamente en la Sección 8.5, por lo que no lo abordamos en Este capítulo. Sin embargo, los modeladores deben recordar que el análisis posterior Estos pasos producen invariablemente cambios en la formulación y el software del modelo, y cada cambio requiere documentación y un nivel apropiado de prueba. La verificación del software es parte del ciclo de modelado, no un trabajo de una sola vez. Validación del modelo y desarrollo de la teoría. Después de la verificación del software, la siguiente tarea de análisis suele ser probar y mejorar el diseño del modelo y formulación. Tradicionalmente, esta tarea de análisis se denomina “validación”: es- establecer qué tan válido es el modelo para los problemas que pretende resolver. Tenga en cuenta que el objetivo es establecer qué tan válido es el modelo, no si el modelo es o no es válido: debemos establecer un número de claramente definido criterios para evaluar un IBM, pero rara vez es útil definir un específico estándar para aceptar o rechazar un modelo. En cambio, podemos pensar en vali- dación como reunir evidencia y construir un caso de por qué IBM es válido para su aplicación prevista o para delinear las aplicaciones para las cuales IBM es, o no es, útil. Debido a que los IBM pueden ser estructuralmente ricos, con el surgimiento del comportamiento de la población de rasgos de los individuos y su entorno simulado, validación debe proceder de abajo hacia arriba (Sección 9.3.3). Primero, podemos probar aquellas partes subyacentes de un IBM que no incluyen comportamiento emergente que surgen de interacciones entre individuos y su entorno. Estas las partes subyacentes suelen incluir submodelos que representan el entorno y rasgos no conductuales de los individuos. Por ejemplo, la validación puede comenzar mostrando que el submodelo de IBM para la producción de alimentos, y el submodelos de cómo un individuo se alimenta y crece, todos producen razonable resultados. A continuación, es probable que desarrollar una teoría para los rasgos individuales clave sea fundamental parte de la validación. Se presenta un ciclo para desarrollar y probar la teoría en Capítulo 4, por lo que no prestamos especial atención al desarrollo de la teoría en este capítulo

1811/5000 Solo después de haber probado los componentes de nivel inferior podemos emprender un validación significativa de la IBM completa. En esta etapa, normalmente podríamos parametrice IBM, realice análisis sistemáticos de sensibilidad y ro- busto, examine qué tan bien las versiones alternativas de IBM reproducen un variedad de patrones observados, y ver si el modelo puede tener éxito predicciones independientes (todos estos tipos de análisis se analizan a continuación). Parametrización. — Validación de muchos modelos ecológicos clásicos, y algunos IBM, es en gran medida una cuestión de ajuste de parámetros: los modelos son simples, por lo que su validez depende principalmente de encontrar valores de parámetros que adecuadamente reproducir datos observados Sin embargo, la validez de muchos IBM depende de mucho o más en la estructura y mecanismos del modelo que en el parámetro valores. Por lo tanto, tratamos la parametrización como un paso de análisis separado. Este paso, también llamado “calibración”, implica encontrar buenos valores para parámetros ters que no pueden evaluarse independientemente durante la formulación de submodelos (secciones 7.5, 9.4.2). La Sección 9.8 discute las técnicas de parametrización. Solución de problemas ecológicos. El paso final del análisis es, por supuesto, Viste el problema para el que IBM fue diseñado. Este tipo de análisis puede implican versiones alternativas contrastantes de IBM para ver qué mejor ex observaciones simples de un sistema real, entendiendo la dinámica del sistema que surgen bajo una variedad de condiciones, o predicen respuestas del sistema a opciones de gestión ambiental. Estos análisis a menudo implican tomar un IBM aparte y volviendo a armarlo de diferentes maneras, como se ilustra en secciones 9.4.4 y 9.4.5. Este paso final de análisis es el más importante, pero sus conclusiones serán recibidas con escepticismo a menos que la credibilidad de IBM Se construye a través de los pasos anteriores.

7.4 Estrategias generales para analizar MOBAs

3831/5000 Esta sección presenta tres estrategias generales de análisis que son particularmente valioso para IBM. Estas estrategias no solo hacen frente, sino que en realidad toman ventaja de la mayor complejidad de los IBM. 9.3.1 La estrategia principal: experimentos de simulación La estrategia básica y más productiva para analizar modelos de simulación como IBM es sugerido por la cita de Starfield et al. (1990) con el cual comenzamos este capítulo: debemos pensar en un IBM como un sistema de laboratorio sobre el cual experimentamos para obtener una comprensión científica. Pero como los científicos desarrollan la comprensión? Diseñamos experimentos controlados que Danos, paso a paso, información sobre cómo se comporta el sistema. Nosotros usualmente comenzar con experimentos muy simples, con la complejidad del sistema reducida tanto que fácilmente podemos predecir el resultado del experimento. Entonces nosotros agregue cuidadosamente grados de libertad al sistema, incrementando su complejidad mientras sigue formulando hipótesis que se prueban fácilmente con experimentos. Nuestras predicciones a veces serán correctas, pero a menudo no lo serán, lo que luego nos hace diseñar nuevos experimentos y continuar aprendiendo. Así también es exactamente cómo deben analizarse los IBM: diseñando cuidadosamente y realizando experimentos de simulación controlada. Cuando un modelo se ejecuta por primera vez, es divertido y útil simplemente jugar con él, explorar cómo reacciona a los cambios en los valores de los parámetros, las condiciones iniciales o los supuestos. Pero es Es importante dejar de jugar en poco tiempo y preguntar: ¿qué quiero saber sobre el modelo y cómo puedo diseñar experimentos para aprender? ¿qué quiero saber? El enfoque experimental para analizar IBM corresponde a la induc- El enfoque de inferencia cognitiva a la ciencia primero atribuido a Francis Bacon y ad- expresado por Platt (1964), al que también nos referimos en el Capítulo 4. Cuando tener un trabajo de IBM el ciclo de plantear hipótesis alternativas y luego diseñar y llevar a cabo experimentos para probar las hipótesis a menudo es solo lo que necesitamos para avanzar rápidamente. Cuando, por ejemplo, estamos desarrollando La teoría de la EBI usando el ciclo en el Capítulo 4, usamos nuestra IBM para encontrar el modelo del comportamiento individual que mejor explica los fenómenos a nivel de población. Nosotros plantear teorías alternativas para el comportamiento individual como hipótesis para ser probado, implementar cada hipótesis en IBM, identificar algunos patrones como la “moneda” para evaluar las hipótesis y luego realizar simulaciones que determinan qué hipótesis no pueden reproducir los patrones. Si en cambio estamos utilizando IBM para comprender la causa de algún sistema en particular dinámico (ciclos en la abundancia de la población, por ejemplo), podemos plantear alternativas hipótesis nativas de la causa: quizás fluctuaciones ambientales, den- dependencia de la ciudad en la reproducción, o competencia dependiente de la densidad entre adultos Entonces podemos diseñar experimentos de simulación que intenten excluir cada hipótesis como explicación: si mantenemos condiciones ambientales constante y los ciclos todavía ocurren, luego se excluyen las fluctuaciones ambientales como la única explicación Sin embargo, debemos ser conscientes de que las dinámicas del sistema, como los ciclos, son a menudo causado por interacciones complejas entre procesos como el medio ambiente fluctuaciones, reproducción y competencia. Esta posibilidad significa que si identificamos tres posibles explicaciones para alguna dinámica, y luego con- conduciendo dos experimentos que excluyen dos de las explicaciones, es arriesgado simplemente supongamos que la tercera explicación debe ser correcta. En cambio, también necesitamos prueba la tercera explicación porque la dinámica podría ser causada por meca- nismos más complejos de lo que asumimos. Cuando preguntas simples de “uno u otro” (por ejemplo, “¿las poblaciones están reguladas por procesos ascendentes o descendentes?”) No tenemos respuestas claras (y rara vez lo hacen en IBM y ecosistemas), nosotros debe diseñar experimentos más inteligentes que pregunten y respondan más esclarecedores preguntas

1741/5000 El resto de este capítulo asume que la forma principal en que los modeladores realizan El análisis de IBM es mediante la realización de este tipo de experimentos de simulación. Una vez que un modelador inicia experimentos de prueba de hipótesis con un IBM, el El poder y la fascinación de esta estrategia se hace muy evidente. A menudo un IBM puede usarse de esta manera para analizar muchos problemas distintos de los que fue originalmente destinado para. Los análisis de una trucha IBM por Railsback et al. (2002; que se originó como un proyecto de clase de posgrado) comenzó con el objetivo de probar la capacidad de IBM para reproducir patrones a nivel de población observados En trucha real. Sin embargo, los autores también analizaron las causas de los patrones. Por ejemplo, la dependencia de la densidad en el tamaño de la trucha juvenil (la trucha real era más pequeño al final de su primer verano cuando la densidad era mayor, un patrón reproducido en IBM) fue hipotetizado por los ecologistas que lo observaron en el campo y en el laboratorio como consecuencia de la competencia alimentaria (Jenkins et al. 1999). Sin embargo, esa hipótesis fue excluida en la experiencia de simulación de IBM momentos, durante los cuales el crecimiento y la densidad estuvieron positivamente relacionados. Railsback et al. luego planteó tres explicaciones alternativas y demostró que dos de ellos tampoco fueron respaldados por los resultados de la simulación. Importantemente se requeriría más estudio antes de que estas conclusiones pudieran aplicarse a la trucha real, pero los experimentos de simulación ciertamente indican que el La hipótesis original, más intuitiva, debe ser cuestionada. La simulación ex- Los experimentos también sugieren estudios de campo que podrían probar hipótesis alternativas. (Este tipo de análisis desarrolla rápidamente la creencia en la “navaja inversa de Occam”: explicaciones simples y obvias para el comportamiento de un sistema complejo son muy a menudo mal)

7.5 Analizando bottom up

3111/5000 Tiene poco sentido analizar el comportamiento a nivel de sistema de IBM antes de aumentar la confianza de que el comportamiento a nivel individual del modelo es aceptable, y no hay razón para esperar que el comportamiento individual sea aceptable Por lo tanto, los procesos ambientales que impulsan el comportamiento individual han sido probado Parece evidente que los modelos ascendentes como los IBM deben ser valiosos desapareció comenzando con los niveles inferiores donde emergen los comportamientos a nivel del sistema de. Sin embargo, una de las razones más comunes por las que IBM no logra desarrollar credibilidad ity (además de no analizar el modelo) está intentando analizar el nivel del sistema sin probar primero la validez del comportamiento individual. El fondo de la mayoría de los IBM es una representación de los individuos entorno, porque el comportamiento de los individuos depende en parte del entorno condiciones ambientales Por lo tanto, el análisis del modelo debe comenzar con las pruebas. y validar cómo se simula el entorno. Entonces comportamiento individual puede ser analizado Especialmente importante es probar el comportamiento que surge de los rasgos adaptativos clave de los individuos, porque los más interesantes e im- La dinámica del sistema importante surge de estos rasgos adaptativos; este problema es abordado utilizando el ciclo de desarrollo de la teoría del Capítulo 4. A menudo, es muy eficaz para comenzar a analizar rasgos individuales al contrastar el comportamiento de individuos aislados con el comportamiento de individuos que interactúan con cada uno otro. Un problema obvio con este enfoque de abajo hacia arriba es que el nivel superior los procesos afectan niveles más bajos en muchos IBM: no solo la dinámica del sistema surgen del comportamiento individual, pero el comportamiento individual se ve afectado por el sistema dinámica del tema. Si los individuos adaptan su comportamiento de alimentación a la disponibilidad de alimentos, y la disponibilidad de alimentos depende del consumo de todos los individuos, entonces el comportamiento de alimentación de un individuo se verá afectado por la densidad de población. En algunos IBM, incluso los procesos ambientales más bajos pueden ser afectado por la forma en que los individuos usan los recursos: la producción de alimentos puede ser una función del consumo de alimentos por individuos, por ejemplo. Sin embargo, la estrategia de La experimentación controlada puede superar fácilmente este problema: podemos diseñar experimentos que aíslan el comportamiento en un nivel lo suficientemente bien como para probarlo de manera convincente. Estos experimentos pueden usar escenarios poco realistas (Sección 9.4.5) como la reproducción congelada, la mortalidad y el crecimiento, por lo que el consumo de alimentos es constante. La estrategia de análisis de abajo hacia arriba es importante para la eficiencia, manteniéndonos de perder el tiempo analizando los comportamientos del sistema cuando están adversamente afectado por problemas en los niveles inferiores. Sin embargo, esta estrategia es aún más importante para la credibilidad de IBM con los revisores y otros “clientes” del modelo. Para evitar que los escépticos digan que “un modelo con tantos parámetros los eters pueden calibrarse para producir los resultados que desee”, el modelador debe mostrar que IBM fue parametrizado y probado en todos los niveles els, usando muchos tipos de información; y que los comportamientos del sistema surgieron de rasgos ambientales e individuales que se analizaron de forma independiente antes de examinar los comportamientos del sistema.

7.6 Analizando la estructura

3357/5000 9.3.3 Análisis de la estructura del modelo por separado El hecho de que la incertidumbre ocurra tanto en la estructura del modelo como en los parámetros ter valores es un problema bien conocido en el análisis de modelos. ¿Cómo sabemos si un la incapacidad del modelo para producir algún resultado esperado se debe a problemas con el ¿Ecuaciones y reglas del modelo o con sus valores de parámetros? Clásico simple los modelos no pueden ser probados o analizados significativamente hasta que su valor de parámetro Los datos se ajustan a los datos, por lo que los efectos de la incertidumbre estructural solo se pueden examinar parametrizando y analizando estructuras de modelo alternativas (por ejemplo, Mooij y DeAngelis 2003). Sin embargo, este enfoque puede enmascarar algunos de los efectos. de estructura modelo. Al ajustar cada modelo alternativo a los mismos datos, el los modelos alternativos se ven obligados hasta cierto punto a comportarse de manera similar. Cómo podemos saber si el ajuste de parámetros oculta problemas subyacentes con el modelo ¿estructura? Estos problemas a menudo se consideran intratables; pero para IBMs La estrategia de modelado orientado a patrones ofrece una manera de separarse al menos en parte análisis de estructura a partir del análisis de valores de parámetros. Con IBMs que son ricos en estructura y proceso, podemos seguir un modelo estrategia de análisis que nos permite analizar la estructura de IBM antes del parámetro ización, separando el análisis de incertidumbre estructural y de parámetros para cierto punto. Esta estrategia es simplemente la que se describe en los capítulos 3 y 4: utilice patrones observados para probar y contrastar diseños de modelos alternativos, pero Este análisis estructural se realiza antes de que IBM se calibre o parametrice en detalle. A medida que IBM está diseñado, los parámetros reciben los mejores valores que se puede determinar sin calibrar el modelo completo. Entonces la estructura de IBM La validez natural se puede evaluar probando su capacidad para reproducir una variedad de patrones que capturan la esencia estructural del sistema que se está modelando. Estos patrones pueden ser cualitativos, pero las pruebas pueden ser claras y cuantitativas. Criterios adecuados para determinar si IBM reproduce los patrones: ¿entran las tendencias? ¿la dirección correcta? ¿Alguna respuesta esperada sucede o no? Si algun La versión de un IBM inesperadamente no puede reproducir algunos de los patrones de prueba, Un análisis adicional puede determinar si la falla se debe solo a un mal elección de valores de parámetros. La calibración y la parametrización completas pueden continuar después de que este análisis orientado a patrones haya identificado el modelo más válido estructura. IBM altamente mecanicistas que se han demostrado mediante análisis orientado a patrones El análisis para ser estructuralmente realista a menudo se puede utilizar para abordar muchos problemas con poco o ningún ajuste detallado de parámetros. De hecho, nuestra experiencia (incluyendo El modelo de trucha descrito en las secciones 1.2 y 6.4.2 y el bosque de hayas. modelo descrito en las secciones 1.2 y 6.8.3) indica que si un IBM produce comportamiento razonable: reproducción de patrones generales y cualitativos observados en el sistema real: solo para un rango estrecho de valores de parámetros, es probable algo mal con su estructura. (Sin embargo, a menudo todavía usamos calibración para reproducir patrones detallados; Sección 9.8.) La estrategia de conducir El análisis orientado a patrones de una estructura de IBM primero puede permitirnos comprender y reducir la incertidumbre estructural antes de abordar la incertidumbre de los parámetros. Esta capacidad puede ser muy importante para demostrar que un IBM es más que una caja negra que puede calibrarse para producir los resultados deseados.