Asunto MBA-093: Modelo compartido que desaparece en la copia local

Problema:
Al copiar un modelo compartido o Archivo Central para crear un nuevo proyecto a partir de uno anterior (por ejemplo, una nueva versión de un mismo edificio) en otra carpeta, ocurre un fenómeno inexplicable con Revit 2010: al crear una copia local (que ocurre automáticamente cuando está seleccionada la casilla "Crear nuevo archivo local" en la caja de diálogo Abrir , el modelo desaparece y sólo se conservan algunos elementos (líneas, secciones, etc.). Nada es visible en ninguna vista y sin embargo el archivo sigue pesando los Kbytes originales. Lo peror es que tampoco puede volver a abrirse el archivo central por sí sólo para crear una copia local con el antiguo método de Guardar como... ¡¡¡¡¡¿Pero qué puede esta ocurriendo?!!!!!!

Solución:
Pues una pequeña simpatía escondida en el menú Abrir: asegúrese de que tenga seleccionada la opción "Todo".

---

Asunto MBA-082: Modelos vinculados - control de visibilidad

Una forma de trabajar proyectos constituidos por muchos edificios diferentes, es emplear el recurso de los vínculos entre archivos .rvt. Un proyecto Revit (.rvt) para un edificio A, está constituído de otros tres edificios complementarios, B, C y D. Los tres últimos son modelos independientes (en sus propios archivos .rvt) que se insertan o vinculan en el modelo anfitrión A, y serán documentados, o sea, aparecerán en planos, dentro del archivo del modelo anfitrión A.

Este método permite una forma de trabajo colaborativo, al mismo tiempo que facilita el trabajo en cada uno de los archivos vinculados, manejando en forma independiente niveles, líneas de ejes, secciones, vistas en elevación, simbología, etc.

Sin embargo, el procedimiento no es trivial y es más poderoso de lo que se puede uno imaginar, si aprendemos a controlar los modos de visualización que adopten los vínculos en cada vista del modelo anfitrión. El primer problema se produce en el modelo A cuando insertamos los vínculos. Analicemos el escenario:

• el modelo A tiene líneas de niveles, ejes, secciones, etc., que le son propios. También contiene símbolos o etiquetas de todos los elementos tales como puertas, muros, etc. que están incorporados a él. Pero los modelos vinculados llegan como un bloque con sólo los niveles y los ejes visibles, y todos sus componentes son virtualmente inaccesibles. Para acotar, habrá que trazar encima., y no se podrán etiquetar sus componentes.
• los niveles de los modelos vinculados no se pueden ajustar. No hay forma de alcanzar las líneas de niveles para controlar su extensión, etc. A veces, se superponen con los del modelo A en forma redundante o "sucia".

Revit ofrece muchos recursos para controlar la visibilidad de los modelos vinculados. En las "Propiedades de vista..." y "Modificaciones de visibilidad/gráficos" podemos encontrar las herramientas adecuadas.



Esta caja de diálogo reserva una lengüeta específica para controlar la forma de visualización de todos los Vinculos Revit en esa vista en particular, incluso sus instancias o ejemplares (cuántas veces está repetido un mismo vínculo, por ejemplo, para edificios repetidos en un conjunto). La lengüeta Básicos ofrecerá tres las alternativas de control: Por vista de anfitrión, Por vista vinculada y Personalizada.



Transcribimos y comentamos las instrucciones de la Ayuda de Revit:

• Por vista de anfitrión. Al seleccionar esta opción, no podrá modificar ningún parámetro de visibilidad para el modelo vinculado, ya que será la vista del anfitrión la que definirá su aspecto. Cuando se configura el modelo vinculado principal como Por vista de anfitrión, cada copia o ejemplar de ese archivo vinculado puede modificarse individualmente si se selecciona Modificar configuración de visualización de este ejemplar. Esta opción aparece en la ficha Básicos cuando se selecciona una copia o un ejemplar de un modelo vinculado principal en el cuadro de diálogo Modificaciones de visibilidad/gráficos. Este método hace que domine por sobre el vínculo las condiciones de visualización de la vista anfitriona. Las propiedades del modelo vinculado se pueden definir caso a caso utilizando la opción Personalizada de la ficha Básicos, y habrá que activar, también como personalizadas, las fichas relativas a Categorías de anotación y a Categorías de modelo.
• Por vista vinculada. Al seleccionar esta opción, puede elegir la vista de proyecto que se mostrará para el modelo vinculado. La lista Vista vinculada contiene todas las vistas disponibles de plano, plano de techo reflejado, sección, alzado y 3D existentes en el modelo vinculado. La lista depende de la vista a la que esté aplicando actualmente la configuración de visibilidad y gráfica. Por ejemplo, si está utilizando una vista de alzado, sólo aparecerán vistas de alzado en la lista Vista vinculada. En las vistas 3D, la lista se llenará en función del tipo de vista 3D que esté visualizando actualmente (si está viendo una vista 3D en perspectiva en el modelo anfitrión, sólo se mostrarán vistas 3D de la visualización del modelo vinculada en la lista Vista vinculada, y lo mismo ocurre con las vistas 3D ortogonales). Nota: Si el modelo vinculado tiene anotaciones que desee mostrar en el proyecto, éstas deben encontrarse en una vista de plano, de plano de techo reflejado, de sección paralela o de alzado paralelo en el modelo vinculado. (Si selecciona una vista en·sección o de alzado no paralela, los elementos específicos de la vista, como los detalles y las anotaciones, así como el aspecto específico de la vista de los elementos que no sean específicos de la vista, como las directrices y las extensiones de referencia, no se mostrarán). Puede seleccionar la opción Por vista vinculada o Personalizado para seleccionar la vista que se mostrará en el proyecto. Este es el recurso que más eficazmente permite que se pueda "aprovechar" el trabajo en equipo, ya que otros colaboradores podrá preparar todas las anotaciones pertinentes en los modelos mismos y dejar vistas (elevaciones, secciones, plantas, etc.) listas para insertarlas en el proyecto anfitrión. Desde el proyecto anfitrión, solamente se hace referencia a estas vistas sin posteriores ediciones.
• Personalizado. Al seleccionar esta opción, puede seleccionar los parámetros de modificación en todas las fichas disponibles. Al seleccionar esta opción quedan disponibles los controles de Vista vinculada, Rango de vista, Fase, Filtro de fase, Nivel de detalle, Disciplina, Estilos de objeto, Vínculos anidados. En cada una de ellas puede definirse si prevalece el modelo anfitrión o la vista vista del modelo vinculado.
  

Por medio de la opción de control de Estilos de objeto, por medio de la cuál se comanda si el aspecto gráfico de los objetos (colores, grosores de línea, etc.) se basa en la configuración definida en el cuadro de diálogo Estilos de objetos del archivo anfitrión o del modelo vinculado, también puede recuperarse la ordenación de las líneas de niveles, extensión de líneas de ejes, etc., de las vistas del modelo vinculado. V el ejemplo siguiente:



Este odenamiento es posible con alguna dificultad: en teoría, debiera adoptarse automáticamente al seleccionar el método "Por vista vinculada", sin embargo en Revit Architecture 2009 (no sabemos qué sucede en la versión 2010) aparentemente requiere de alguna suerte de regeneración. Para conseguirla hay que activar primero el método "Personalizado" y luego cambiar (esto, sin sentido lógico) la opción ahí seleccionada como un "toggle". Esto forzará la regeneración de la vista con las características de la vista vinculada (no conocemos, por el momento, otro método mejor).

Lamentablemente... , de sesión en sesión, Revit olvida este setéo del estilo de las líneas de nivel, ejes, etc. y hay que reahacerlo cada vez obligándolo manualmente a releer esas características del archivo vinculado.

---

Asunto MBA-055: Sistema operativo en el servidor y Trabajo en grupo

Presentamos este asunto todavía sin solución, con el propósito de provocar la discusión de experiencias que puedan ser provechosas para la comunidad de usuarios.

En forma creciente, estamos experimentando problemas de lentitud (ya exasperantes) en el proceso de guardar al archivo central con un proyecto Revit cuyo archivo .rvt ya alcanzó los 180Mb. Un archivo de ese tamaño toma unos 10 a 12 minutos. La consecuencia es que los usuarios dejan de guardar a la central; sólo lo hacen al archivo local, y van dejando elementos tomados que tardan mucho en ceder. A esto debe agregarse el hecho de que cada vez que se modifica un elemento, Revit registra o consulta su estado con el archivo central para evitar que dos usuarios lo editen simultáneamente y con ello se pierda el trabajo del otro. Esta verificación con el archivo central también es lenta y representa una constante demora, a pesar de que el usuario esté evitando grabar a la central sin ceder los elementos reservados.

La situación actual en nuestra oficina en relación con el hardware y software de red ha llegado a ser claramente deficiente con Revit. El servidor dedicado está muy bien, pero corre Netware 4.2 y el switch es 10BaseT. Principalmente este último es un cuello de botella que estrangula el tráfico. Pero también el sistema operativo Netware 4.2 no transfiere paquetes grandes de información.

Sin embargo, la necesidad de instalar un nuevo sistema operativo (SO) en el servidor nos ha hecho descubrir que existe un problema ya conocido de velocidad de grabación al archivo central, independiente del SO del servidor y que se habría desencadenado con Revit 9.1 y que aún hasta Revit Architecture 2008 sigue pendiente. Ver el siguiente foro de AUGI: http://forums.augi.com/showthread.php?t=63786&highlight=Windows+server+2003
que aborda el tema "Guardar en Windows Server 2003 es muy lento" y que concluye en que no sería problema de SO de red.

Novell Netware

En el siguiente link, http://forums.augi.com/showthread.php?t=19440&highlight=Netware, un usuario de AUGI indica una solución para el problema y dice que, cambiando ciertos parámetros en la configuración del servidor y del cliente (relacionados con el cache de archivos), la velocidad de grabación aumenta en 3 veces y la consulta al panel de subproyectos responde instantáneamente. Los parámetros son:

• en el Servidor, Level 2 Oplocks Enabled debe estar en "ON".
• en el Cliente, deben estar activas las funciones de Ajustes avanzados "File Caching" y "File Commit".
  

El parámetro File caching (caché de archivos) controla si el cliente almacenará los archivos localmente o no. File Commit controla si los buffers creados por una aplicación se almacenarán en el servidor. Si se ajusta este valor en Activado, se garantizará la integridad de los datos a costa del rendimiento. Así, se asegura que los buffers de archivo se almacenen en el servidor cuando una aplicación los cree.

Oplocks (Oportunistic locking) está relacionado con el cache de archivos y habilitarlo aumenta sensiblemente el número de veces que una estación de trabajo lee/escribe en el servidor agrupando paquetes pequeños de data y transfiriéndolos agrupados en grandes grupos. las aplicaciones que transfieren datos en pequeños paquetes (¿Revit?) se benefician de esta función. Lamentablemente para nosotros, Netware 4.2 no tiene la función Level 2 Oplocks que existe desde Netare 5.1 (con sp6) en adelante.

Proyecto de solución

Evidentemente, la solución pasa por una actualización de hardware y software. Nos hemos propuesto el siguiente itinerario:

1. Descartar el problema del cableado y del switch: instalar un nuevo switch 10/100/1000T con el cambio de las correspondientes tarjetas de red en cada estación de trabajo y un cableado de Categoría 5 o 6 para alcanzar el mejor ancho de banda posible.
2. Instalar un nuevo servidor dedicado de tal manera que, sin interrumpir el trabajo, pueda despejarse la parte del problema que dependa del equipo. El propósito de un segundo servidor es desvincular la red el actual en forma controlada, impidiendo que le imponga a todo el sistema procedimeintos lentos de los que no se pueda prescindir.
3. Estando la cuestión del hardware despejada, la pregunta pendiente será la de la elección del SO.
   

Otros sistemas operativos

Windows Server 2003 R2 o 2008

En materia de SO pagados el producto de elección por costo parece ser Windows Server 2003 R2 o el nuevo Windows Server 2008, siendo el primero el más probado y estable. Aparentemente (según foro AUGI antes citado) no hay razones para atribuir el problema de la lentitud de grabación al archivo central atribuibles al SO. Parece ser recomendable que el servidor DHCP y DNS residan en el mismo servidor central y utilizar IP fijas (según foro AUGI).

Linux

Nuestra elección sería Ubuntu Server Edition. Aquí, sin embargo, no hay experiencias que conozcamos y nos encantaría que alguien contara la suya. Una vez que tengamos operativo nuestro segundo servidor, nos proponemos instalar Ubuntu en el primero.

---

Asunto MBA-045: Trabajo en grupo

Habilitar la capacidad de trabajo en grupo (Worksharing) sobre un archivo convierte el trabajo en ese proyecto en una tarea algo más tediosa al introducir mucho tráfico en la red de computadores. La necesidad de pasar, del ágil trabajo individual de la primera construcción del modelo, al trabajo colaborativo de más personas, implica tener que resignarse a un proceso más lento con muchos choques y esperas.

La razón de esto se debe a que por cada modificación que un usuario efectúa sobre algún elemento existente, Revit verifica que nadie del grupo de trabajo lo haya modificado primero (ya sea reservándose el Subproyecto (Workset) en el que está o tomándolo prestado). Con esto, se salvaguarda el trabajo de cada usuario y se evita que otro sobreescriba lo que yo ya he cambiado, incluso antes de que yo mismo haya actualizado el alchivo central y los demás usuarios hayan cargado lo más reciente.

La consecuencia de este procedimiento (muy seguro e indispensable, por lo demás) es el aumento del tráfico de red. En nuestro caso, la situación es mala debido a que el sistema operativo que corre en nuestro servidor es Novell Netware 4.2, que ya está muy anticuado. El inconveniente que se nos presenta es que el tamaño de los paquetes de información que viajan por la red es muy pequeño, asunto que entendemos está superado con las versiones más nuevas de Netware o en servidores que corren Linux.

En la práctica de trabajo en grupo, Revit recomienda el uso de subproyectos (Worksets). La idea es agrupar elementos de un proyecto que requieran ser editados en conjunto y que puedan reservarse para un usuario sin la intromisión de otro. Por ejemplo, dividir el proyecto de tal forma que todos los muros que conforman fachadas estén en un mismo subproyecto, o todas las losas, columnas y vigas en otro, etc.). La idea es que un usuario que necesite trabajar en las fachadas, se apropie de ese subproyecto y lo ceda sólo cuando haya terminado su labor. Los demás miembros del equipo podrán guardar al archivo central y cargarán lo más reciente actualizando su propio modelo local todas las veces que quieran, pero no podrán intervenir en la fachadas hasta que el propietario no haya cedido el subproyecto.

