Acabados automáticos mediante Microsoft Excel y Dynamo
Durante el desarrollo de proyectos con Revit es común que, según las necesidades de cada proyecto y los usos BIM previstos, sea necesario modelar los acabados de los muros de las habitaciones como un elemento independiente para garantizar una mayor precisión a la hora de extraer las mediciones del modelo.
El modelado de los acabados puede suponer un incremento de tiempo de modelado, ya que tenemos que modelar por separado el núcleo del muro y los acabados de cada una de las caras como elementos independientes.
En entradas anteriores del blog hemos podido ver cómo con el uso de Dynamo podemos automatizar procesos de modelado para reducir los tiempos de modelado. Durante el desarrollo de esta entrada veremos como podemos automatizar el proceso de modelado de los acabados de las habitaciones mediante el uso de Excel y Dynamo.
Consideraciones previas
Para que el script que vamos a desarrollar funcione correctamente, deberemos tener unas consideraciones previas a la hora de generar la hoja de Excel que nos permita, posteriormente, obtener la información para el modelado de los acabados:
- El nombre de la habitación debe ser el mismo tanto en Excel como en el modelo de Revit.
- El nombre del acabado de la habitación debe ser el mismo tanto en Excel como en el modelo de Revit.
- Los muros de acabados deberán estar creados en el archivo de Revit antes de la aplicación del script.
Teniendo en cuenta estas consideraciones, desarrollaremos una hoja de Excel para poder introducir la información al modelo mediante el uso de Dynamo.
Desarrollo del script
El script estará dividido en tres bloques que permitirán la creación automática de los acabados en nuestro modelo de Revit desde la hoja de Excel:
- Obtención de datos desde Excel. Mediante el nodo Data.ImportExcel obtendremos la información a partir de la hoja de Excel que habremos creado anteriormente. Esta información la utilizaremos para relacionar que acabado del modelo de Revit será aplicado a cada una de las habitaciones.
- Obtención de parámetros de las habitaciones. Deberemos obtener varios parámetros que nos permitirán definir los atributos de los muros de acabado que se van a modelar automáticamente. Con el parámetro “Nombre” de la habitación y la información de la hoja de Excel obtendremos el muro de acabado que se va a modelar en cada habitación. Con el parámetro “Altura sin límites” obtendremos la altura de la habitación y la utilizaremos para definir la altura de los acabados.
Finalmente, con el nodo Room.Boundaries del paquete Clockwork, obtendremos el perímetro de las habitaciones y los muros que las delimitan. Estos elementos serán usados posteriormente para el modelado automático de los acabados.
- Creación de acabados de muros. Una vez hayamos obtenido los parámetros anteriormente mencionados, realizaremos un desfase del perímetro de la habitación para obtener la línea de referencia que utilizaremos para crear el muro. Para que este proceso sea automático, obtendremos el valor “Anchura” de cada uno de los muros de acabado y el valor de desfase del perímetro variará en función de la anchura del acabado.
Una vez hayamos realizado el desfase del perímetro de la habitación, usaremos el nodo Wall.ByCurveAndHeight para dibujar los muros de acabado. Para ello, deberemos usar como input del nodo la curva perimetral de la habitación con el desfase aplicado, la altura de la habitación obtenida anteriormente, el nivel en el que estamos trabajando y el tipo de muro de acabado que queremos modelar en cada habitación.
Finalmente, utilizaremos el nodo Element.JoinGeometry del paquete Clockwork para unir los muros de acabados con los muros delimitadores de la habitación que hemos obtenido anteriormente mediante el nodo Room.Boundaries. De esta forma, se unirán los muros delimitadores con los acabados y se realizarán automáticamente en los muros de acabado los huecos correspondientes a muros y puertas.
Conclusión
Como hemos podido ver en esta y en otras entradas del blog de MSI Studio, el uso de scripts de Dynamo nos permite automatizar tareas que pueden resultar tediosas de forma automática. De esta forma conseguiremos reducir el tiempo de modelado y podremos invertirlo en tareas que aporten un mayor valor al proyecto y al modelo BIM y que nos permitirá cumplir con las exigencias y necesidades del proyecto.
¿Por qué Dynamo? Vol. IV: Gestión del peso del modelo
¡De nuevo con Dynamo! Y es que hay infinidad de aplicaciones que le podemos dar a esta herramienta. A diferencia de en las anteriores entradas donde veíamos cómo realizar comprobaciones normativas (¿Por qué Dynamo? Vol. II: Comprobación Normativa) o cómo cambiar los valores de un determinado parámetro (Automatización de tareas repetitivas, ¿por qué Dynamo?) en este caso veremos varias rutinas sencillas que nos permitan gestionar nuestro modelo.
Antecedentes
Es habitual intervenir en proyectos en los que
el nivel de madurez BIM de los colaboradores se encuentra polarizado. Unos
tienen mucha experiencia y otros poco o ninguna. Como consultores, confiamos en
las automatizaciones para realizar muchas tareas que son importantes para el
comportamiento del modelo. Esto permite que ellos puedan centrarse en el
proyecto mientras garantizamos que los modelos se estructuran de una forma
correcta con los scripts.
En los siguientes posts veremos algunas ideas que
a través de Dynamo nos podrían permitir aplicar buenas prácticas para la
estructuración de un modelo BIM.
Controlar el peso del modelo
En concreto, en este hablaremos de herramientas
que nos permitan controlar el peso del modelo.
Es común oír la importancia que tiene mantener
un determinado peso en el modelo. Algunos dicen 150, 200, 250 MB… pero la
realidad es que nos encontramos con modelos que pesan más.
Puede ser debido a que el modelo tenga una gran
extensión (lo cual no tiene otra solución que segregar el modelo), un exceso de
información (tanto geométrico como no geométrico), que tenga
configuraciones o familias cargadas que no estén en uso o bien que haya
un exceso de vistas en el modelo.
Peso en las Familias
Hay un eterno debate
entre las familias genéricas y las familias de fabricante. ¿Debo usar familias
genéricas propias y asociar la información del elemento que se ha instalado en
obra, o bien he de descargarme familias realizadas por el fabricante que ya
incorporen la información del elemento?
Bajo mi punto de
vista hemos de usar las familias genéricas propias ya que es la única manera de
controlar la estructura de la base de datos (que todos los parámetros se
llamen igual, que tengan uso específico, conozcamos el funcionamiento de la
familia, etc). A menudo nos descargamos familias de internet y nos encontramos
que estas familias están creadas con taxonomías, parámetros y estrategias
distintas. E incluso con parámetros que no nos interesa incorporar a nuestro
modelo y que queremos eliminar. Dicha información a parte de desestructurar la
base de datos añade peso a nuestros ficheros. Por ejemplo, la siguiente familia
descargada de la red:
Observamos que hay una serie de parámetros relacionados a la disponibilidad del producto en los distintos continentes que no nos interesa añadir al modelo (por razón x). Por lo que deberíamos suprimirlos antes de cargar la familia a nuestro proyecto. Como ya sabéis realizar esto es muy tedioso y hay que invertir mucho tiempo. A través de automatizaciones podríamos llegar a eliminar varios parámetros de una determinada familia. Como vemos a continuación, el primer vídeo muestra cómo eliminar parámetros de una determinada familia.
Vistas
Otro punto
importante para controlar el peso de los modelos son la cantidad de vistas
que se alojan en nuestros archivos. Cuantas más vistas en el modelo más tamaño
tendrán los archivos. Solemos organizar nuestros navegadores de proyecto para
tenerlas debidamente agrupadas, pero sin darnos cuenta generamos vistas
y vistas y eso afecta al rendimiento de nuestros modelos. Cada vez que
accedemos a una zona del modelo necesitamos crear vistas para poder ver en
verdadera magnitud aquello que se está modelando y luego nos olvidamos de
suprimirlas. Es recomendable realizar un control periódico de las vistas
que se generan en el modelo para poder eliminar aquellas vistas que no tienen
un uso específico en el modelo y que se ha pasado por alto su existencia.
Para todo lo
anterior podemos usar dos rutinas:
- La primera es un sencillo script
que nos permite eliminar las vistas que no se encuentran correctamente
ordenadas. Cualquier vista que se pretenda conservar debe estar correctamente
organizada y agrupada en el Project browser. Por lo que si no se
encuentra correctamente organizada se sobreentiende que no tiene un objetivo
establecido y que puede ser eliminada. Normalmente usamos 4 tipos de
agrupación:- WIP
- CONTROL
- EXPORTACIÓN
- IMPRESIÓN
Si alguna vista no se encuentra en ninguna de las anteriores (es decir que se encuentra agrupada en: ???) solemos eliminarla en el plazo de una semana. A continuación, se muestra un vídeo que nos enseña cómo eliminar vistas que no se encuentran ordenadas.
El
Script funciona extrayendo información de todas las vistas agrupables en el
Project Browser (excluyendo en este caso tablas y leyendas) y comprueba que en
los parámetros de agrupación exista algún valor asociado. En caso que no haya
ningún valor asociado se eliminarán las vistas.
- El segundo, es un script que nos permite eliminar todas las vistas que no se encuentran en los planos del proyecto. Al hacer entrega de un modelo en cualquier fase de proyecto solemos eliminar las vistas de trabajo (que corresponden a nuestra forma de trabajar) y dejamos solo aquellas que se usan para extraer la documentación del proyecto. Esta función se puede realizar también a través de Etransmit. De estas dos maneras podremos suprimir todas las vistas de trabajo o control que no forman parte de la entrega y liberar peso del archivo. Como se muestra a continuación, en el vídeo se enseña a eliminar vistas que no se encuentran en los planos.
Esta
rutina se basa en nodos de Orchid y Datashapes para extraer los
parámetros de una familia y crear un front end o cuadro de diálogo
en el que el usuario pueda seleccionar los parámetros que posteriormente se
eliminarán.
Conclusiones
A través de estos
Scripts seremos capaces de gestionar nuestros modelos aplicando buenas
prácticas en lo que respecta el tamaño de nuestros modelos. En el
próximo post veremos más Scripts que nos permitan gestionar nuestros modelos desde
otras vertientes de los modelos BIM.
¿Por qué Dynamo? Vol. III. Clashes
Hoy os mostramos una nueva aplicación de Dynamo que nos permitirá agilizar el proceso de resolución de colisiones para el modelador. A diferencia de las anteriores entradas donde veíamos cómo realizar comprobaciones normativas (¿Por qué Dynamo? Vol. II: Comprobación Normativa) o cómo cambiar los valores de un determinado parámetro (Automatización de tareas repetitivas, ¿por qué Dynamo?) en este caso veremos cómo usar Dynamo para gestionar la resolución de las soluciones.
Antecedentes
Para poder localizar en Revit las colisiones
que detectamos en Navisworks, Navisworks cuenta con la funcionalidad de
Switchback. Esta nos permite visualizar los elementos involucrados en un Clash
de Navisworks en Revit. Para ello necesitamos que ambos programas estén
instalados y que la persona que va a solucionar dichas colisiones tenga
un mínimo conocimiento del funcionamiento de Navisworks.
En el supuesto caso que no queramos que el
modelador tenga conocimientos de Navisworks o que simplemente no tenga acceso a
dicho documento deberemos buscar una forma de trasladar dicha información.
Informes
Existe la posibilidad de trasladar esta
información a través de informes. Estos informes que se exportan desde
Navisworks, pueden encontrarse en distintos formatos como puede ser html.
Puede ser un poco tedioso, o poco intuitivo, usar los informes html de Navisworks para poder gestionar y solucionar las colisiones o interferencias que aparecen en un modelo. Para ello hemos de copiar los códigos Id del informe y pegarlos en Revit, pero requiere de poca preparación de herramientas y de formación nula en Navisworks para los modeladores.
Dynamo
Mediante la rutina que hoy describimos pretendemos usar Navisworks para identificar las colisiones que aparecen en un modelo y ubicar familias en la coordenada de la interferencia exacta dentro de Revit. De esta manera podremos analizar las colisiones sin tener que acceder al informe extraído de Navisworks. Sino que lo haremos directamente desde Revit localizando las familias o “marcadores de colisión” que Dynamo ha puesto por nosotros.
Localización de la colisión
Después de que nuestros modelos sean comprobados mediante un análisis de colisiones, deberemos exportar la información relevante a otro formato que Dynamo sea capaz de abrir y trabajar. En este caso el formato será xml. Al exportar el informe del test desde Navisworks a formato xml decidiremos llevarnos la información que nos permita localizar la interferencia (las coordenadas) y toda aquella información que creamos relevante para incorporarla en los marcadores de los diferentes solapamientos. Como, por ejemplo:
Una vez exportado el informe, el libro de Excel tendrá un aspecto parecido a este:
A partir de aquí y gracias a nuestro Script
seremos capaces de seleccionar las coordenadas de las colisiones y utilizarlas
para colocar las familias marcadoras de la colisión.
Deberemos estar muy atentos en el tipo de coordenadas con las que exportamos el NWC desde Revit. Si son internas de proyecto o si son compartidas. Ya que dependiendo de si utilizamos unas u otras posteriormente en Dynamo deberemos trasponer y rotar dichas coordenadas entre uno y otro sistema. Puede verse dicho proceso en la siguiente imagen.
Las familias marcadoras de las colisiones son unas esferas que se colocan justo en el punto donde se encuentra una colisión.
En ellas tenemos una serie de parámetros que nos
permiten identificar los elementos a los que hace referencia, la profundidad de
la colisión y otros parámetros como la fecha en la que se detectó.
Una vez colocadas dichas familias en el modelo, podemos organizarlas y gestionarlas, así como localizarlas gracias a tablas de planificación como la que vemos a continuación.
Conclusiones
En este caso gracias a Dynamo, hemos conseguido colocar familias a modo de marcadores de la posición de las colisiones en una coordenada concreta. Gracias a esto no obligamos al modelador a utilizar Navisworks para poder gestionar las colisiones encontradas, sino que es capaz de hacerlo desde el software de modelado mediante tablas de planificación.
¿Por qué Dynamo? Vol. II: Comprobación Normativa
En anteriores entradas, que podéis encontrar en este enlace, hablamos sobre una posible aplicación de Dynamo en el contexto de un proyecto real concreto. Allí se nos pedía una cierta estructuración del modelo en base a subproyectos que debíamos cumplir acorde al BEP del proyecto. En este caso, mostramos una aplicación que podemos utilizar en el contexto de cualquier proyecto ya que no es una exigencia BIM si no un beneficio derivado de utilizar los softwares paramétricos y Dynamo.
Antecedentes
Como hemos comentado anteriormente, las automatizaciones se pueden utilizar para realizar tareas repetitivas, gestionar la base de datos del modelo, o para utilizarlo como puente con otros motores de cálculo o análisis. En este caso utilizamos Dynamo para realizar una comprobación a nivel normativo.
Para garantizar unos niveles de iluminación y ventilación
mínimos se establece en diversos documentos de carácter normativo, una
superficie mínima de contacto con el exterior. Esta exigencia mínima suele ser
una fracción de la superficie útil de la estancia o espacio.
Gracias a Dynamo y a unas ciertas configuraciones,
seremos capaces de analizar si nuestro modelo cumple con esta exigencia durante
la etapa de diseño de una forma muy rápida y gráfica. Así podremos realizar
comprobaciones de forma rápida y analizar cuál es la mejor distribución de
oberturas para cada uno de nuestros espacios.
Tal y como se puede apreciar en la imagen anterior, vemos como
los valores asociados a cada una de las habitaciones se actualizan cuando
ejecutamos el script (por eso el cambio de color en las habitaciones de
la vista). Después de haber modificado la distribución de oberturas en fachada
en algunas estancias, hemos vuelto a ejecutar el script para recalcular los
valores y poder comprobar así que las modificaciones nos permiten cumplir con
las exigencias mínimas de iluminación y ventilación.
Para conseguir que funcionara este script tuvimos que realizar
3 tareas principales:
Preconfiguración de las Familias
Es fundamental que las familias que utilicemos estén preparadas para realizar el cálculo previo de la superficie de iluminación natural y de ventilación. Posiblemente es el paso más importante y tedioso de todo el proceso ya que implica entrar en todas las familias de ventana o balconera y crear parámetros relacionados con parámetros existentes que nos permitan calcular estas dos superficies que antes comentábamos.
Es importante destacar que, dependiendo del tipo de ventana, de sus
parámetros y de cómo se haya parametrizado, las formulaciones que utilicemos
variarán. Número de hojas, número de marcos, etc.
El uso de formulaciones es imprescindible ya que, si no fuera así, cuando
creásemos un nuevo tipo de ventana no se calcularían estos valores actualizados
de forma automática.
Script
Por otro lado, necesitamos crear esa secuencia de funciones
o acciones que nos permita obtener el resultado que esperamos (resultado de
la comprobación: “Cumple” o “No Cumple”). Para ello, extraemos la información
necesaria del modelo, la organizamos como necesitemos, realizamos la
comprobación y devolvemos la información del resultado al modelo.
Para realizar un script normalmente utilizamos los “nodos” que se tratan de funciones precreadas. Éstos son sencillos de usar, solo tendremos que conectar la información en sus puntos de entrada y salida. Utilizamos los nodos para desarrollar la programación visual y los extraemos de Packages o “Paquetes” de nodos que han sido desarrollados por terceros (profesionales que son capaces de crear esos nodos, no a través de la programación visual, sino a través de la programación en código). Programar en código es mucho más complejo que la programación Visual (Dynamo), pero nos permite tener más libertad y poder desarrollar cualquier función mientras seamos capaces de imaginarla.
Función a través de Python script
Por lo tanto, cuando necesitemos aplicar una función de la que
no disponemos (ya sea porque es muy personalizada o porque no la encontramos en
los paquetes de otros desarrolladores) deberemos realizarla nosotros.
Estas funciones las desarrollamos a través de programación
en código y podemos realizarla con diversos lenguajes. En este caso, lo hemos
realizado con Python, uno de los lenguajes de programación
más sencillos.
En el script anterior la función que realizamos es comprobar si los valores de las diferentes superficies de iluminación llegan a un mínimo o no. Esta función, que es muy sencilla, podría haberse realizado con otros nodos o funciones y funcionaría de la misma manera.
En este caso optamos por hacerlo con un único nodo para simplificar el script general. Al ser un script que no quisimos ligar a Dynamo Player (por la versión de Revit), necesitábamos que fuera lo más simple posible para que los modeladores pudieran abrirlo y usarlo sin asustarse demasiado al abrirlo.
Conclusiones
Gracias a este script, podemos agilizar el cálculo de la superficie mínima de huecos en fachada y ahorrar tiempo en esta tarea. No solo en un proyecto determinado, sino en todos los proyectos que realicemos, ya que será algo que deberemos implementar siempre. Además, el uso de los nodos personalizados a través del lenguaje Python, nos permitirá particularizar al máximo las herramientas que realizamos y a través de ellas tener el control que necesitamos del proyecto.
Automatización de tareas repetitivas, ¿por qué Dynamo?
Parece irreal, pero a veces nos encontramos con profesionales que son reacios a seguir evolucionando. Acostumbrados al proceso de diseño tradicional, les ha costado mucho la transición entre CAD y BIM, de modo que ahora venimos nosotros y les decimos que han de dar un paso más y automatizar tareas repetitivas. Llegado al punto en el que el proceso se ha sintetizado, es importante determinar aquellas tareas que son repetitivas y a las que dedicamos un tiempo considerable para poder optimizarlas. Pero el hecho que implique un nivel de dominio de las herramientas informáticas mucho más elevado que el necesario para modelar un muro, hace que los profesionales se queden atrás.
Este post pretende poner ejemplos para que estos profesionales
se animen a dar este segundo paso en la implementación de nuevas tecnologías y
busquen optimizar los procesos a través de herramientas de programación visual.
Automatizar tareas repetitivas
La principal ganancia de la automatización de tareas repetitivas es muy
obvia: ¡ahorrar tiempo! Pero los beneficios derivados de esta anterior son
muchos, porque: ¿qué podemos hacer en ese tiempo que no estamos dedicando a las
tareas repetitivas?
Analizar el diseño, analizar la constructibilidad del modelo, analizar los
costes… En definitiva, estudiar, pensar, diseñar mejor el edificio.
Las tareas que podemos automatizar van desde la creación de planos (con sus correspondientes cajetines, ventanas gráficas, tablas, etc., renumeración de rejillas, cambiar el texto de minúscula o mayúscula, etc.
Cualquier tarea que requiera de una repetición es automatizable ya que
sigue un proceso iterativo que se puede predeterminar.
Gestionar la base de datos del modelo
Dynamo es muy útil para gestionar la base de datos del modelo en Revit debido a que nos permite acceder a cualquier parámetro y su valor de cualquier elemento del modelo. Admite personalizar la manera en la que queremos ver la información y, sobre todo, exportarla en distintos formatos.
Nosotros, con Revit y tablas de planificación, podemos extraer información a Excel, pero lo tenemos que hacer por categorías, cosa que es muy tediosa. Con Dynamo, podemos combinar información y volcarla en un Excel para hacer algunos cálculos y luego traer esos cálculos de nuevo a Revit.
Por ejemplo, extraer las superficies de ventilación de cada una de las ventanas de una habitación, comprobar si cumple con la normativa e introducir esa información dentro del modelo con el fin de que el equipo de diseño realice las modificaciones necesarias para hacer que se cumpla la normativa.
Interoperabilidad con softwares de análisis
Antes comentábamos el caso de Excel, pero tenemos otros casos en los que utilizamos nodos para conectar con motores de simulación y análisis. Es el caso, por ejemplo, de LadyBugTools, en el que se crean, lanzan y visualizan simulaciones de iluminación natural (interoperando con Radiance), modelos energéticos (interoperando con EnergyPlus/OpenStudio) y pérdidas o flujos de calor a través de elementos constructivos (interoperando con Berkeley Lab Therm/Window).
¿Cuándo automatizar un proceso?
En ocasiones, automatizar un proceso no es la mejor opción. Cada
situación debe evaluarse de forma independiente para poder determinar si un
determinado proceso vale la pena automatizarlo.
Normalmente me hago algunas preguntas que me ayudan a tomar la decisión:
¿Cuántas repeticiones hay que realizar?
Imaginemos que tenemos que colocar manualmente 5 elementos en 5 coordenadas diferentes. Es posible que tardemos menos colocándolas manualmente que no generando la automatización. Si habláramos de 200 elementos en cambio, sí que saldría a cuenta. Podéis ver un ejemplo donde se vea claro la necesidad de la automatización según el número de repeticiones en este enlace.
¿Cuantos pasos se contemplan dentro del proceso iterativo?
¿El proceso tiene muchas subtareas? ¿Tiene pocas? Es importante porque
esto dificulta mucho el tiempo de ejecución de la automatización. Siguiendo con
el ejemplo anterior. Si hemos de poner 5 placas solares, pero estas han de
estar colocadas en cubierta en la posición en la que reciban más radiación a lo
largo del año será una situación muy distinta a la anterior. En este caso
siguen ubicándose solo 5 elementos, pero en cambio las subtareas que se deben
realizar antes de ubicar los elementos tienen un peso importante: estudio de
sombras, encontrar la mejor posición y ubicarlas.
¿Es replicable en otros proyectos?
Puede que el script que desarrollamos nos ahorre tiempo en un determinado
proyecto, pero debido a que es un proyecto muy singular, no podamos o no
creamos que se pueda reutilizar ese script en otros proyectos.
La complejidad del script
Si usas Dynamo y no tienes soltura programando en código, sabrás tan bien como yo que estás limitado. Estás limitado en función de la oferta de Packages o nodos que puedas encontrar en la red. Hay que dedicar tiempo a la búsqueda de nodos y, en el caso de no encontrarlos, deberemos ver si es posible generar en base a otros nodos más sencillos la misma función que definíamos con aquel nodo que no encontramos.
En función de los nodos y de lo que queramos realizar, el script será más o menos difícil de conseguir. Es muy importante analizar el trabajo que requiere realizar un script para así no dedicar esfuerzos importantes a una tarea que no se podrá replicar en otros proyectos.
El camino del BIM es interminable y las herramientas de programación visual son el claro ejemplo de ello. Nos permiten hacer cuanto imaginemos siempre y cuando seamos capaces de traducirlo al lenguaje de las máquinas. Nos encontraremos en una constante evolución y cada vez usaremos herramientas que nos permitan realizar más cosas. Pero también es cierto que cada vez querremos personalizar más las tareas que realizamos a través de las herramientas informáticas. El sector ha sufrido un gran cambio desde que pasamos del papel al CAD y seguirá evolucionando, por lo que es necesario que empecemos a utilizar este tipo de herramientas para poder desarrollar los proyectos de una forma más sencilla.
Dynamo: caso práctico
Determinados clientes nos exigen a través de
diferentes documentos BIM como protocolos, EIR o “pseudo-BEPs” una determinada
forma de realizar nuestros modelos. En ocasiones esa forma de modelar no es la
más eficiente para nuestra manera de realizar los modelos, por lo que debemos
recurrir a estrategias secundarias que nos permitan crear los modelos de
información de manera óptima a la vez que cumplimos con las necesidades de
nuestros clientes.
Antecedentes
Requisitos BIM
Para un determinado proyecto X, el cliente nos hizo llegar sus requisitos de información para los modelos que se debían realizar. En este
pliego entre muchas cosas, especificaba el software que debíamos utilizar para
generar los modelos BIM. En este caso fue Autodesk Revit. Otro requisito del
proyecto fue que se entregase con una determinada organización del modelo por
lo que respecta a la compartición de proyectos, es decir, los subproyectos o worksets. Se debían configurar
de manera que toda la albañilería se agrupase en un subproyecto, así como todas
las carpinterías juntas, fachadas, pilares, losas, etc.
Esta organización permite categorizar los elementos para poder controlar rápidamente
su visibilidad, tanto en Revit como en Navisworks, pero dada la naturaleza del
proyecto y del equipo proyectista, no era una de las mejores condiciones.
Equipo BIM
Para este proyecto el equipo de diseño solo contaba con un modelador y un
coordinador. El coordinador, a modo de Consultor BIM, daba soporte en ciertas
configuraciones, modelado de elementos complejos, creación de Objetos BIM, auditoría y controles de calidad del modelo, etc.
Pero la persona en la que recaía el peso del modelado era solo un modelador.
Como bien sabemos, los subproyectos o worksets están pensados para habilitar el trabajo de diversos usuarios y en este
caso solo encontrábamos uno, por lo que no requeriríamos de dicha configuración
para realizar el proyecto, salvo en el caso en el que el cliente así lo exija.
Naturaleza del proyecto
Como bien sabemos, en determinados usos y tipos de edificios se intenta
modular el diseño de esta construcción. En este proyecto no iba a ser menos y
contábamos con diferentes tipologías de vivienda que se repetían en diversas
zonas del edificio. Pueden verse en la siguiente imagen:
Este diseño nos forzaba a buscar una herramienta
para modelar que admitiese las repeticiones y, así, optimizar el modelado. En
este caso optamos por el uso de grupos.
Estrategia de modelado
Los grupos admiten solo un único subproyecto, por eso todos los elementos
se asocian al subproyecto del grupo que los contiene. Puede verse un ejemplo en
la siguiente imagen:
Podríamos haber
utilizado múltiples subgrupos y haberlos asociacio al subproyecto que tocase
(grupo de pavimentos, grupo de mobiliario, etc) pero esto hubiera provocado un
aumento considerable del número de grupos y, por consiguiente, el peso del
archivo, además de hacer más “ingobernable” el modelo.
Pero si usábamos grupos por tipología, ¿cómo seríamos capaces de asociar
a cada elemento a su workset?
Solución
La primera opción que planteamos fue desagrupar todas las agrupaciones de
elementos y asociar a cada elemento su subproyecto correspondiente. Después de
realizar esta acción, guardaríamos el modelo como una nueva versión del archivo
y lo mandaríamos para que el cliente lo revisara. Al crear un nuevo archivo sin
sobrescribir el anterior, preservaríamos una copia con los grupos de elementos
para posibles modificaciones o actualizaciones. La parte negativa de esta
acción fue que se trataba de tareas que conllevaban tiempo, tiempo que hay que
invertir cada vez que hay una entrega o una revisión.
Tareas repetitivas y trabajo muy manual. ¡La respuesta estaba clara!
Para siguientes proyectos con unas características parecidas creamos una
rutina a través de Dynamo que nos permitiera
realizar esta tarea de forma automática.
Parte 1: tareas previas a la exportación de la información
La primera parte del script buscaba “explotar” todos los grupos y dejar
los elementos sueltos, sin agrupar. No sé si alguna vez habéis intentado
desagrupar todos los grupos de un modelo (seleccionando los similares y
desagrupando de forma reiterada), pero se trata de un proceso muy tedioso.
Mediante este script los podemos
desagrupar todos de una sola vez, de forma que nos ahorramos tener que
seleccionar todos y cada uno de los ejemplares.
Parte 2: exportación de información
La segunda parte del script, recoge información de los elementos que se
encuentran en la vista activa y los almacena en un archivo .csv. La
información que exportamos puede ser el id, Familia y Tipo, Subproyecto o algún
código identificador como por ejemplo el Código de Montaje.
Parte 3: consulta en la BBDD
Esta acción es la única que se realiza sin que Dynamo o Revit interactúen.
Los datos que hemos extraído del archivo .csv se cargan a continuación en una
hoja de Excel. Esta actúa como base de datos donde consultamos qué subproyecto
corresponde a cada uno de los códigos de montaje. De esta manera, en función
del valor del Código de Montaje que tenga guardado el elemento se asociará un
Workset u otro.
Parte 4: carga masiva de datos
En la última parte del proceso, a través de Dynamo se consultan los valores
de Workset para los distintos elementos (Id) y los asocia a todos los elementos
del modelo. Esta parte del Script será la que más tarde en ejecutarse debido a
que cogerá todos y cada uno de los elementos del modelo y los colocará en el
workset apropiado.
Gracias a esta rutina, somos capaces de ahorrarnos cerca de un 75% del
tiempo que conlleva desagrupar y asociar Worksets a los elementos. Obviamente,
requiere de un tiempo de adaptación si es que se han de cambiar los
subproyectos entre proyectos, pero nos permitirá poder trabajar a nuestra
manera cumpliendo con las exigencias del cliente. Además, al ser algo que se
ejecuta de forma automática, mientras se lleva a cabo la asociación de valores,
podremos desarrollar otras tareas que no tengan que ver con el modelo.
A continuación, podéis ver un fragmento de video en el que se visualiza cómo se realiza la carga masiva de dato, cuarta parte de la solución.