Informe final de actividades de Sismología.
Base Antártica Orcadas
Proyecto:
Red Sismológica Antártica.Período: marzo 1997 - noviembre 1997.
Operador: Geof. Julián Brizzi.
Introducción
Las actividades en el área de Sismología, desarrolladas en la Campaña de Invierno en la Base Orcadas, se pueden dividir en cinco partes principales, y en cierta medida correlativas.
1) Instalación de la estación ORCA, puesta en funcionamiento, y prueba de las distintas componentes.
2) Operación de la Estación y adquisición de registros sismológicos.
3) Desarrollo de software específico y configuración de la PC de trabajo.
4) Escritura de un "Manual de Operación" de la Estación Sismológica ORCA.
5) Preprocesamiento de los registros obtenidos.
Como era de esperar, muchas fueron las contrariedades presentadas, pero pese a la complejidad e importancia de algunas de ellas, afortunadamente todas fueron superadas con éxito.
Todo ésto, ha servido para acumular una gran experiencia sobre las distintas situaciones que se pueden presentar, y como sortear las inclemencias con las pocas herramientas con que se cuenta.
No hay que olvidar que el gran aislamiento que tiene la Base juega un papel fundamental para ciertas tomas de decisión, que pasan siempre por un plano más conservador que si se estuviese en un lugar de fácil acceso y fluida comunicación.
Con el fin de organizar de alguna manera práctica la información que se vuelca en este Informe, es que se presenta en primera instancia, un listado de todas las actividades en forma cronológica, separándolas luego en los cinco grupos ya citados para su exposición más detallada.
Cronograma de actividades realizadas
Encuentro con Milton Plasencia y Marcelo Caso (CADIC) en Ushuaia.
Desembalaje y control de inventario y estado.
Búsqueda de una mejor manera de realizar la transferencia disco SCSI a DAT.
La PC 386 se pone a disposición de la dotación, previa protección de sus archivos, para uso general y dictado del curso antedicho.
18:00 hs UTC: Arranque de la adquisición, en forma continua e ininterrumpida, de los registros sismológicos de Base Orcadas.
No se puede bajar la información en memoria al disco SCSI del DAS.
El cambio de parámetros activa la calibración.
El próximo objetivo de estudio son los parámetros de disparo de eventos para Orcadas.
Se optimiza el Batch de cortado de archivos suds, para trabajar con el NC en forma ágil y cómoda (procesa.bat).
Se continúa con las pruebas de parámetros de registración hasta 04/08/97.
Se cambia el modo de funcionamiento del GPS de ciclos a continuo.
Instalación de programas nuevos, y mejora de la configuración general.
En el caso de los archivos horarios, en el mismo paso ya se extraen los sismos cercanos.
Se detecta que no hay 220v (= calefacción) en el abrigo del sensor.
Se regraban los DATs N° Ø5 para dejarlos bajo las condiciones estándar de grabación.
El objetivo es ver si los ruidos de la radio afectan menos a estos canales.
Llegada de la dotación 98. Traspaso del cargo a Milton Plasencia y Nestor Rossi y charla de transmisión de experiencias vividas.
Abandono de Base Orcadas.
Actividades comunitarias realizadas.
Para finalizar, se da un resumen de las actividades realizadas fuera del contexto de la estación, pero que obviamente insumieron tiempo, dedicación, y atención. Son las tareas de orden comunitario, o de colaboración para con los trabajos o personal de la Base. Algunos han sido realizados por propia voluntad, y otros bajo el requerimiento, normalmente, del Jefe de Base. A continuación se enumeran las que se recuerdan, por ser seguramente las más significativas.
Se ofreció el servicio de Guardia de Base, con el SAy. Paez, en los turnos semi periódicos de una vez por semana aproximadamente. Esta consistió de rondas cada dos horas con el fin de cargar combustible al generador en servicio, y anotar parámetros del mismo y de las cámaras frigoríficas, controlar el sistema de calefacción de la casa EGA, y estar atento a cualquier anormalidad que se presentara, llevar la basura para que reciba el tratamiento pertinente, encargarse por completo de la operación del derretidor de nieve, limpiar el baño, despertar por la mañana al personal de la Base, poner en calefacción al Thiokol, etc. También la Guardia se hacía cargo de actividades esporádicas que surgieran como deber, por ejemplo, los domingos era la responsable de hacer de comer y lavar los platos, debía estar informada sobre todas las tareas que se realizaban en la Base y de asentarlas en el Libro de Guardia, etc.
Las tareas comunitarias que se hicieron en conjunto fueron la carga de cajones con nieve para derretir, el despeje de nieve de los accesos, la limpieza de algún sector de la Casa Principal que se iba rotando, construcción de Casa Bote, etc.
De las no comunitarias y normalmente esporádicas, se da un resumen sucinto de las que se recuerda:
Descripción de las actividades y contratiempos de mayor relevancia
1) Instalación de la estación ORCA, puesta en funcionamiento, y prueba de las distintas componentes.
La campaña de trabajo comenzó el 1 de marzo, cuando Marcelo Caso, hizo la demostración de la metodología de trabajo que tenía la estación de Ushuaia. Fue muy didáctico y preciso sobre los distintos pasos de la bajada de datos.
En el CADIC, y luego de la demostración, se efectuó el embalaje de todo el instrumental que se iba a trasladar a Orcadas. A grandes rasgos consistía en: una PC 386 con su monitor, el DAS, el DAT, el GPS, y un grueso manojo de cables.
El primer contratiempo se suscitó antes de pisar el suelo de Base Orcadas. Al arribar a la Base con el Aviso Castillo el tiempo estaba muy ventoso y en consecuencia el mar totalmente picado. El desembarco de personal y equipo se realizó con botes (uno del Castillo y otro de la Base), luego de haber esperado un día completo para que pasara el temporal, cosa que no ocurrió. Por tal motivo, se embolsó todo cuidadosamente, y se realizó la maniobra con un mar muy movido. Al llegar a la costa, las olas provocaron la caída de los tres tripulantes del bote, que traíamos los equipos más delicados (PC, Notebook, DAT, DAS, etc.). Milagrosamente, y ante la sorpresa de quienes buceamos en mar Antártico por unos segundos, el bote no dio vuelta de campana, y aunque le entró un poco de agua, el equipaje no se mojó.
Baterías:
La primer tarea luego de desembalar el equipo y mudar todo lo que ya se encontraba en la base al "Detall" (Casa Principal), fue la puesta en carga de tres baterías con un cargador facilitado por el electricista de la Base. En ese mismo momento se vio la imperiosa necesidad de construir alguna clase de bornera, que permitiera efectuar la distribución de corriente a las distintas componentes del sistema, de una manera segura, cómoda, y confiable. En tal sentido, el electrónico de la Base contribuyó con la construcción de una caja de madera donde poder ubicar las tres borneras a usar. Del resto del armado me encargué personalmente (colocación de la bisagra para la tapa, alojamiento de las borneras, lijado, etc.).
Desde un principio, se dispusieron dos baterías en serie (24V) para alimentar al sensor, y sobre la más negativa, se tomó la alimentación (12V) para el DAT, y el DAS con sus componentes satélite. las mismas no tenían carga a flote, por lo que había que cambiarlas frecuentemente por otras nuevas. Aunque nunca fue necesario dejar sin alimentación al sistema, gracias al interconexionado que se realizaba dentro de la caja de borneras, esta tarea era una maniobra de riesgo (si se confundían los cables...).
Para evitar correr los mencionados riesgos y despreocuparse de la carga de las baterías, que por la falta de un cargador asignado significaba depender constantemente de terceros, es que se pidieron los materiales necesarios para construir un cargador a flote de 24V a 1A. A tal efecto se utilizó un transformador, un rectificador de media onda (1 diodo), y una resistencia casera (tungsteno) para limitar la corriente.
Al tiempo de estar las baterías en carga a flote con esta configuración, se advirtió que debido al desparejo consumo sobre ellas, la más positiva levantaba mucha tensión (16 V). Entonces, se convirtió el cargador, mediante el reemplazo del transformador, para que trabaje con 12V a 1,5A, al que adicionalmente se le sumó un capacitor de filtro. Se conectó sobre la batería más negativa (la de mayor consumo) en forma continua, y esporádicamente (1 vez al mes), sobre la más positiva por un par de días para que recuperara la carga.
Con esta configuración es que se entregó el cargo al operador de la campaña ‘98. Cuando se instalen las nuevas fuentes reguladas para la carga de las baterías, habría que devolver al electricista de cargo, todos los componentes de la comentada fuente casera.
Casi sobre el final de la campaña se descubrió que una de las baterías (la más positiva) no tomaba carga por encima de los 10,5 V. Se procedió a su recambio por una nueva, y se colocó un separador plástico entre el piso y las baterías por temor a que el frío del piso haya sido el responsable del deterioro de la batería en cuestión, la otra posibilidad del inconveniente podría ser la carga excesiva que sufrió unos meses atrás.
Conexionado e inicio de funcionamiento de la Estación:
Volviendo a los comienzos de la campaña, una vez cargadas las baterías y leídas las partes más importantes de los manuales Reftek, se procedió a conectar la caja de control al cable de datos que viene del sensor, y las baterías a la mencionada caja. Se dejó 6 horas para que el sensor se estabilizara térmicamente, y luego se continuó con las conexiones del resto del sistema.
Comenzaban entonces las primeras comunicaciones entre la Notebook y el DAS por medio del "fsc.exe" versión 1995, que era la versión que estaba instalada en la Notebook.. Una de las primeras tareas fue la de transferir el nuevo grupo de parámetros al DAS, según el nuevo criterio establecido para las estaciones de la Red.
Ya que la Estación estaba siendo instalada por primera vez en forma completa, se realizaron varias pruebas de distinta índole, para llegar a comprender lo máximo posible sobre el modo de funcionamiento del DAS y demás componentes.
Bajada de datos:
Una de las pruebas más importantes fue la de conocer las capacidades de almacenamiento de los DAT, y el ritmo de consumo de recursos de memoria RAM y disco del DAS, en bytes y su equivalente en unidades de tiempo. En este sentido se obtuvieron los siguientes resultados:
Con estos datos en mente, es que se descubrió que no era necesario perder una hora de registro cada vez que se efectuaba la bajada de datos. El procedimiento indicado consistía en detener la adquisición, hacer las copias de los DATs, formatear el disco, borrar la memoria, y luego reiniciar la adquisición.
El nuevo procedimiento propuesto para ser implementado en las demás estaciones, permite hacer la bajada de datos perdiendo menos de un minuto de registro. El mismo consiste simplemente en detener la adquisición (grabar todo lo que hay en memoria al disco en forma automática); borrar la memoria; reiniciar la adquisición; y a partir de ese momento, disponiendo de 1 hora y 45 minutos, hacer las copias (<30 minutos por semana por copia); finalmente se puede formatear el disco SCSI.
En otro orden de cosas, de descubrió que aunque cambiando los parámetros de comunicación entre el DAS y la PC se podían transferir más rápido los datos entre ellos, ocurrían problemas serios: se perdía la posibilidad de establecer la comunicación por completo. Se encontró que el "fsc.exe" tiene un error en la grabación del archivo de configuración que hace que un retardo (delay) que existe como parámetro en la ventana de comunicaciones, se grabe como 0, llevando a un conflicto que impide la comunicación DAS - PC. Por lo tanto es recomendable no cambiar esos parámetros e informar a los proveedores del "fsc.exe".
Nivel de ruido:
Otras pruebas fueron las de estudio de nivel de ruido ambiente, y sus frecuencias dominantes para el cálculo de los parámetros a efectos de diseñar los filtros del procesamiento de datos. Se llegó a la conclusión de que la frecuencia dominante es la de 0,3 Hz y en ancho de banda de 0,1 a 0,7 Hz, en la mayor parte del tiempo. Es fluctuante en magnitud, según el viento produzca mayor o menor agitación del mar. En invierno, debido al congelamiento del mar el nivel de ruido baja considerablemente.
2) Operación de la Estación y adquisición de registros sismológicos.
Finalmente, se inició la adquisición de datos sismológicos de Base Orcadas, con la intención de que, salvo indeseables pérdidas, se mantuviese la misma en forma continua e ininterrumpida a lo largo del tiempo. En tal sentido se acordó con Base Esperanza realizar la bajada de datos dos veces por semana en forma simultánea en ambas estaciones. Los días elegidos a tal efecto fueron los lunes y los jueves a las 9:00 hora local (12:00 UTC). En consecuencia, los archivos de 6 horas serían cuatro por día, con uno coincidente con las 00:00 hs UTC.
El registro se produjo en forma ininterrumpida excepto en dos oportunidades:
La primera fue, cuando se realizó un cambio de parámetros para intentar hacer aparecer los pulsos de calibración. Esto produjo un desajuste del DAS resultando que, el disco no aceptó ser grabado por éste, y cuando se agotó la capacidad de memoria, se detuvo la adquisición por falta de espacio. Se descubrió tiempo después, que la nueva versión del "fsc.exe" no es compatible con la unidad DAS de Orcadas (vieja estación de Ushuaia), con respecto al envío de los parámetros de registración. Por lo tanto, desde que se utilizó la versión de "fsc.exe" vieja, que se encontraba instalada en la PC 386 Compac, no se presentó nunca más este inconveniente.
La segunda ocasión de pérdida de datos fue programada, debido a la necesidad de realizar un análisis de ruido.
Análisis de ruido:
A efectos de determinar si la caja de control era la que producía ruidos de alta frecuencia en los registros, se programaron una serie de pruebas entre las cuales por ejemplo, se debía registrar con el cable del sensor desconectado. El resultado de las pruebas dio positivo, por lo que se dejó la caja de control fuera de servicio, puenteada en su interior para no realizar conexiones externas volátiles. Estos ruidos no desaparecieron por completo, pero si se atenuaron en gran medida.
Más tarde se volvió sobre el tema, y mediante un exhaustivo seguimiento de varias semanas, se reveló el misterio. Las emisiones de radio, en frecuencias bajas (3 a 5 MHz), y realizadas con la antena rómbica (única con bobina de ajuste automático de impedancia), eran las que producían el máximo efecto de interferencia. Lamentablemente, esa es la antena más usada, y en invierno y por las noches esas frecuencias son las únicas con buena propagación para comunicarse con el continente.
Se intentó poner a tierra todos los componentes y de distintas formas, pero en vano fueron los esfuerzos por hacer siquiera disminuir los ruidos. Una característica peculiar de estos ruidos es su presencia bien marcada sobre las componentes horizontales, y casi imperceptible en la vertical (relación de 20 a 1). Esto no tiene una explicación lógica inmediata.
Sensor:
Es de interés destacar que la ubicación del instrumento sensor de Base Orcadas, está accesible durante todo el año. Debido a que los vientos corren paralelos a la ladera del Mossman, no se acumula nieve en la puerta del abrigo. Además, durante el invierno se cubre todo el pie del cerro justo hasta esa ubicación, siendo aún más fácil el acceso que en el verano, cuando es necesario trepar por roca suelta para poder acceder al mismo.
El abrigo se mantuvo con temperaturas entre los 9,5°C y los 10,7°C, toda vez que su puerta no haya sido abierta. Nunca hubo problemas con la calefacción excepto una vez en que hubo un corto circuito de la resistencia del pozo de agua de donde se toma la alimentación del abrigo,. En esa oportunidad la temperatura bajó hasta -1°C. Se detectó el problema cuando se midió un salto anormal en los valores de la posición de las masas del sensor al realizar la bajada de datos sumado a que al analizar los registros se apreciaba una variación de muy largo período que confirmaban las lecturas mencionadas.
Por tal motivo dos serían las sugerencias en este tema:
-. Es importante tener un testigo de la existencia de alimentación en el abrigo. Las opciones posibles son: colocar una luz externa en el abrigo para ser controlada periódicamente; o mejor aún llevar una línea de bajo consumo desde el sensor al local donde esté el registrador para tener un testigo luminoso permanente de situación.
-. El otro punto en cuestión, es que la estufa que hay en el abrigo es demasiado grande para el pequeño espacio a calefaccionar, y que sería saludable reemplazarla por una más pequeña, y así contribuir a un mejor uso del sistema eléctrico de la Base.
Pulsos de calibración:
Volviendo al tema del comportamiento del DAS, además de la incompatibilidad con el nuevo "fsc.exe", se le suma la inestable aparición de los pulsos de calibración.
No se ha podido determinar el motivo de la ausencia de dichos pulsos, y no se continuó en la búsqueda de su solución por la recomendación sobre no arriesgar la integridad de los registros por algo de lo que se puede prescindir de momento. Los intentos por recuperar los pulsos fueron la gran mayoría realizados con cambios de parámetros y reiniciación del DAS o también forzando la calibración en forma manual con la ventana del "fsc.exe" diseñada para tal fin, sin éxito alguno.
Sólo dos veces se vieron los pulsos, y se hizo entrega del cargo sin que la calibración se produzca. De todas maneras, el DAS graba el evento CAL, pero algo falla en la transmisión del pulso al sensor o en la generación del mismo.
Canales de registro:
También en una oportunidad en que se estaba escribiendo el Manual de la Estación, se descubre que el DAS tiene, según la versión, los canales 1, 2, y 3 de 16 bits, mientras que los canales 4, 5, y 6 son de 32 bits. Se procedió de inmediato al cambio de los canales de registro, por desconocimiento de con qué clase de unidad se estaba trabajando. Pero por lo visto, esta versión de DAS tiene todos los canales de 32 bits. En otra oportunidad se vuelven a cambiar los canales para ver como afectan al 1, 2, y 3 los ruidos parásitos producidos por la radio.
Transferencia disco - DAT:
Otra falla suele ocurrir a la hora de realizar la transferencia disco - DAT, sin que tal transferencia se efectúe. Se advirtió que para que tal falla no se presente, hay que desconectar la alimentación del DAT antes de conectar el cable SCSI DAS - DAT. Realizando las conexiones en ese orden, y luego introduciendo el cassette correspondiente, no hay inconveniente alguno.
La primera vez que se presentó esta falla, se advirtió luego de formatear el disco. Por tanto es que se procedió a copiar los datos del DAT ‘B’ grabado con éxito, al DAT ‘A’ que no se había grabado en absoluto. Lo antedicho se llevo a la práctica con la ayuda del programa "scsi.exe". Se bajó el grupo de datos nuevos del ‘B’ con scsi read (+parámetros), a un archivo auxiliar, y luego se grabó en el ‘A’ con scsi write (+parámetros).
Un par de ocasiones ocurrió que el formateo del disco no se produjo como se esperaba. Tal vez por falla en el DAS o por descuido del operador, pero la lección que se aprendió fue que es conveniente controlar el estado del disco luego de formatear, confirmando que se encuentren usadas sólo 2 unidades del disco.
Centrado de masas:
En lo que concierne al centrado de masas, sólo en dos oportunidades fue necesario efectuarla. Por tanto se concluye que los sensores se encuentran trabajando de excelente manera. Otras dos veces más se intentó efectuar el centrado, pero sin éxito. Aquí actuó el criterio impuesto a la caja de control, que no realiza el centrado si el equivalente en Volts del descentrado no supera los 1,2V.
Unidad DAT:
El mayor y más grave de los inconvenientes que se presentara en la estación a lo largo de la CAI’ 97 fue la rotura de la unidad DAT. Se redactará de la forma más detallada posible los distintos pasos efectuados en este tema.
El primer síntoma, que quizás no esté en realidad relacionado con la rotura del DAT, fue que durante la bajada de datos del 13/10/97, fue imposible grabar en el DAT ‘A’. Como el ‘B’ no opuso resistencia, se decidió realizar luego la copia del ‘B’ al ‘A’ como en la ocasión antes detallada.
Los intentos fueron en vano, el DAT ‘A’ parecía estar lleno, lo cual era imposible porque el ‘A’ y el ‘B’ eran idénticos y aún les restaban un 30% libre. Por tanto se decidió formatear el ‘A’ y regrabarlo a partir del ‘B’.
Para tal fin se trabajó con la PC 386 (siendo utilizada por primera vez para trabajar con la estación) debido a su mayor espacio libre de disco. Se decidió que en tres tandas se copiarían todos los datos. Pero en el segundo grupo, a la hora de introducir el DAT ‘A’ para ser grabado, éste se trabó a mitad del proceso de carga.
Se intentó por todos los medios normales retirar el DAT, pero no se pudo. Además, una combinación de luces verdes y ámbar intermitentes, ya estaba anunciando que un error grabe había ocurrido. Como no se logró restablecer el DAT al estado normal, se decidió abrir la unidad para retirar así la cinta. Con gran complicación, sobre todo por el desconocimiento del modo de operación de ese diminuto y complejo mecanismo, se logró retirar la cinta, pero el mecanismo continuó trabado, con el mensaje de error aún presente.
Se informó lo ocurrido de inmediato, por tener un panorama muy desalentador ya que sin los DATs no había forma de guardar el enorme volumen de datos que se recolectaban, y además la bajada a la PC se hacía muy complicada y lenta. Se continuó entonces desarmando más partes del mecanismo involucrado en el proceso de carga y descarga del cassette, para comprender su funcionamiento, y tratar de encontrar cual era el problema que le impedía trabajar.
Mientras tanto se estudiaron posibles soluciones para la bajada de datos si fracasaba la reparación del DAT: disminuir la frecuencia de muestreo, cancelar el stream de 6 horas, grabar datos en el disco de la PC 386, y el último ½ Gb dejarlo sin bajar en el disco del DAS.
Afortunadamente, se descubrió que una pieza muy interna y oculta del mecanismo estaba fuera de posición, pero se desconocía su posición correcta. Así y todo, el mecanismo dio muestras de vida, y en ese rumbo se siguió intentando hasta lograr recuperar por completo su funcionamiento.
De todas maneras no quedó perfecto, ya que a partir de ese momento hubo que ayudar al cassette, empujándolo un tramo, para que fuera admitido.
En este momento se supuso erróneamente que el problema estaba superado, pero al intentar leer la información de un DAT, la unidad realizaba muchos intentos de búsqueda, rebobinando una y otra vez y no leía nada en absoluto. Se concluyó que la cinta había perdido su centrado frente a la cabeza giratoria, y se trabajó en este tema para llegar a recuperar la unidad a su estado de operación normal.
Luego de varias prueba - error, se fueron consiguiendo mejoras hasta que finalmente se leyó el DAT, aunque con notable dificultad. De esa manera, aún sabiendo que era posible que se presentaran problemas para leer los nuevos datos grabados, se inició el uso de la unidad.
Luego de dos bajadas se observó que era importante mejorar el centrado del cabezal, y se volvió a abrir la unidad DAT. Esta vez con un resultado muy satisfactorio, ya que se descubrió que los tornillos que permitían realizan el centrado estaban flojos, de forma tal que se pudo dejar el cabezal muy cerca de lo correcto.
Se procedió entonces, a regrabar las bajadas que estaban fuera de estándar, y todo volvió a la normalidad, excepto que los cassettes siguieron precisando la ayuda para entrar en la unidad. Desafortunadamente, se descubrió que el DAT N° Ø4-B que se grabara con los dos formatos diferentes, quedó con una pequeña sobrescritura perdiéndose así unos 3 minutos de registro. No se hicieron otros intentos de tocar los datos grabados en él con el formato fuera de estándar, ya que no tenían copia en el ‘A’.
Hasta aquí llega el relato de las fallas del DAS y periféricos. Queda claro que la estación es muy dependiente de la unidad DAT, que por poseer un mecanismo tan complejo es susceptible de presentar inconvenientes. Es necesario estudiar las posibilidades de hacer más robusto el sistema en este aspecto.
Duración de los registros:
Luego de un tiempo de estar trabajando con la estación, llamó la atención el hecho de que, por mas que los streams tenían 21600 y 3600 segundos, estos valores de duración no se respetaban con exactitud. En consecuencia, el intento por hacer que los archivos coincidieran con una hora en punto solo se conseguía en el arranque de la adquisición, y más aún, entre ellos mismos existía una deriva apreciable.
Luego de intentos por compensar esto, y lectura de los manuales pertinentes, se llegó a comprender el proceso que genera este fenómeno, y la limitación que se tiene para su solución. De todas maneras se llegó a una solución de compromiso en la cual se logró que los archivos de hora y 6 horas no se desfasen más. Esta solución fue la de darle a los archivos horarios una duración de 3610 segundos. Se informó a Esperanza para su implementación pero se desconoce si se efectuó o no.
Como el corrimiento en el tiempo no se pudo corregir, y éste fue tan apreciable como 14min.12seg. por día, se volvió a estudiar el tema, y se llegó a establecer una fórmula que permitía resolver el problema.
Como era necesario cambiar los parámetros de registro, y para mantener un estándar con el resto de las estaciones de la Red era necesario corregirlas a todas en forma homogénea, de manera que se consultó a José Febrer para llevar a cabo la implementación. La respuesta fue, con buen criterio conservadora, para poder estudiar con calma la propuesta.
La configuración de la que se estuvo hablando es la siguiente: los archivos de 6 horas pasarían a ser de 8 horas y 1 segundo (28.801 segundos); y los archivos horarios pasarían a ser de 24 minutos 0,125 segundos (1440 segundos). No se cambian las frecuencias de muestreo actuales.
Con dicha configuración, cada 5 archivos de 24 minutos se cumplirían 2 horas y ¼ segundo de registro. Entonces a las ocho (8) horas se tendrían 20 archivos totalizando las 8 horas y 1 segundo, con lo que ambos registros estarían sincronizados. Además solo habría un desfasaje de 3 segundos-día con la hora UTC lo que haría más coherente su cortado. De esta forma entrarían por día, 3 archivos de 8 horas casi con exactitud.
Una mejora adicional que produciría este cambio es el hecho de que si los archivos fueran de 24 minutos se podrían ver sin problema alguno, y sin preocuparse por tener la PC en el límite de la optimización, ya que las utilidades SUDS solo pueden trabajar, en el mejor de los casos de la configuración de la PC, con archivos de 37000 muestras, esto es lo que equivale a una media hora (para registros de 20 muestras por segundo), por lo que actualmente siempre es necesario, partir los archivos para poder verlos.
Si esto último no fuera importante, o las utilidades SUDS mejoraran sus capacidades de proceso (empleando la memoria extendida o expandida), existiría la opción de usar registros de 2 horas ¼ de segundo (7200 segundos) en lugar de 24 minutos, con idénticos resultados.
3) Desarrollo de software específico y configuración de la PC de trabajo.
Configuración de las PCs:
Luego de trabajar un corto período de tiempo con los distintos programas que permiten operar la estación, transferir los registros a la PC, y ver los resultados y demás labores, se llega a la conclusión de que el ambiente de trabajo de Windows 95 no es el adecuado para hacer que la PC trabaje en forma cercana a lo que es óptimo. Se debe ésto, principalmente al hecho de que todos esos programas son para DOS, y por más que Windows 95, permite abrir ventanas DOS, no deja todos los recursos libres que se pueden desear para DOS.
En consecuencia es que el primer paso en la optimización de la Notebook, para el trabajo con la Estación Sismológica, fue desinstalar el Windows 95, y reemplazarlo por el MS-DOS 6.22 (en castellano).
Esto último produjo, al cambiar el sistema operativo, que se perdiera la capacidad de arrancar la máquina en LINUX. De todas maneras, y con un gran esfuerzo debido a mi falta de conocimiento sobre configuración de ese sistema operativo, se pudo recuperar el arranque con el LILO, que permite elegir entre DOS o LINUX.
Junto con el DOS se instalaron varios programas más, como el Windows 3.11 y MS Office, etc. Se configuró el DOS con un método de arranque múltiple, que permite optar por distintas configuraciones según se desee disponer del sistema en forma óptima para alguna tarea en especial (Utilidades SUDS y tarjeta SCSI, o Windows, o Fortran de Salford).
Así es pues, que se pueden ver en forma completa con "sudspick.exe" archivos de hasta 36.800 muestras (~30 minutos a 20 muestras por segundo), operar la comunicación SCSI libre de fallas, y trabajar con las Utilidades SUDS a la máxima resolución en pantalla que permite la Notebook. Imposibles para Windows 95. Además de las ventajas que reporta trabajar con el "NC.exe" para el manejo práctico, seguro, y veloz de la gran cantidad de archivos que se crean en cada bajada de datos.
Debido a la falta de un importante disquete de configuración de la Notebook DELL, no pude configurar la tarjeta SCSI en su mejor manera, pero, aunque los administradores que se tienen que usar por ese motivo ocupan mucha memoria, los resultados alcanzados son satisfactorios.
A lo largo del año las configuraciones se fueron mejorando, llegando a un nivel que, a criterio personal, no precisan ser ajustadas más. De intentar cambiar los archivos autoexec.bat y/o config.sys, se recomienda tomar todas las precauciones pertinentes para volver a la configuración original, en caso de que se presenten fallas o comportamientos anómalos.
En cuanto a la PC 386, se la dejó configurada para poder ser usada lo mejor posible en cuanto a programas generales (Word 6.0, Excel, etc.), no así para el trabajo en la Estación, para lo cual se le pueden hacer unas cuantas mejoras, tomando a la Notebook como referencia.
En un principio se le dio utilidad para el dictado de un curso de uso de PC para la dotación. Luego se ofreció para uso general de la dotación, pero al ver que esos usos generales estaban muy polarizados hacia el juego y el ocio, se retiró de la sala de computación y sismógrafo, ubicándola en el dormitorio para uso exclusivo del personal de DNA (guardaparques y sismólogo).
Programas y Batch para la bajada de datos.
Extrlog.exe:
Como una de las indicaciones recibidas en Ushuaia fue la de anotar en un planilla los sectores finales del DAT en cada bajada, se empezó a estudiar el contenido de los archivos bajados con scsi log. Se descubrió cual es la información que contenían, que formato presentaban y cuanta utilidad podían tener.
En consecuencia, se creó un programa para extraer los datos de interés que poseían esos archivos. A este programa se lo bautizó "extrlog.exe". Su misión en un principio era la de extraer los sectores iniciales y finales de cada stream, para luego bajar con scsi read los de interés. Luego se le adicionó la capacidad de reconocer los grupos de 6 horas para bajar los archivos horarios y de 6 horas, coincidentes en tiempo. Todo ésto fue pensado en función del uso de "qlook.exe", y en los posibles intentos futuros de bajar del DAT un stream en particular. De esta forma se lograba mucho más que anotar simplemente el último sector del DAT (que de todas maneras se siguió haciendo), que además el "extrlog.exe" mostraba en especial para ser incluido en la planilla de bajada de datos Por ende, en cada bajada de datos se ejecutó este programa con el archivo resultante de scsi log.
En otras oportunidades se volvió a modificar a "extrlog.exe", para mejorarlo. Algunas de ellas fueron las siguientes: la posibilidad de extraer por separado (en otro archivo) las líneas de información general sobre el estado de operación del DAS; la realización de la resta entre el número de sector final e inicial para determinar el largo (en sectores) del stream, que es uno de los datos requeridos por scsi read; etc.
Bajada.bat:
Pero con el descubrimiento de la utilidad del paquete Reftek "ref2suds.exe", se mejoró substancialmente en velocidad y comodidad la bajada de datos a la PC, desligándose del uso de "qlook.exe" (del que se hablará más adelante) para trasformar los archivos al formato SUDS, y de scsi read. para transferir los datos del DAT a la PC. El "ref2suds.exe" baja los datos en formato Passcal del DAT transformándolos a SUDS y creando un archivo independiente para cada stream registrado. Su modo de uso es muy elemental (similar a scsi read).
De todas maneras, se creó un Batch (bajar.bat) para simplificarlo aún más, lo mismo que para la ejecución de scsi log (log6.bat). Luego estos dos se integraron en unos solo, llamado "bajada.bat", que ejecutaba los pasos de los anteriores en forma secuencial.
A "bajada.bat" se le agregaron instrucciones adicionales, para hacer la bajada más segura, confiable, documentada en nivel necesario. En primer instancia se ejecuta scsi scan con los parámetros correspondientes, ya que se plantea un error no existente en realidad, cuando se intenta acceder con "scsi.exe" al DAT por primera vez. Si ya se accedió con anterioridad al DAT, este comando dará un informe sin importancia, sino, dará un mensaje de error y así el próximo comando "scsi.exe" se hará con éxito.
Luego, "bajada.bat" inicia la bajada del archivo log, y al finalizar toca la campana del sistema (beep). A continuación hace un cambio de directorio al lugar donde se bajan los datos sismológicos (C:\DATA\DAYFILES\), y inicia la trasferencia con "ref2suds.exe". Al finalizar manda un comando a la unidad DAT para que ésta expulse el cassette, y por último bloquea el sistema con "blk.exe".
En consecuencia, el operador queda libre durante los aproximadamente 45 minutos que tarda todo este proceso, volviendo cuando lo crea conveniente, y liberando la protección del sistema introduciendo la contraseña pertinente. Luego, debe ejecutar "extrlog.exe" con el archivo log bajado, y después de anotar en la planilla de bajada de datos el sector final grabado en el DAT, concluye la tarea básica que precisa la estación.
Programas y Batch para el reconocimiento y procesado de eventos.
Con respecto al procesamiento que se ha hecho de los datos recolectados, es mucho lo que se ha hecho, sobre todo en software y catalogación de eventos. La primer experiencia de búsqueda de eventos se realizó con "qlook.exe". Se perdió considerable esfuerzo y tiempo en conseguir optimizar la PC para el trabajo con ese programa, ya que su utilidad fue casi nula. De todas maneras fueron los primeros pasos y sirvió para ver los primeros registros y encontrar eventos grandes.
Como el "qlook.exe" no servía mas que para encontrar un gran evento, se empezó a incursionar en los distintos programas disponibles para el procesado de los datos. Se intentó con "sudsplot.exe" y los programas de filtrado y decimado de las utilidades SUDS. Se escribieron varios archivos Batch para utilizar cómodamente estos programas, pero como el "sudsfilt.exe" no funcionaba correctamente (no filtraba las frecuencias altas, y de intentar hacer un pasabanda se filtraba todo), no se podía trabajar adecuadamente.
Se reinstalaron por completo las Utilidades SUDS y Reftek, para intentar eliminar posibles fallas, pero nada cambió. Se rescataron las versiones viejas de la PC 386 pero no fueron de gran utilidad, salvo en el caso del "fsc.exe" que ya se detalló.
Se trató entonces de usar el SAC de LINUX, pero no estaban disponibles los programas de transformación al formato SAC. Y, aunque se consiguió transformar archivos a formato ASCII, y tomarlos con el SAC, el LINUX se comportaba muy inestablemente y era imposible pensar en trabajar de esa manera.
También se dieron algunos pasos con el "pitsa.exe", pero el desconocimiento de su manejo, y la falta de toda documentación, llevaron a abortar el intento. Se trató finalmente de instalar el "Mathlab" de Windows, pero los discos de instalación tenían sectores dañados y la instalación fracasó.
Con este panorama se aceptó la sugerencia del operador de Esperanza (Gustavo Rodríguez), de usar el "sudspick.exe" que aunque era un programa muy elemental y limitado, funcionaba.
Se empezaron entonces a ver los archivos de 6 horas con "sudspick.exe" con un filtro pasabajos cortando en 0,1 Hz. Cada evento detectado era anotado, y se tomaba el tiempo de arribo con la ayuda de una regla y tomando extrema paciencia en el tamaño de ventana usado para mantener la escala.
Cuando un evento era reconocido en los archivos de 6 horas; entonces se trabajaba con los archivos horarios para mejorar precisiones en la determinación de tiempos de arribo. Pero como para ver archivos SUDS con "sudspick" éstos debían tener alrededor de 36.000 muestras o menos (según la configuración de la PC), al principio se hacía una decimación de los archivos horarios (que tenían unas 72.000 muestras) para dejarlos de 10 muestras por segundo. Como al decimar se produce una pérdida apreciable de información, al corto tiempo se optó por cortar los archivos en dos de media hora cada uno, y así verlos sin decimar, aunque en dos partes.
En julio del 97, se detectó un pulso particular en los archivos de 6 horas, que al mirarlo en los horarios resultó ser en realidad un sismo de gran magnitud, con un gran contenido de energía en frecuencias altas (superiores a los 0,5 Hz de los archivos de 6 horas). Era un evento muy cercano (~330 Km.) y fue encontrado por casualidad.
Este hallazgo cambió conceptualmente la forma de trabajo, era imprescindible ver uno por uno los archivos horarios, con filtros pasa altos, para detectar esta clase de eventos. Pero esta tarea podía llevar un tiempo de trabajo superior al disponible.
Procesa.bat:
Entonces, para agilizar este rutinario proceso se generó un Batch que realizaba un cortado e invocado del "sudspick" en forma automática. Este Batch (procesa.bat), además de utilizar la capacidad que posee el "NC" de ejecutar un comando predeterminado cualquiera cuando se pulsa Enter sobre un archivo en particular, agilizó la forma de ver los archivos horarios.
Los dos archivos auxiliares de media hora generados al cortar los horarios, eran borrados al final de la ejecución del Batch, con previa consulta. Esto se hacía así para conservar el archivo de media hora que contuviera algún evento de interés.
Spk.bat:
Adicionalmente, como el sudspick define los parámetros del filtro en un archivo auxiliar, y éstos no se pueden modificar dentro del programa, se tenía que modificar el archivo auxiliar cada vez que se quisiera pasar de utilizar filtros pasabajos, a pasaaltos, o viceversa. Para hacer esta tarea en forma sencilla y veloz, se generaron varios archivos auxiliares (sudsutil.ini) con distinta extensión, para ser intercambiados mediante un simple copiado.
Este copiado se ejecuta con un Batch escrito de forma tal que es necesario sólo invocar un corto nombre (spk) seguido de la última letra de la extensión del archivo que se quiere usar. Por ejemplo para usar el sudsutil.in1 se escribe en la línea de comandos DOS simplemente spk 1 y ya se estarán usando los nuevos parámetros que posea el sudsutil.in1.
Una vez que las cuestiones más básicas del procesamiento, o sea la búsqueda de eventos, se iba agilizando, y ya superada la etapa de pruebas del DAS, el tiempo disponible para el trabajo en la estación fue aumentando.
Determinación de parámetros focales:
De manera tal que se empezaron a inferir distancias epicentrales en los eventos observados teniendo en cuenta en primer instancia las diferencias S-P. Luego se trabajó con los códigos fuente en Fortran de Salford de los programas del IASP91 para la determinación de tiempos de arribo de las distintas fases.
Con estos programas, y luego de introducirles algunas modificaciones pequeñas, se pudo generar un ejecutable que permite calcular los tiempos de arribo, conociendo las coordenadas epicentrales, la profundidad del foco, y hora origen, para Base Orcadas. Usando como base lo realizado en la estación sismológica de La Plata, mediante el programa gtimes.exe.
Como los datos requeridos eran muy difíciles de conseguir en Orcadas, el trabajo tuvo que realizarse con otro procedimiento. A partir de las fases detectadas en los eventos, lograr determinar distancias epicentrales (DE), profundidad (P), y hora origen. Obviamente esto no era fácil, y además con una sola estación resultaba muy impreciso, requiriendo además tablas y/o gráficos de tiempos de arribo con las que no se contaba en Orcadas.
Arribos.exe:
Por este motivo se transformó el programa "gtimes.exe", para que trabaje a la inversa. A este nuevo ejecutable se lo nombró "arribos.exe", y el mismo permitió generar las tablas en cuestión, que se partieron en grupos de archivos independientes para su fácil consulta. Estos archivos son:
Además, se graficaron las curvas de tiempos de arribo según DE, con el Excel (Windows), para la profundidad de 33 Km en dos gráficos independientes: uno con DE entre 0º y 180º, y el otro entre 0º y 15º. Estos gráficos se pudieron imprimir en color, y por cierto a escala 1cm = 1minuto, gracias al préstamo de la impresora personal del Gpque Quintana.
Con estas tablas y gráficos se intentó, estimar las DE y P de los sismos más claramente registrados. De unos ~2.000 eventos detectados en el período del 6/97 al 11/97, aproximadamente la mitad fueron procesados para determinar esos parámetros. En el período del 7/97 al 11/97 se puede decir que el porcentaje de sismos cercanos sobre el total de eventos fue de un ~70%. Sobre estos temas volveremos luego con más detalle.
Arm.bat - arm2.bat - arm3.bat:
Para trabajar más cómodamente, se escribieron tres Batch (arm.bat, arm2.bat, arm3.bat) para cortar y pegar los archivos de media hora resultantes de "procesa.bat" por fecha y hora, y duración en segundos, y así extraer los eventos de interés en una sola pieza del tamaño deseado. La pieza más grande que se puede conseguir con ellos es de hora y media, usando arm3.bat que junta tres archivos de media hora. Más que esto es imposible debido al programa "sudstrim.exe" que invocan estos Batch.
Los archivos así generados eran procesados, anotados los resultados obtenidos, y grabados en un DAT en formato DOS que se preparó para tal fin. Los más importantes fueron comprimidos y conservados en grupos mensuales en la Notebook para referencia rápida futura.
El entusiasmo fue creciendo a medida que se lograba ir aprendiendo como tratar la información recolectada, y comenzó una etapa muy creativa en la que se escribieron varios programas absolutamente inéditos, los que se pasan a detallar a continuación.
Tiempos.exe - Picar.bat:
El primer programa creado fue "tiempos.exe" que permite recuperar, junto con el Batch "picar.bat", y la configuración correspondiente del "NC", los picados de fases realizados con "sudspick" (no más método de la regla para determinar tiempos).
Este programa fue factible gracias al descubrimiento de que el "sudspick", graba los resultados de los picados de fases en el archivo que se esté ejecutando. Pero, lamentablemente, no tiene ningún programa para la recuperación práctica de esa información, que queda contenida en los archivos tratados al salir del "sudspick".
Entonces, para resolver la extracción de esta información, se utilizó el programa conversor de archivos de las Utilidades SUDS "suds2asc.exe". Con determinados parámetros, esta utilidad permite sacar la información general que posea un archivo SUDS, sin extraer los valores numéricos de las muestras sismológicas que contiene. Pero esta información es mucha y variada, y el excedente debe ser filtrado presentado lo útil en forma sintética y clara.
Para este último fin es que fue creado "tiempos.exe". Éste toma el resultado de "suds2asc.exe", y lo filtra, lo procesa, y lo imprime en pantalla y en un archivo con un nombre que hace referencia a la hora inicial del archivo tratado. El proceso que realiza "tiempos.exe", luego de identificar y recuperar la información de interés, es: ordenar el picado por tiempo creciente; transformar la información sobre nombre de la fase a formato de P y S con un número de orden y signo de interrogación si fue pedido (ésto lo decide el operador al picar la fase en el "sudspick"); cálculo de la diferencia de tiempo en segundos y parte decimal de todos los picados con respecto al primer arribo; la determinación del nombre del archivo de resultados en formato de día Juliano, y hora y minutos de la primera muestra del archivo tratado; y finalmente la presentación de resultados.
El Batch "picar.bat" se encarga de: copiar el archivo a ser tratado a uno auxiliar, para conservar el archivo de datos en forma original; invocar al "sudspick" para que el operador realice el picado de fases en cuestión; al salir del "sudspick" ejecuta "suds2asc.exe" con los parámetros correspondientes; a continuación invoca a "tiempos.exe"; y finalmente impone una pausa para que se puedan ver los resultados presentados en pantalla.
Adicionalmente, "picar.bat" antes de realizar todo lo expuesto en el párrafo anterior, pregunta si se sólo se desea Ver el archivo, o si en cambio se desea Procesar. La primera opción sólo invoca a "sudspick" con el archivo auxiliar copiado, y la segunda opción hace lo explicado anteriormente.
Todo esto, Batch y programa, sufrieron varias modificaciones a lo largo del año, para realizarles mejoras en sus funciones, corregir errores, e inmunizarlo contra equivocaciones del operador. Al momento se puede decir que su funcionamiento es más que satisfactorio, y que ha aliviado considerablemente la tarea del operador que desee procesar los datos con este ágil método.
Eventos.exe:
Inmediatamente después de crear "tiempos.exe", el "knowhow" adquirido se aplicó para la escritura de otro programa "eventos.exe", que, con la ayuda del Batch "autocut.bat", permite extraer de los archivos SUDS, los eventos cercanos (contenidos por completo en un archivo de media hora) que se vean con "sudspick.exe".
En este caso, los eventos que se vean con "sudspick" en un archivo SUDS, pueden ser cortados en una forma muy práctica del resto del registro, para conservarlos en un pequeño archivo con un nombre coherente con su contenido y de fácil lectura, y extensión ".orc". Esto se hace picando en un mismo canal del registro que se esté viendo, una fase inicial y otra final cualesquiera entre los puntos que se quieran recortar. Por claridad se recomienda usar una P con cualquier combinación del resto de los parámetros (por ej. P0-E) para la época de principio del corte, y una F para el final del corte. Si en lugar de una P se usa la S como primer picado, la extensión del archivo cortado (".or_") hará referencia a una duda acerca de la certeza de la ocurrencia de ese evento.
Como los cortes P o S y F se van a efectuar en un minuto exacto (o sea con 00 segundos), es necesario controlar que el picado esté entre ±30 segundos del minuto redondo en que se desee cortar. Esta característica está impuesta para mayor prolijidad en el corte efectuado. Se pueden hacer hasta tres cortes independientes por cada archivo visto, uno en cada canal. Si hay más de tres eventos (muy raro) se debe realizar otra vez el proceso con el mismo archivo para extraer en esa segunda oportunidad los eventos remanentes.
Autocut.bat:
El trabajo que realiza "autocut.bat" consiste en primera medida en consultar al usuario por tres alternativas de proceso. Una es (D) dividir el archivo horario en dos, para entonces ser sólo visto en dos partes en forma secuencial; finalmente se pregunta por la eliminación de los dos archivos auxiliares generados. Otra opción (T) es la de Tiempo, que con un truco no muy estético usando "sudstrim.exe", da la época inicial y final del archivo horario en formato de día Juliano; como ésto genera un error, el usuario debe oprimir la ‘y’ en la consulta de sí se continúa o no con el proceso.
La tercera de las opciones (P) es la que permite el cortado en cuestión de los eventos que se observen. Los pasos que sigue entonces "autcut.exe" en esta opción son: cortar el archivo horario en la primer media hora; invocar el "sudspick.exe" para que el operador realice la determinación de los cortes inicial y final si los hubiere que hacer; ejecutar "suds2asc.exe" como antes; luego ejecutar "eventos.exe" con los resultados obtenidos; y llamar al archivo Batch (corta.bat) que genera "eventos.exe", quien realizará el cortado en cuestión; finalmente se repiten los mismos pasos con el remanente del archivo horario.
La labor que realiza "eventos.exe" es apenas un poco más compleja que "tiempos.exe". Primero busca los datos de interés en el archivo resultante de "suds2asc.exe". Si no hay picado, entonces interpreta que no hay eventos y el programa termina con la presentación en pantalla de un cartel indicando que no hay datos de interés en ese archivo.
Si hay picado, "eventos.exe" controla que estos estén bien hechos; si no, presenta en pantalla el mensaje de error que corresponda, y el nombre del archivo que se está usando para que pueda ser vuelto a procesar. Entonces, si todo va bien, efectuará el redondeo de los picados en el minuto exacto, salvo que se esté en alguno de los extremos del archivo, en cuyo caso se redondeará a los 10 segundos dentro del archivo más cercano al extremo del mismo.
Luego, definirá el nombre del archivo en que se guardará el registro extraído, usando la primer época del corte en formato de día Juliano para el nombre, y ".orc" o ".or_" para la extensión. A continuación armará el Batch "corta.bat" que contenga las instrucciones DOS para ejecutar el cortado en cuestión, o sea la invocación a "sudstrim.exe" con los parámetros correspondientes.
Esta forma de trabajo es muy ágil, y se obtienen resultados prolijos sin gran esfuerzo. El proceso es muy práctico y automático, resultando casi transparente para el operador. Los archivos resultantes quedan perfectamente codificados para su fácil reconocimiento futuro. Pero lo que en definitiva se persigue con este proceso, es guardar sólo las partes de interés de los registros, y así ahorrar espacio y comodidad, gracias al tamaño reducido de los archivos de eventos cortados; lo que se consiguió con satisfacción plena.
Ver1.bat - Procesa2.bat - Cortado.bat:
En otra oportunidad, se mejoró la manera de ver y procesar los archivos SUDS con la ayuda de un comando de DOS (for) que permite hacer lazos de repetición de un determinado comando. Con esta idea se escriben "ver1.bat" y "procesa2.bat" para ver en forma secuencial los archivos de 6 horas y horarios respectivamente. En el caso de los últimos, en el mismo paso ya se van extrayendo los sismos cercanos.
Esto agilizó notablemente la búsqueda de eventos, ya que los archivos SUDS se van pasando como diapositivas; al salir de un archivo, se muestra el siguiente, y así sucesivamente. En el caso de "ver1.bat" se carga el filtro ‘1’ preparado para trabajar con estos archivos, y luego se los va pasando uno por uno con "sudspick". El operador debe anotar los eventos que vea para luego cortar y armar los que desee extraer.
En el caso de los archivos horarios, "procesa2.bat" requiere en la línea de comandos la letra final del archivo de filtros que se desee emplear (como con spk.bat). Luego ejecutará en forma secuencial un Batch similar al "procesa.bat" ya explicado, llamado "cortado.bat". Las únicas diferencias entre ellos son que "cortado.bat" no consulta por ninguna opción porque se sobreentiende que lo que se desea es Procesar , o sea, extraer los eventos cortando con "eventos.exe", y la otra diferencia es que al final de cada archivo horario procesado, se mueve éste a otro directorio (C:\DATA\DAYFILES\VISTOS\).
Lo último se hace para que, si por algún motivo se debe interrumpir la ejecución de "procesa2.bat", se pueda continuar trabajando con el último archivo que se estaba viendo. Para interrumpir este Batch se debe oprimir Ctrl^C, y en las tres opciones que muestra el sistema operativo DOS, se debe elegir la ‘A’ (Anular). Si no se elige esta opción el sistema se cuelga porque se genera un conflicto con el administrador de pantalla, y será necesario reiniciar la PC.
Arma.bat - Arma.exe:
Continuando con los programas hechos para procesado está "arma.exe". Éste se escribió para facilitar la tarea del armado (cortado y pegado) de los archivos SUDS cuando los eventos se encuentran contenidos en más de un archivo. Esto suele ocurrir cuando el evento es lejano, y por tanto tiene gran separación en tiempo entre las distintas fases. El "arma.exe" se usa en combinación con un Batch (arma.bat) quien lo invoca, y al cual se le debe indicar en la misma línea de comando, los nombres de los archivos que contienen los registros a cortar (4 horarios como máximo).
El comportamiento de "arma.exe" varía según la longitud del archivo que se requiere cortar. Básicamente, el programa consulta por la época inicial y final del archivo a cortar, en formato de día Juliano (Año Día Hora Minutos, por ej. 97 259 23 45). A continuación, calculará la longitud del archivo en segundos, corroborando que se encuentre entre 1 minuto y 3 horas como máximo, de lo contrario dará un mensaje de error y finalizará.
Si no hay errores, comenzará la escritura del Batch auxiliar "cortar.bat" que tendrá todos los pasos de comando DOS, y evocaciones a las utilidades SUDS "sudstrim.exe" y "sudsjoin.exe", en el orden y con los parámetros correspondientes para realizar el armado del archivo requerido.
El método de trabajo consta en partir los archivos horarios en dos, pegar tres de estas partes (hora y media), y cortar de este bloque media hora con la época inicial solicitada. El proceso se repite con la media hora que le siga y así sucesivamente hasta llegar a la época final requerida. Por último se juntarán todas esas medias horas en un sólo archivo continuo con la longitud pedida. Es conveniente aclarar que entre 1 minuto y 180 minutos (3 horas) se puede conseguir cualquier longitud en saltos de 1 minuto.
Cuando se corta el primer bloque de media hora, se ejecuta "sudspick" con el mismo para que se verifique que el cortado se implementó desde el lugar deseado. Al salir del "sudspick" el Batch preguntará si se continúa o se finaliza (C o F) con el armado. En caso de finalizar no se realizan más operaciones, y se sale del Batch. Se deberá entonces iniciar desde cero el proceso abortado, con los nuevos parámetros deseados.
Si se continúa, dependerá del largo del archivo final la muestra o no del resto de las medias horas. Para más de media hora se mostrará también el segundo bloque; para más de dos horas se mostrará también el tercero. En estos dos casos se preguntará sí se desea borrar (o de lo contrario conservar) esos archivos auxiliares. La primera media hora siempre se conservará.
Esto se hace porque los archivos de más de media hora no se pueden ver enteros, y los de más de 1 hora 45 ni siquiera se podrán cortar en el futuro, al menos con los programas que hay en Orcadas. Los nombres de todos ellos, el entero y las partes de media hora que se conserven, tendrán por nombre el mismo formato que el ya explicado en el caso de "eventos.exe". La diferencia es que el entero tendrá extensión ".or2", por cuestiones de posible cortado posterior con el soft desarrollado.
Nuevamente, se agilizan y automatizan las tareas del operador, dejando a la PC todos los cálculos para armar los archivos, que a mano eran tediosos y requerían un estado de absoluta concentración. Por más que en este programa en particular no se hacen las cosas en la forma más óptima posible, anda y los resultados son los deseados. Igualmente, se consideró el problema del espacio de disco que van ocupando los archivos auxiliares al correr el Batch, por lo que archivo que no se usa más, se borra o se sobrescribe con datos nuevos.
De cambiarse los parámetros de registro, este programa no permanecerá operativo ya que es dependiente de que los archivos de datos tengan una duración horaria. De todas maneras no sería difícil adaptarlos mediante ligeras modificaciones al código fuente. Sin embargo, si se decide que es una pieza útil, lo correcto sería escribir otro programa que realice las mismas funciones pero con otro concepto más racional de trabajo.
Programas auxiliares varios.
Distepic.exe:
Otros tres programitas se escribieron con diferentes finalidades. El "distepic.exe" permite calcular la distancia epicentral con respecto a Base Orcadas, si se conocen las coordenadas del epicentro de interés. Se usa sólo cuando accidentalmente se escucha por radio la ocurrencia de un terremoto grande y seguramente lejano. Entonces se sabrá para ese evento, cuales son las fases a ver a partir de las tablas de tiempos de arribo, y si se encuentra registrado, su procesamiento se puede ayudar con datos auxiliares.
Pos-gps.exe:
El otro de la terna es "pos-gps.exe", que se usó para promediar los resultados de las posiciones calculadas por el GPS de la estación, que aparecen en los archivos log. Con la posición promediada de la antena GPS, sobre ~1200 observaciones a lo largo de dos meses, y la ayuda de brújula y cinta métrica, se hizo el traslado de coordenadas al abrigo del sensor. Los resultados fueron: S 60° 44’ 23,0" ±0,5" y W 44° 44’ 17,5" ±0,5" en el sistema WGS84. También se hizo un traslado de coordenadas al mástil central del Istmo, pero a nadie le interesó el resultado.
Blk.exe:
El último de la terna "blk.exe" fue un programa de bloqueo de la PC en ambiente DOS. Este se pensó en función de mantener cierta seguridad cuando se deja la PC encendida, y es necesario retirarse dejándola a merced de dedos curiosos. Por más que desde un comienzo quedó bien claro que la Notebook no debía ser tocada por nadie, en una oportunidad se encontró que la habían encendido, y debido a la existencia de una clave de acceso general afortunadamente no consiguieron entrar.
4) Escritura de un "Manual de Operación" de la Estación Sismológica ORCA.
Una de las tareas emprendidas en esta campaña, y que quedó inconclusa debido a la falta de tiempo, sobre todo debido a los trabajos de estética hechos en la Base para su traspaso a la nueva dotación, fue la escritura de un completo Manual de Uso de la Estación de B. Orcadas. Este Manual comprende desde una breve introducción sobre qué es la Sismología, pasando por la historia de la estación sismológica Orcadas (no disponible), hasta lo realmente específico que es como se opera la estación: como se efectúa la bajada de datos, cambios de parámetros de registración, conexionado de todo el sistema, distribución de los componentes de la estación, forma de uso de los programas desarrollados, etc.
También incluye temas como inventario, contenido de los manuales (en inglés) de Reftek (no disponible), recomendaciones y sugerencias generales (no disponible), y resumen de características técnicas de las distintas partes componentes del sistema (no disponible). Todo este material tiene por objeto dejar un punto de referencia (en español) para el trabajo de los operadores futuros, de ésta como de cualquier otra estación de similares características. Es el reflejo de la experiencia acumulada durante la invernada 97, y que seguramente es importante que no se pierda.
Sería interesante continuar esta obra, completando las partes previstas que no están disponibles y/o agregando otras nuevas, para que no quede inconclusa. De todas maneras, lo más importante para el usuario de la estación está ya redactado, y sólo requiere correcciones y/o aclaraciones imposibles de efectuar por el mismo autor.
Resultados y conclusiones preliminares del procesado de los datos
5) Preprocesamiento de los registros obtenidos.
Como se adelantó anteriormente, los eventos registrados en Orcadas rondaron los 2.000 en un lapso de 8 meses de registro. De ellos, solamente de unos 1.000 se puede decir con certeza que son movimientos sísmicos; el resto son dudosos, pudiendo ser desprendimientos rocosos, fractura de glaciares, o ruidos por viento u otro factor no deseado.
Para precisar un poco más estos dichos, se muestra un cuadro que sintetiza los últimos tres meses de registro. En estos meses se realizó un procesado completo de la información recolectada, dentro de los alcances permitidos por el equipamiento de Orcadas, de un grado alto de confiabilidad. Los eventos procesados en los meses anteriores, no merecen tanta confianza, y por ello se descartan a la hora de hablar de estadísticas.
|
Amplitud en muestras |
< 1.000 |
1.000 a 10.000 |
>10.000 |
< 1.000 |
>1.000 |
Totales |
||
|
Distancia epicentral. |
< 1° |
1 a 15° |
< 1° |
1 a 15° |
<15° |
> 15° |
||
|
Del 1/09 al 16/10 |
74 |
16 |
17 |
7 |
8 |
59 |
18 |
199 |
|
Del 16/10 al 24/11 |
104 |
12 |
15 |
6 |
4 |
51 |
16 |
208 |
|
Parciales(1/9-24/11) |
206 |
45 |
12 |
110 |
34 |
407 |
||
|
Totales (1/9 - 24/11) |
(<15º) 263 |
144 |
407 |
|||||
Cuadro de cantidad de eventos sísmicos detectados en Orcadas sobre tres meses de registro.
Los eventos de más de 15° (~1.650 Km.) de distancia epicentral tienen contenidos de frecuencias bajas, en gran medida por debajo de las frecuencias de la onda de mar, por lo que se los detecta filtrando con pasabajos. Los más cercanos, tienen contenido de frecuencias predominantes altas, usándose filtros pasaaltos para su detección. Las amplitudes del cuadro anterior son, en su mayoría, las resultantes luego del filtrado.
Dentro de estos eventos, hay distancias de ocurrencia de repetición frecuente. Por ejemplo, una distancia epicentral muy frecuente es la de ~0,55°, y otra la de ~0,8°. También hay gran actividad, pero de amplitud baja, en distancias menores a 0,1°. Las profundidades son siempre escasas, con predominio del rango entre 15 a 25 Km.
Con los resultados expuestos, se pueden sacar varias conclusiones inmediatas: Orcadas del Sur es una zona de actividad sísmica importante y continua; la estación trabaja satisfactoriamente; las frecuencias de la onda de mar afectan primordialmente a los eventos con distancias epicentrales entre 10° y 20°, donde se encuentran comprendidos los sismos de las Sandwich del Sur.
Además, se puede agregar que las actividades de la base no se ven reflejadas con ruidos en los registros, excepto el producido por las emisiones radiales comentadas en el apartado anterior. También, que los ruidos ambientales se ven disminuidos considerablemente durante el invierno, cuando el mar se congela en su parte superior, e incrementados cuanto mayores y más frecuentes sean los vientos y ráfagas presentes en la zona.
De acuerdo con lo comentado sobre los distintos programas y procesos realizados para el estudio de los datos recolectados, es muy abundante el subproducto generado. El resultado de ese trabajo se encuentra contenido en un DAT en formato DOS, un cuaderno de observaciones, y archivos varios.
El DAT DOS contiene todos los eventos sísmicos detectados, y eventos dudosos o ruidos parásitos fuertes que se fueron presentando a lo largo de los 8 meses de registro. En los primeros 3 meses sólo se buscaron eventos de contenido de frecuencia baja, y en los 5 meses restantes la búsqueda se efectuó sobre las frecuencias bajas y altas. Por tanto, los últimos meses son más ricos en información que los primeros.
Como a medida que pasaba el tiempo, los procesos efectuados sobre los datos crudos se iban mejorando y optimizando, los archivos de eventos detectados se fueron perfeccionando, consiguiendo su codificación definitiva hacia mediados de julio. Así mismo, el DAT contiene los archivos del registro continuo de 1 muestra por segundo de los 8 meses, y los resultados del picado de fases sobre los eventos más importantes registrados.
El cuaderno de observaciones contiene la clasificación y catalogación de todos los eventos importantes detectados desde julio. Cada evento tiene indicada la hora de arribo de las fases que en él se observaron, sus amplitudes, y dirección aproximada donde la componente N-S se hace máxima, también un intento por determinar de qué fase se trata, y finalmente una estimación de distancia epicentral y profundidad del sismo.
Entre los archivos varios generados en la CAI 97 se encuentran el presente informe, un manual sobre uso de la estación de 50 páginas escrito por mí, un directorio elemental de eventos registrados, un directorio de los archivos contenidos en el DAT, un directorio de los sectores de los DATs de datos crudos para extraer en forma fácil cualquier época que se desee, los programas y Batchs por mí desarrollados, las planillas de bajadas de datos y centrado de masas, un inventario del material presente en Orcadas a noviembre del 97, un par de informes elevados al Jefe de Base por él pedidos, y otros tantos archivos de menor tenor e importancia.
Aunque el trabajo de procesado realizado sobre los datos crudos no es parte de la misión que me fue encomendada, sino que pertenece al resultado de un esfuerzo personal por aprender algo más sobre Sismología y paralelamente hacer un aporte que sirva al conocimiento del funcionamiento de la estación y la sismicidad de la zona en forma antisipada, hago entrega al Departamento de Sismología de la Facultad de Ciencias Astronómicas y Geofísicas de la UNLP todo el material resultante del procesamiento por mi efectuado. Mi único deseo es que se mencione mi nombre en los futuros trabajos que tomen de base los resultados de la información por mi procesada.
Sugerencias
Son dos los puntos que habría que considerar como más importantes a discutir. Uno es el del sistema de registro en DAT, que es extremadamente frágil. El otro es el de calidad de los registros debido a los ruidos parásitos producidos por las emisiones radiales.
Ya han sido expuestas las desventuras ocurridas con la unidad de grabación de DATs. En tal sentido, queda claro que algo hay que hacer al respecto. Las posibles soluciones del problema tendrían dos caminos: reemplazar el DAT por otro sistema de soporte de información más seguro, o agrandar la capacidad del disco SCSI y actualizar la versión de DAS para poder transferir los registros deseados por conexión SCSI del disco a la PC. También pueden ser implementados ambos simultáneamente.
Para el caso de reemplazar la unidad DAT, una alternativa actualmente accesible es la del CD-ROM. Su bajo costo, su sólido y seguro soporte, la robusta y sencilla mecánica de las unidades, la velocidad de acceso, y lo difundido y estándar de su uso, lo posicionan en el presente como el medio más adecuado de soporte de grandes volúmenes de información de solo lectura.
El inconveniente a discutir sería que la conexión directa al DAS no es la mejor forma de implementarlo, y traería grandes cuestiones secundarias a resolver. Por tanto, lo correcto sería bajar los datos a la PC, acomodarlos de manera prolija y sumando los 640 Mb a grabar en un bloque solo. Lo último se debe al hecho que el CD actualmente puede ser grabado sólo en una sola vez, y si no se llena en esa oportunidad, el espacio libre restante será desperdiciado.
Para trabajar realmente cómodo, lo que sería muy recomendable es la actualización del DAS por un modelo como el que está actualmente instalado en Ushuaia. Ese modelo de RefTek permite bajar del disco SCSI el archivo o grupo de archivos de datos crudos recolectado por el DAS, en forma independiente. Por tanto, la forma de manejo de la estación cambiaría considerablemente, aumentando seguridad y prestaciones.
Con el aumento del tamaño del disco SCSI a 1 Gb y la actualización anterior, el mecanismo sería el siguiente:
Con este método de trabajo se obtendrá un ágil acceso a los datos, y un aumento en la seguridad de almacenamiento de los mismos.
Con respecto al tema de los ruidos parásitos debidos a las emisiones radiales, las soluciones que se presentan para la resolución al problema son: la construcción de una pequeña casa al pie del monte Mossman justo enfrente del abrigo del sensor, para hacer el tramo del cable de datos lo más corto posible; o entubar en metal y enterrar el cable en todo su recorrido. Otra posibilidad, y muy atrayente por cierto, es la sugerida por la Guralp de proveer a la estación con un conversor analógico digital para el sensor y otro digital analógico para la caja de control, para que la transmisión de datos sea digital.
Si en cambio se dispusiese de un sistema como el sugerido más arriba para eliminar el DAT, toda la comunicación con el DAS se haría a través de un cable serie (fsc.exe) y otro SCSI (bajada de datos). Habría que consultar al fabricante al respecto, pero para la longitud del tendido actual (~200 metros), y las condiciones antárticas (bajo ruido ambiente, ausencia de tormentas eléctricas, etc.), se podría colocar el DAS, la caja de control, el GPS, y el sistema de baterías y cargadores (a flote) en el abrigo del sensor, dejando la PC y el sistema de grabación (CD-ROM) en la ubicación actual (casa principal).
En tal caso, los cables entre la casa principal y el abrigo del sensor serían: alimentación de 220V, cable serie (módem de 3 a 7 pines), y cable SCSI de datos (como el actual DAS-DAT). Como el material dejado en el abrigo no requiere ser manipulado, salvo el caso de eventuales centrados de masa el acceso al abrigo será mínimo. De todas maneras es aconsejable proveer a tal sistema de ciertos controles remotos como: control de estado de alimentación de 220V, y temperatura del abrigo.
Como el DAS y el sensor podrán estar alimentados desde la misma y única batería, el indicador de tensión del DAS será suficiente para advertir eventuales problemas de carga. Asimismo, el termómetro interno del DAS puede servir de testigo de fallas en la calefacción del abrigo. El descentrado de las masas se puede advertir de las lecturas de los valores absolutos de las cuentas de las distintas componentes.
Aunque la configuración anterior presentada no se ponga en práctica, es más que recomendable dotar al actual sistema del testigo de 220V en el abrigo. La experiencia del año 97 así lo demuestra.
Con respecto a los equipos de computación destinados para el manejo de la estación, son varios los comentarios y sugerencias a plantear.
Por un lado, la Notebook DELL por más que es una computadora rápida y con una excelente configuración general, no es el instrumento adecuado para realizar las tareas de la Estación. Su disco rígido tiene una capacidad muy reducida, aún desinstalando el sistema operativo LINUX, para el tipo de trabajo que se realiza con los datos sismológicos. Además, el concepto de usar una máquina portátil para una tarea de escritorio es, no solo un derroche de dinero, sino una incomodidad para el operador. La diminuta pantalla, el comprimido teclado, el incómodo mouse, y las delicadas conexiones con los periféricos son algunos de los puntos a considerar; pese a todo lo anterior, entre las Notebook que conozco, la DELL es realmente excelente.
Lo aconsejable sería una buena PC de escritorio, con un disco rígido grande (> 3 Gb), un monitor de alta resolución y del mayor tamaño posible, grabadora de CD, e impresora de chorro de tinta color. Secundariamente estarían, la memoria, velocidad del procesador, tarjeta SCSI, una UPC de buena calidad. placa de sonido, unidad de Packer radial, disquetera de 3½, teclado y mouse, scanner, etc.
Por otro lado, la PC 386 de resguardo, es una máquina para uso en caso de emergencia exclusivamente. Su lentitud la hace inusable para cualquier clase de procesamiento de datos. Además, se encuentra totalmente desactualizada en conjunto, por lo que no se recomienda ningún intento de actualización. Ni siquiera es factible usar el monitor para trabajar con la Notebook ya que son distintos estándares (VGA y SVGA). En resumen, no hay que tenerla en cuenta a la hora pensarla como PC alternativa, pudiendo ser donada para uso general de la base y enviando otra mejor en su reemplazo.
Otro punto a considerar es la cantidad de información general escrita con que cuenta la estación. Es recomendable enviar el resto de los manuales del DAS, libros sobre Sismología, un globo terráqueo o planisferio grande, y mucho software general, sobre todo un CD de alguna enciclopedia buena y un atlas completo.
Finalmente, las comunicaciones con el continente son muy limitadas. Es necesario ampliar el horario de radio de Orcadas - DNA, y procurar mantener un contacto radial más fluido con el operador de la Estación. Unas palabras de aliento, o la simple sensación de que aún se acuerdan de la existencia de uno es muy saludable, sobre todo para sentir que lo que se está haciendo en el ámbito laboral es realmente útil.
La estación Orcadas puede, sin mucha dificultad, convertirse en una Estación que envíe en forma compacta los eventos cercanos detectados, al día siguiente en que ocurrieran. Esto demandaría la transmisión de sólo unos 300 Kb por mes en bloques de unos 20 Kb. Si se toma la decisión de hacerlo por el enlace de radio actual tomaría menos de 10 minutos día por medio, y Orcadas pasaría a ser una estación mucho más importante que lo que es hoy en día.
La experiencia que he recolectado en estos 9 meses de trabajo, ha sido muy formativa en varios aspectos, muchos de los cuales no pueden o no deben ser volcados en este Informe. Por tanto, quedo a disposición de quienes estén interesados en ampliar los temas aquí expuestos, o de discutir los puntos que están lamentablemente ausentes.
Geofísico Julián Brizzi
Fac. de Ciencias Astr. y Geof.
Universidad Nacional de La Plata