Según nuestra experiencia, a pesar de la claridad del método anterior, los mejores resultados los hemos obtenido haciendo caso omiso de los subproyectos. Es decir, salvo para ejes y niveles, todo lo demás va a parar al Subproyecto 1 (es decir, dejamos todo tal cual Revit lo deja luego de habilitar el trabajo en grupo) y nadie nunca se apodera de nada. Dejamos que todas las apropiaciones sean del tipo "elemento prestado" (borrowing) y por ende muy dinámicas.

Con esto hemos conseguido:

a) todos se ven estimulados a grabar a la central frecuentemente

b) todos se apropian sólo del elemento específico que necesitan editar

c) se disminuyen las zonas paralizadas del proyecto dado que los subproyectos, por específicos que sean, tienden a agrupar más elementos que los deseados

d) se reducen los choques y tiempo de espera

Esto no acelera el tráfico en la red, pero a toda la operación le resta la "sensación" del prójimo y una buena parte de la agilidad del trabajo individual se recupera.

---

Asunto MBA-025: Subdividir un proyecto Revit – 2 (colecciones de detalles estándares)

La presentación de un tema como este puede deberse sólo a nuestra ignorancia. Pero, no conocemos otro método para manejar una colección de detalles estándares en Revit que se asemeje a lo que se puede hacer con Autocad en base a archivos independientes insertables como bloques.

Es decir, lo que Revit (parece) no hace, a lo menos con una suficiente fluidez, es permitir insertar detalles anotados provenientes de una biblioteca centralizada; salvo por el método de Copiar-Pegar, entre proyectos Revit, desde vistas de Diseño (Drafting views). Por ejemplo, podemos tener una familia con el dibujo 2D de todos los detalles constructivos de un marco de ventana en aluminio, pero sin textos ni anotaciones. Es decir, no hay familias de “detalles diagramados”.

(nos encantaría que alguien refutara la afirmación anterior)

Hasta aquí, nos hemos preparado unos archivos .rvt que coleccionan detalles afines, como una biblioteca de estándares de puertas y otra de detalles de techumbre y revestimientos metálicos. Estos archivos .rvt contienen detalles diagramados y los guardamos en nuestra biblioteca de familias central. Si en el proyecto de un edificio necesitamos incluir, por ejemplo, detalles constructivos de portones de acero de corredera, entonces:

1)hacemos una copia del archivo 310-Estándares de puertas.rvt desde nuestra biblioteca a la carpeta del proyecto en cuestión
2)luego editamos esa copia incorporándole la viñeta oficial del proyecto con su número de plano específico del caso y agegamos cualquier “retoque” que el proyecto particular requiera.

Cuando alguno de esos retoques constituye una mejora relevante que justifica cambiar el estándar, la incorporamos primero al archivo 310-Estándares de puertas.rvt de la bilioteca central de la oficina.

Asunto MBA-024: Subdividir un proyecto Revit - 1

Este asunto lo presentamos sin resolver, con el propósito de compartir lo intentado y recibir, si la generosidad de los lectores de este blog lo permite, algún feed-back que complemente nuestra ideas... o nos convenza de cambiar de rumbo.

El problema se reduce a dos puntos fundamentales:
1)Cómo subdividir un proyecto que permita manejar un abultado número de planos,
2)Cómo hacer detalles (y planos) estándares en Revit.

El Asunto MBA-024 lo dedicaremos al primer punto, y el segúndo lo abordamos en MBA-025.

El método de Revit que consiste en unificar en un mismo archivo el modelo, las vistas y los planos tiene, entre otras la ventaja de mantener coordinada y coherente toda la nomenclatura y referencias cruzadas para toda la documentación planimétrica del proyecto. Con ello se cumple el lema de la publicidad que dice “si lo cambio aquí y lo cambio en todos lados”.

Sin embargo puede llegar a ser un problema manejar un proyecto con muchos planos o un edificio de gran superficie. El efecto negativo que un proyecto grande produce es el “peso” y la “interferencia”. El primero se debe a la manipulación de un gran archivo que pone en jaque el hardware, no sólo de la estación de trabajo sino también el tráfico de la red de computadores, especialmente en las redes en las que el flujo de bytes se transfiere en paquetes pequeños (por ejemplo, Netware 4.2). El segundo es la consecuencia de habilitar “Worksets” (subproyectos), lo que necesariamente habrá que hacer, y la consiguiente experimentación de choques con otros usuarios del archivo: elemntos reservados, prestados, modelo local desactualizado con respecto al archivo central, etc.

La solución obvia consiste en tratar de subdividir el proyecto en otros proyectos pequeños que puedan integrarse. Para ello vemos que existen dos aproximaciones posibles:

a) La más recurrida consiste en separar en edificios independientes, y es la que podríamos llamar la “subdivisión natural”. Ello supone archivos de proyectos Revit independientes por edificio, con sus series de planos individuales y no relacionadas, por lo menos, no en forma automática. El proyecto en su totalidad todavía está integrado via la importación de los archivos .rvt de cada proyecto subproyecto en otro de conjunto (el terreno, por ejemplo) con el que se comparten coordenadas.

b) La segunda es la “subdivisión forzada” de un edificio, y consiste en agrupar la documentación de un edificio (o un proyecto en general) en grupos o áreas administrativas independientes. El criterio de subdivisión forzada se basa en la independencia de lo representado un plano con respecto al modelo 3D. Por ejemplo, una sección transversal del edificio es dependiente. Los detalles constructivos de un mesón de cocina o los detalles de puertas, ventanas, etc, son independientes, es decir, no necesitan “necesariamente” al modelo 3D para existir.

En otras palabras, todos los detalles que podamos sacar del proyecto principal para detallarlo en base a dibujos independientes del proyecto principal, son suceptibles de ser agrupados en subproyectos independientes.

Hasta el momento, hemos conseguido una subdivisión forzada "sin traumas" para las siguientes series de planos:
- series de detalles de puertas y ventanas
- series de detalles de cubiertas
- series de detalles misceláneos (muebles incorporados, molduras, tabiques, detalles estándares en general)

Pero... El costo de la subdivisión forzada es la pérdida de la coordinación automática, ya que los llamados a detalles que no existen como vistas en el archivo del proyecto principal, sino en el subproyecto independiente, deben hacerse empleando símbolos especiales que imitan un símbolo de llamado normal.

---

Asunto MBA-003: Worksharing: archivo central corrupto. Cómo hacer uno nuevo.

¡Crisis! Por una falla, nos encontramos con la amarga sorpresa de que ya no es posible salvar al archivo central (Save to Central). En nuestro caso, nos ha aparecido el fatídico mensaje:

Data in file XXX.rvt needs to be manually upgraded.
Please contact your Autodesk Revit service provider.

La situación es catastrófica porque ya no hay tiempo para recurrir a Autodesk y enviarle el archivo para reparación. ¿Qué hacer?

OPCION A: Recuperar la información de un respaldo anterior, del menú File>Backups... y seguir las instrucciones del programa. La información que se perderá dependerá de la antiguedad de los respaldos, y la antiguedad de la última versión sin fallas.

OPCION B: Reconstruir el archivo central generando uno nuevo a partir del archivo de trabajo local de la estación de trabajo más actualizada, haciendo lo siguiente:

• En la estación de trabajo escogida para generar a partir de ella el nuevo archivo central, deberá guardarse el archivo local con un Save simple (a la propia estación), y cerrar el alchivo seleccionando la opción Don't Relinquish.
• Cerrar el archivo.
• Volver a abrir e archivo local con File>Open seleccionando Detach from Central.
• Guardar el archivo, ya desligado del antiguo archivo central, en una nueva ubicación (una nueva carpeta en el servidor) con Save As seleccionando el botón Options, y marcando"Make this the Central location after save" (ver figura).

• Crear un nuevo archivo de trabajo para la estación de trabajo haciendo "Save As" al disco duro local.
• Para recuperar el trabajo que las otras estaciones no lograron respaldar en el antiguo archivo central, cada estación de trabajo deberá abrir su propio archivo local con la opción Detach from Central, y volver a guardarlo con Save As en el disco duro de la estación de trabajo (no en el servidor) con un nombre distinto (por ejemplo: Resp-1.rvt). Luego, abrir el nuevo archivo central y generar una nueva copia de trabajo con Save As en el disco duro local ( es decir, del mismo modo que se hizo la primera vez que se habilitó Worksharing para el proyecto). A continuación, copiar y pegar del archivo antiguo Resp-1.rvt al nuevo, y salvar al central.

---

Asunto MBA-002: Worksharing y carpetas asociadas

Cuando implementamos Worksharing en Revit, y se genera el archivo central en una ubicación compartida (servidor de una red local de computadores), Revit crea dos carpetas asociadas a éste:

nombre_archivo.backup
nombre_archivo.log

El tamaño y contenido de estas carpetas puede llegar a ser enorme, al punto que eventualmente se transformen en un serio problema de espacio en el disco duro del servidor de la red. Entonces surgen las siguientes preguntas sobre su contenido, administración y respaldo:

1. ¿Qué contienen? ¿Pueden borrarse estas carpetas?

La carpeta nombre_archivo.backup contiene respaldos incrementales del proyecto y son imprescindibles para la recuperación del trabajo en caso de que el archivo .rvt se corrompa o deba recobrarse un estado anterior de su desarrollo. Por esa razón la carpeta .backup no debe ser tocada. El contenido de la carpeta .log , en cambio, sí puede ser borrado. Nosotros eliminamos periódicamente el contenido con fecha anterior a los dos últimos días, y no hemos experimentado problemas operacionales.

2. ¿Deben respaldarse junto con el archivo .rvt del proyecto?

Para respaldar un archivo .rvt en el que se ha habilitado el trabajo compartido (Worksharing), primero debe abrirse el archivo con la opción Detach from central. Luego hacer Save As en otra ubicación para respaldo.

---