RAADDIIOO VO OBBSSE ERRVA ATTORRIIOO DDE …jro.igp.gob.pe/publications/tecnical_reports/2010/Op_201003.pdf · archivo producto de los experimentos en cada uno de los distintos instrumentos

RRAADDIIOO OOBBSSEERRVVAATTOORRIIOO DDEE JJIICCAAMMAARRCCAA

IINNSSTTIITTUUTTOO GGEEOOFFÍÍSSIICCOO DDEELL PPEERRÚÚ

EESSTTAANNDDAARRIIZZAACCIIÓÓNN DDEE BBAASSEE DDEE DDAATTOOSS::

BBOOUUNNDDAARRYY LLAAYYEERR AANNDD TTRROOPPOOSSFFEERRIICC RRAADDAARR

DDAANNIIEELL ÁÁNNGGEELL SSUUÁÁRREEZZ MMUUÑÑOOZZ

OOPPEERRAACCIIOONNEESS DDEE RRAADDAARR

SSEEPPTTIIEEMMBBRREE 22001100

Apartado 130207, Lima 13, Perú

Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

2

RESUMEN

Este reporte describe las pautas para el proceso de estandarización de Base de Datos en el Radio Observatorio de Jicamarca (ROJ). Es necesario el proceso de estandarización porque el ROJ administra los datos de diversos instrumentos con datos de diferentes formatos, y también se cuenta con desarrollo de software de lectura y procesamiento especifico usando IDL o lenguaje C que no ha sido documentado, lo cual hace difícil el mantenimiento y comprensión de la base de datos para el administrador; a esto se suma la diversidad de páginas web en el servidor del ROJ, donde se manejan distintas interfaces por cada tipo de dato.

El proceso de estandarización se inicia con la integración del ROJ a la red mundial de observatorios que utilizan la base de datos Madrigal. Este reporte describe la estandarización a formato Madrigal de los datos del sistema Boundary Layer and Tropospheric Radar (BLTR), donde primero se realiza un análisis del estado actual de la base de datos, partiendo de la organización de los datos, formatos, estructuras de archivos y tipos de experimentos. Luego, se hace un análisis del software involucrado, donde se da a conocer cuáles son los lenguajes utilizados, cuáles son la librerías o funciones requeridas para el procesamiento y publicación de los datos en la web.

Luego, se propone una arquitectura de operación para la base de datos, donde el desarrollo de software para lectura y procesamiento se ha realizado con Python. Se han creado tres experimentos para los datos del BLTR: Bltr Low-Res, Bltr High-Res mode 1 y Bltr High-Res mode 2, donde el primero trata acerca de los datos de consenso horario; el segundo, trata acerca de los datos observados en Baja Atmósfera y el último, trata acerca de los datos observados en Alta Atmósfera.

La operación de la base de datos se ha dividido de tal forma que se han asignado tareas específicas para cada servidor del ROJ, los cuales son tres: JRO, JRO_PROC y JRO1. En el JRO se encuentran los archivos de salida de cada instrumento; en JRO_PROC se procesan los archivos hasta su conversión a un formato compatible con Madrigal. En JRO1 se tiene instalado una versión de Madrigal donde se agregan los archivos entregados por el JRO_PROC.

Como resultado de este reporte se han integrado exitosamente los datos del BLTR con Madrigal. Ahora se cuenta con código documentado y un mejor desempeño en la operación y mantenimiento de los datos.


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

3

ÍNDICE

1 INTRODUCCIÓN ................................................................................................................ 4

2 DESARROLLO ................................................................................................................... 5

2.1 Estado actual en el servidor JRO .................................................................................................... 5 2.1.1 Organizazion de los Datos .............................................................................................................. 5 2.1.1.1 Datos de Baja Resolución ............................................................................................................... 5 2.1.1.2 Datos de Alta Resolución ................................................................................................................ 6 2.1.2 Secuencia de Procesamiento .......................................................................................................... 9 2.1.2.1 Datos de Baja Resolución ............................................................................................................... 9 2.1.2.2 Datos de Alta Resolución ...............................................................................................................10 2.1.3 Entorno Web ..................................................................................................................................11 2.2 Desarrollo propuesto con fines de estandarizacion .........................................................................11 2.2.1. Organización de los datos ..............................................................................................................11 2.2.1.1 Datos de Baja Resolución ..............................................................................................................11 2.2.1.2 Datos de Alta Resolución ...............................................................................................................11 2.2.1.3 Datos en Madrigal ..........................................................................................................................11 2.2.2. Secuencia de Procesamiento .........................................................................................................13 2.2.2.1 Servidor JRO_PROC .....................................................................................................................14 2.2.2.2 Servidor JRO1 ...............................................................................................................................16 2.2.3. Entorno Web ..................................................................................................................................16

3 RESULTADOS ................................................................................................................. 16

4 CONCLUSIONES ............................................................................................................. 17

5 RECOMENDACIONES ..................................................................................................... 17


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

4

ESTANDARIZACIÓN DE BASE DE DATOS: BOUNDARY LAYER AND TROPOSPHERIC RADAR

1 INTRODUCCIÓN

El ROJ tiene a su cargo distintos instrumentos, además del Radar Principal de 50 MHz en sus distintos modos de operación, se tienen, Magnetómetros, Digisonda, Jicamarca All-sky Specular Meteor Radar (JASMET), Jicamarca Unattended Long-term Investigations of the Ionosphere and Atmosphere (JULIA), Boundary Layer and Tropospheric Radar

(BLTR) y otros.

Estos instrumentos también manejan distintos experimentos para observar diferentes tipos de parámetros, lo que implica que existe una variedad en el formato de archivo producto de los experimentos en cada uno de los distintos instrumentos que el ROJ tiene a su cargo. Esta diversidad en el formato de archivo obligó al ROJ a implementar una base de datos para cada tipo específico de archivo, lo que también involucra desarrollo de software a la medida. Esto se traduce en librerías de lectura/escritura, procesamiento y gráficos de los datos. El problema del desarrollo a medida es que el soporte se hace tedioso, porque requiere mucho del tratamiento de los usuarios o del administrador de la base de datos, peor aún, cuando el desarrollo no se ha documentado y solo se ejecutan aplicaciones cerradas, donde no hay posibilidad de aumentar el desempeño y llegar a automatizar toda la base de datos. Aquí nace el propósito del proyecto de estandarización de la base de datos del ROJ.

En el 2009, el ROJ se incorporó a una red mundial Radio Observatorios, donde se utiliza la Base de Datos Madrigal, desarrollada por el MIT Haystack Observatory. El formato de archivo que utiliza Madrigal es el mismo que utiliza la National Science Foundation soportado por el programa Coupling, Energetics and Dynamics of Atmospheric Regions

(CEDAR). En Madrigal se dispone de un único formato para toda una variedad de instrumentos, experimentos y parámetros observados, este formato CEDAR es el formato que adopta el ROJ para su base datos. La adopción de este formato conlleva también a un mejor desempeño de la base datos, ya que no solo se hablará del formato de archivo sino también del desarrollo de software.

En el pasado y presente del ROJ, en cuanto a desarrollo de software, se ha utilizado el lenguaje IDL para lectura/escritura, procesamiento y gráficos de los datos, y también para las aplicaciones web que tienen que ver con la base de datos. En el proyecto de estandarización de base de datos se ha elegido como lenguaje de desarrollo Python; primero, porque Madrigal utiliza Python; segundo, este lenguaje se caracteriza por ser orientado a objetos, lo cual conlleva a un orden y sentido de programación, fácil de administrar, código ordenado y documentado; y Tercero, Python es open-source. A diferencia de IDL, Python trae consigo librerías para el tratamiento y análisis de datos. Se podría discutir más sobre las ventajas o desventajas de uno u otro lenguaje, IDL o Python, pero no es el tema de este reporte, además, los resultados obtenidos y descritos en este reporte confirmarán que Python es la elección adecuada y necesaria para la Base de Datos del ROJ.

Este proceso de estandarización se inicia con los datos obtenidos del BLTR. Las ciudades de Piura y Huancayo cuentan con este sistema de radar, y los datos de cada uno de estos deben ser recibidos en el servidor del ROJ. Cabe destacar que en la ciudad de Huancayo se ha instalado el sistema, pero no se realiza el envío de datos y su publicación en web porque no dispone de un acceso a Internet que ha sido oportunamente requerido, pero hasta la fecha no ha sido atendido ni implementado. Por tal motivo en este reporte nos referiremos solo a los datos del BLTR ubicado en la Universidad de Piura (UDEP).


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

5

2 DESARROLLO

La sección de Desarrollo está dividido en dos partes: la primera parte trata acerca del estado actual de la base de datos del BLTR en el ROJ; en la segunda parte, se describe el proceso de estandarización, además del sistema propuesto para el procesamiento y la actualización automatizada de los datos.

El ROJ cuenta con dos servidores, al primero se le denomina JRO y contiene la actual base de datos, aquí se reciben los datos de los distintos instrumentos que se mencionaron en la sección anterior. Al segundo servidor se le denomina JRO1, y aquí se tiene instalado Madrigal; esta será la nueva base de datos.

2.1 Estado actual en el servidor del JRO

Para entender la importancia de la estandarización es necesario dar a conocer el estado en el que se encuentra la base de datos, cómo están organizados los datos, cómo se realiza el procesamiento y la publicación de los mismos en la web.

2.1.1 Organización de los datos

Los datos del BLTR se presentan en alta resolución (aprox. 1.5 minutos) y baja resolución (1 hora), con los formatos *.sswma y *.cns respectivamente. Los datos de baja resolución son datos de consenso o promedio horario que se utilizan para monitoreo del sistema.

2.1.1.1 Datos de baja resolución

Estos datos tienen formato ASCII con extensión *.cns (Revisar Anexo sección 1, formato de archivo). Por medio de un servidor en la UDEP los datos son comprimidos (*.gz) y enviados por FTP (File Transfer Protocol) al servidor JRO. Cada hora del día el servidor

JRO recibe un archivo con la siguiente denominación:

BUTYYYYDDD.YY.cns.gz

Donde:

BUT - Nemónico para los datos del BLTR en Tiempo Universal

YYYY - Indica el año del experimento (4 dígitos)

DDD - Indica el día del año del experimento (3 dígitos)

HH - Indica la hora del día del experimento (2 dígitos)

cns - extensión del archivo

gz - extensión del archivo comprimido

Estos archivos contienen valores de velocidad meridional, vertical y zonal de cada hora, los cuales son concatenados para formar un archivo correspondiente a un día, este archivo diario se lee y grafica en la siguiente página web:

http://jro.igp.gob.pe/database/blt_cns/html/online_bltr_frame1.html

Mediante la web se comparten los archivos en formato ASCII con extensión *.cns, la persona interesada debe solicitar un usuario y contraseña al administrador de la base de datos.



Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

6

La Figura 1 muestra la organización de carpetas, en el servidor JRO, que tienen relación con datos del BLTR en la ciudad de Piura, Huancayo y Porcuya (solo hasta 2009).

Figura 1 Organización de carpetas en el servidor JRO

2.1.1.2 Datos de Alta Resolución

Estos son datos en formato binario con extensión *.sswma, los que son adquiridos, procesados y compartidos (solo gráficos) de forma manual por el usuario local, esta es la persona encargada del BLTR. En la siguiente página web se muestran los gráficos que corresponden a estos datos:

http://jro.igp.gob.pe/database/blt_winds/html/windsdata.html

Estos gráficos se presentan en dos modos: Alta y Baja Atmosfera. Los datos procesados por el usuario local no se encuentran en ninguna base de datos y son denominados de la siguiente forma:

peru2.YYYYMMDD.sswma

Donde:

Peru2 - Nemónico designado para Piura

YYYY - Indica el año del experimento (4 dígitos)

MM - Indica el mes del experimento (2 dígitos)

DD - Indica el día del experimento (2 dígitos)

sswma - formato binario

CNS

Huayao

Porcuya

UDEP

Winds

/users/database/bltr

CNS_data 2010 (*.cns)

Winds_data 2010 (*.png)

CNS_data

Winds_data

2002 – 2009 (*.cns)

2002 – 2009 (*.png)

2001 – 2010 (*.cns)

BLTR 2001 – 2010 (*.png)

2001 – 2002 (*.png) BLTR

CNS_data

Winds_data

Graph

data_porcuya ->../Porcuya/CNS_data

data_udep ->../UDEP/CNS_data

*.jpg

*.png


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

7

Figura 2 Estructura de datos de Alta Resolución

La Figura 2 muestra la estructura de los archivos *.sswma, esta información no estaba documentada y se obtuvo a partir de la interpretación de rutinas de lectura en el lenguaje IDL. Muchos de los parámetros contenidos en este tipo de archivo no se describen en este informe debido a que no son considerados para efectos de procesamiento requerido por el usuario local. Todos los parámetros se ponen a disposición del usuario, para su uso posterior por medio de rutinas realizadas en Python. A continuación se describe brevemente las secciones del archivo Header1, Header2 y Data.

TIPO DE DATO PARÁMETRO BYTES Unsigned Int FMN 4 Unsigned Int nrec 4 Unsigned Int Unsigned Int Unsigned Int

fr_offset id site

4 4 32

Tabla 1 Descripción del HEADER1

HEADER1

DATA

(RECORD 0)

HEADER2

HEADER2

DATA

(RECORD 1)

HEADER2

DATA

(RECORD n)


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

8

La variable más importante es nrec que indica el número de records que tiene el archivo *.sswma.

TIPO DE DATO PARAMETRO BYTES Unsigned Int Rmn 4 Unsigned Int Rcounter 4 Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Float Float Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Signed Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Unsigned Int Float Unsigned Int Unsigned Int Unsigned Int Unsigned Int Float Float Float Float Unsigned Int Unsigned Int

Nr_offset Tr_offset Time Time_msec Tag Comments Lat Lon Gps_status Freq Freq0 Nchan Delta_r Nranges R0 Prf Ncoh Npoints Polarization Rx_filter Nmodes Dmode_index Dmode_rngcorr Nrxs Acf_length Acf_lags Sea_to_atmos Sea_notch Lh_sea Hh_sea Nbins_sea Min_snr Min_cc Max_time_diff Antenna_coord Rx_gains Rx_analysis

4 4 4 4 32 32 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4*[2*Nchan] 4*Nchan 4*Nchan

Tabla 2 Descripción del HEADER2

De estos parámetros se utilizan los siguientes:

- Lat y Lon, indican la ubicación en Latitud y Longitud del BLTR

- Nrxs, indica el número de canales

- Nranges, indica el número de muestras

- Delta_r, indica la resolución en altura

- Nmodes, indica el número de modos de operación


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

9

TIPO DE DATO PARAMETRO BYTES Unsigned Int Range 4 Unsigned Int Status 4 Float Float Float Float Float Float Float Float Float Float Float FloaT Float Unsigned Int Unsigned Int Unsigned Int Float Float Float

Zonal Meridional Vertical Zonal_a Meridional_a Corrected_fading Uncorrected_fading Time_diff Major_axis Axial_ratio Orientation Sea_power Sea_algorithm Rx_saturation Chan_offset Rx_amp Rx_snr Cross_snr Sea_power_relative

4 4 4 4 4 4 4 4 4 4 4 4 4 4*Nrxs 4*[2*Nrxs] 4*Nrxs 4*Nrxs 4*Nrxs 4*Nrxs

Tabla 3 Descripción de DATA

De estos parámetros se utilizan los siguientes:

- Range, indica el range en Kilómetros

- Status, se utiliza para validar los datos

- Zonal, indica el valor observado para velocidad zonal

- Vertical, indica el valor observado para velocidad vertical

- Meridional, indica el valor observado para velocidad meridional

- Rx_snr, indica el valor de Relación Señal-Ruido

2.1.2 Secuencia de Procesamiento

Los datos de Baja Resolución (*.cns) son enviados cada hora desde el servidor de Piura, estos datos se utilizan para monitoreo, la unidad de procesamiento (PC) del BLTR tiene programado el envío de estos datos sin realizar procesamiento de filtrado. Los datos de Alta Resolución son almacenados en la PC del BLTR, para luego ser descargados vía FTP por el usuario local, esto se realiza una vez por semana.

2.1.2.1 Datos de Baja Resolución

En el crontab del servidor JRO se tiene indicado la ejecución de una aplicación llamada “get_cns”. Aquí se encontró programas en lenguaje C y otro en IDL. La siguiente figura muestra la secuencia de ejecución o procesamiento:


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

10

Figura 3 Secuencia de Procesamiento para Datos de Baja Resolución


El usuario local se encarga de procesar manualmente estos datos cada semana, para esto se cuenta con una interfaz de procesamiento desarrollada en IDL. Tiene incluidas rutinas de lectura, procesamiento y gráficos. Este desarrollo no tiene documentación.

Figura 4 Secuencia de Procesamiento para Datos de Alta Resolución

get_cns

bhour

get.files

hour2cns.idl

Programa en C, edita los programas get.files y hours2cns.idl

Busca el ultimo archivo *.gz según la fecha, lo mueve a un fólder distinto donde se descomprime y se cambia de nombre

Programa en IDL, concatena los archivos de cada hora en un único archivo del día

Archivo CNS (online) Online: indica que se refresca cada hora. Este archivo se usa para un monitoreo del sistema de radar, contiene valores observados que no han sido procesados (limpiados y validados).

Archivo SSWMA Se recibe un archivo comprimido por FTP desde el servidor de Piura a la PC del usuario local.

Lectura y Pre-Procesado

El usuario local dispone de una Interfaz desarrollada en IDL para Leer y pre-procesar los datos. El pre-procesado involucra una validación de los datos, filtrado por SNR y filtrado por Mediana. Los script en IDL son los siguientes: read_sswma.pro, proc_sswma_ut.pro, outlier_removal.pro

Archivo SV y Gráficos

Luego del pre-procesamiento se genera un archivo intermedio *.sv, este es un archivo binario con un formato de compresión asignado por IDL (ZLIB compression library). Con este archivo se realizan dos graficas, Alta y Baja Atmósfera, en ambas se muestran la velocidad meridional, vertical y zonal además del SNR. El usuario local añade manualmente estas gráficas al servidor JRO donde se publica por una página web. No se comparte el *.sv

Post-Procesado

Se lee el archivo *.sv y se calcula el promedio de los valores observados en rango de una hora, este periodo es asignado por defecto. El resultado de este promedio produce un archivo *.cns con la diferencia que este último ha sido procesado.

Archivo CNS (procesado) El usuario reemplaza manualmente este archivo en el servidor JRO.


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

11

2.1.3 Entorno Web

Se tienen dos páginas Web para los datos del BLTR:

- Baja Resolución


- Alta Resolución

http://jro.igp.gob.pe/database/blt_winds/html/windsdata.html

Estas páginas web contienen interfaces que han sido desarrolladas específicamente para cada tipo de dato del BLTR, por lo cual no es compatible o re-utilizable para otros instrumentos.

2.2 Desarrollo propuesto con fines de estandarización

Debido a la afiliación del ROJ a la red de Madrigal, se le ha escogido como la referencia para la estandarización de los datos de los distintos instrumentos que tiene a su cargo el ROJ.

2.2.1 Organización de los datos

2.2.1.1 Datos de Baja Resolución

Los archivos *.cns son convertidos a formato CEDAR-ASCII, se ha creado un experimento con el nombre de “Bltr Low-Res” que hace referencia a los datos del BLTR de

Baja Resolución. Los parámetros observados serán las velocidades meridional, vertical y zonal, indicando también el rango en kilómetros.


Los archivos *.sswma son recibidos en el servidor JRO, estos se leen y procesan adecuadamente según lo deducido de todos los programas en IDL. Según lo descrito en la Figura 4, se tienen dos resultados para este tipo de archivo: Alta y Baja Atmósfera, siendo que para Baja Atmósfera corresponde a valores observados en un rango desde 0 – 3 Km, para Alta Atmósfera se tiene un rango desde 0 – 10 Km. Estos resultados son convertidos a formato CEDAR-ASCII, además se han creado dos experimentos “Bltr High-Res mode 1” y “Bltr High-Res mode 2”, que corresponden a los resultados de Baja y Alta Atmósfera respectivamente.

2.2.1.3 Datos en Madrigal

Para convertir los datos de Alta y Baja Resolución (*.cns y *.sswma) al formato CEDAR-ASCII, se han asignado códigos para el Instrumento (kinst), el algoritmo de procesamiento (kindat) para cada experimento y códigos de parámetros observados (parcods). Los códigos asignados son los siguientes:

- Kinst:

CÓDIGO NEMÓNICO DESCRIPCION 1000 pbr Piura BLTR


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

12

1001 hbr Huancayo BLTR 1002 obr Porcuya BLTR

Tabla 4 Descripción de Kinst

- Kindat:

CÓDIGO OPTCHAR DESCRIPCION 1600 h Bltr High-Res mode 1 1601 H Bltr High-Res mode 2 1602 L Bltr Low-Res

Tabla 3 Descripción de Kindat

- Parcods:

CÓDIGO NEMÓNICO DESCRIPCION 1412 VN1P2 Velocidad Zonal 1422 VN2P2 Velocidad Meridional 1430 412

VN3 SNL

Velocidad Vertical Relación señal-ruido

Tabla 3 Descripción de Parcods

Con el apoyo del usuario local se ha elaborado la cabecera (Header) y catálogo (Catalog) de los archivos CEDAR-ASCII. Para mayor información del formato CEDAR-ASCII consultar al administrador de la base de datos de Madrigal.

La estructura de carpetas en Madrigal se muestra mediante la siguiente figura:

Figura 5 Organización de carpetas en Madrigal

El bloque experiments que muestra la Figura 5 está ubicado dentro de la carpeta de instalación de Madrigal, a esta se le denomina MADROOT, para este proyecto de estandarización se asignó como MADROOT a “/usr/local/madrigal2”/ en el servidor JRO1,

esta dirección puede variar según lo decida el administrador de Madrigal. Luego se tiene subcarpeta divididas por cada año, Year; A continuación se tiene subcarpetas por cada instrumento, instrument; y finalmente el bloque exp.folder indica las distintas carpetas

asignadas para cada experimento de acuerdo al día, mes, año y optChar; como por ejemplo: 10jun10L, carpeta que contiene datos del 10 de Junio de 2010 que corresponden al experimento “Bltr Low-Res”.

experiments

Year Instruments

Exp. Folder

2010 pbr

hbr

obr

16jun10H

16jun10h

10jun10L 2009


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

13

2.2.2 Secuencia de Procesamiento

A continuación se muestra la arquitectura propuesta para la automatización de la base de datos del ROJ.

Figura 6 Arquitectura para la Base de Datos del ROJ

Se observan los siguientes elementos:

- Servidor JRO, donde los instrumentos del ROJ escriben sus datos o archivos de salida. La dirección IP es 200.60.148.180

- Servidor JRO_PROC, es el servidor de procesamiento de datos, se leen los datos, por medio de FTP, del servidor JRO, se procesan localmente y se escriben, por FTP, al servidor JRO1. Se ha definido un archivo de configuración para todo el proceso, ver el formato en Anexo sección 2.1. La dirección IP es 10.10.10.3

- Servidor JRO1, servidor de la base de datos en Madrigal, los datos se actualizan periódicamente y en tiempo real. Se ha definido un archivo de configuración para el proceso realizado, ver el formato en Anexo sección 2.2. La dirección IP es 200.60.148.184

- Administrador, se refiere al grupo encargado del soporte, control y mantenimiento de la base de datos.

- Clientes, son los usuarios que mediante la Web acceden a la base de datos del ROJ.


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

14

2.2.2.1 Servidor JRO_PROC

Para el caso del BLTR se ha desarrollado una aplicación en Python, bltr_app.py, que de acuerdo a sus parámetros de entrada y del archivo de configuración se realiza el procesado de los datos. Ver en Anexo sección 3 el diagrama de programación para esta aplicación. A continuación se define el diagrama de bloques de operación:

Figura 7 Diagrama de bloque de operación bltr_app.py

Se programa en el crontab del servidor la ejecución periódica de esta aplicación con sus parámetros requeridos.

ENTRADA DE PARAMETROS

CARPETAS DE TRABAJO

CONFIGURACIÓN

PROCESAMIENTO

Se leen los parámetros de entrada usando el método setScriptState. Con estos parámetros se define el experimento, la ubicación de los datos y el archivo de configuración. Para más información revisar Anexo

Con el método getFiles se descargan por FTP los archivos del servidor JRO usando el modulo customFtp.py. Los archivos descargados se encuentran en la carpeta definida por la variable (atributo) rawdata.

De acuerdo al experimento seleccionado, Bltr High Resolution ó Bltr Low Resolution, se procesan los archivos con los modulos pertinentes para cada experimento.

Se emplea el método putFiles, para escribir remotamente en el servidor JRO1, la carpeta principal de destino es /usr/local/madrigal2/cedarData/ftp/. A partir de esta se crean subcarpetas de acuerdo a los permisos, público o privado, de acuerdo al Nombre del Experimento y Año. Por cada archivo enviado se actualiza el log-file ya que se considera que el proceso ha sido completado o exitoso para ese archivo.

LOG-FILE

DESCARGA DE ARCHIVOS

TRANSFERENCIA DE ARCHIVOS

De acuerdo a los parámetros de entrada, se lee el archivo de configuración: expConfig.txt, aquí se complementa la información para definir la ubicación de los datos de entrada y de salida del proceso, se definen también los parámetros para conexión FTP. Se usa el método readConfigTable para lectura de estos parámetros.

Se borran las carpetas de trabajo existentes que han sido dejadas por procesos que no han culminado con éxito, luego, se crea la carpeta de trabajo para el procesamiento y el log-file. Los métodos para esta función son removePath y createPath.

Se crea el log-file: logfile.txt, con el método createLog, este método crea un log personalizado usando el modulo logfile.py


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

15

El bloque de PROCESAMIENTO de la figura anterior, se divide en dos procesos distintos que se explican a continuación mediante los siguientes diagramas de bloques:

Figura 8 Diagrama de bloques Bltr Low Resolution

Figura 9 Diagrama de bloques Bltr High Resolution

2.2.2.2 Servidor JRO1

Para la actualización de los datos en Madrigal se tiene la aplicación createExpWithDir.py.

CONVERSION

CONCATENAR Descompresión y Concatenación de archivos *.cns, al servidor JRO los datos del Bltr llegan comprimidos con datos de cada hora del dia en formato UT.

Conversión del archivo *.cns a formato CEDAR-ASCII usando la clase strcns2cedar del modulo bltr_data_conv.py.

LECTURA DE DATOS

CEDAR

PROCESADO DE DATOS

Se realiza la lectura del archivo *.sswma, para esta tarea se utiliza la clase ReadRawData del modulo sswma.py

El procesado de datos consiste en realizar: Filtrado por SNR, Filtrado por Status, Filtrado por la Mediana y Calculo del Promedio. Para esta tarea se utiliza la clase ProcRawData del modulo sswma.py

Se escriben tres tipos de archivos CEDAR-ASCII, Low Resolution, High Resolution mode 1 y High Resolution mode 2. Para el primero de se usa la clase cns del modulo bltr_data_conv.py, para los restantes se usa la clase sv del mismo modulo


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

16

Figura 10 Diagrama de bloques para la actualizacion de la base de datos

2.2.3 Entorno Web

Los envíos de datos se encuentran automatizados en el crontab de la PC del sistema de radar del BLTR en Piura. Para mayor información consultar con el usuario local.

La página web para interactuar con los datos en Madrigal es la siguiente:

http://jro1.igp.gob.pe/madrigal2/

La interfaz ha sido desarrollada por el Ing. Miguel Urco en el proyecto “Base de Datos Madrigal en el ROJ”. Mediante esta interfaz los usuarios pueden observar gráficamente el resultado de cada experimento, donde también pueden ver los valores numéricos de estos y hacer la descarga de los datos, su forma de uso es sencillo e intuitivo para el usuario.

3 RESULTADOS

Para los datos de consenso o monitoreo (*.cns) del sistema BLTR se ha uniformizado y ordenado el desarrollo de software en un solo lenguaje: Python, no se depende de IDL o C para procesar, registrar o graficar estos datos. Se ha creado el experimento Bltr Low-Res.

Para los datos crudos o de alta resolución (*.sswma) del sistema BLTR se ha creado una base de datos, con un desarrollo de software para lectura y procesamiento de los datos en Python debidamente documentado. A partir de estos datos se han creado dos experimentos: Bltr High-Res mode 1 y Bltr High-Res Mode 2, para datos de Baja y Alta Atmósfera respectivamente.

Se ha definido una arquitectura de operación para la base del ROJ que permite automatizar los procesos requeridos de la base de datos: lectura de datos,

ENTRADA DE PARAMETROS

CONFIGURACIÓN

Se leen los parámetros de entrada usando el método setScriptState. Con estos parámetros se define el experimento, la ubicación de los datos y el archivo de configuración.

De acuerdo a los parámetros de entrada, se leen los archivos de Madrigal desde la carpeta /usr/local/madrigal2/cedarData/ftp, de acuerdo al experimento, publico o privado. El modulo createExpWithDir.py se encarga de crear experimentos y añadirlos a la carpeta experiments del MADROOT.


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

17

procesamiento, conversión a formato CEDAR, registro de datos en Madrigal de distintos Instrumentos y experimentos.

Se utiliza una única interfaz web mediante la cual los usuarios pueden observar los resultados de diferentes instrumentos, experimentos, donde tienen a disposición los gráficos y valores numéricos de los datos.

Empleando Madrigal como base de datos, se tiene un mejor control en el registro de los datos y su mantenimiento con reporte de errores vía correo electrónico al administrador de la base de datos.

4 CONCLUSIONES

La integración de los instrumentos del ROJ en una única base de datos es posible usando Madrigal, esta integración trae consigo un mejor desempeño y mantenimiento de la base de datos. Se ha definido las pautas de cómo continuar con la integración y estandarización de los demás instrumentos contenidos en el servidor JRO. La documentación de las librerías desarrolladas serán reutilizables para este propósito.

5 RECOMENDACIONES

Atender e implementar el requerimiento de conexión a Internet del sistema BLTR ubicado en la ciudad de Huancayo.


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

18

BIBLIOGRAFíA

URCO, Miguel. Base de Datos Madrigal en el ROJ. Lima, Perú, Radio Observatorio de Jicamarca, Tecnologias de la información, 2009


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

19

ANEXOS

1. Formato de archivo *.cns

UBICACIÓN

LATITUD LONGITUD

YEAR MONTH DAY HOUR MINUTE SECOND

MINUTOS_CONSENSUS MINUTOS_REALES

HEIGHT U (m/s) V (m/s) W (m/s)

Value Value Value Value

$

2. Formato de archivo de configuración

2.1. JRO_PROC

experiment="Bltr High Resolution"

site="Piura"

local="/home/apajares/database_pro"

temp="/bltr"

logPath="/logPath/bltr/high/piura"

logBacKup="/logBackup/bltr/high/piura"

ftp1="Download"

host1="200.60.148.180"

user1="database"

passwd1="QLZBH40"

remotefolder1="/users/database/bltr/test"

ftp2="Upload"

host2="200.60.148.184"

user2="madrigal"

passwd2="madrigal"

remotefolder2="/usr/local/madrigal2"

permission="public"

site="Huayao"

local=""

temp=""

logPath=""

logBacKup=""

ftp1="Download"

host1=""

user1=""

passwd1=""


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

20


ftp2="Upload"

host2=""

user2=""

passwd2=""


permission="public"


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

21

3. Diagrama de Pogramación

bltr_app

LowResProc

MÓDULOS sys, traceback time, datetime getopt subprocess re, glob shutil,stat fnmatch customFtp logfile madrigal.metadata

ATRIBUTOS expName site configPath year, month, day dateDateTime dirFile, dirLog dirBackupLog obj_log rawdata, cedardata listproc kinst instMnemonic format, permission obj_dwFiles obj_upFiles workPath __createMadDB __configExp __madInst

MÉTODOS setScripState readConfigTable __getValueFromArg createpath removePath getFiles putFiles createLog updateLog

HighResProc

ATRIBUTOS obj_cns

MÉTODOS procFiles

MÓDULOS bltr_data_conv

ATRIBUTOS obj_read obj_proc obj_sv obj_cns

MÉTODOS procFiles

MÓDULOS sswma bltr_data_conv


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

22

4. Documentación de Librerías desarrolladas en Python

4.1. Bltr Low Resolution. Según el diagrama de programación

corresponde a la clase “LowResProc”.

Clase strcns2cedar __init__(self)

Inicia los miembros de la clase Entradas: Ninguna Retorna: Vacio

cns2cedar(self,input,output,site) Realiza la lectura del archivo *.cns, y separa en lista de datos los arreglos que contienen la información de tiempo y velocidades. Luego, carga los arreglos de datos para la escritura de archivos CEDAR-ASCII.

Entradas:

Input -Archivo de entrada output -Archivo de salida, site -Indica la ubicación del instrumentos que

relaciona el valor kinst. 0: 1000 (valor de kinst para Piura) 1: 1001 (valor de kinst para Huancayo) 2: 1002 (valor de kinst para Porcuya) format -fija el formato de archivos de salida. Por defecto

es ASCII. Retorna: Vacio

bltr_data_conv.py

Metodo __create_madfile

Realiza la escritura en formato CEDAR-ASCII de los datos de consenso del archivo *.cns

Metodo __info_cedar

Define la información del catálogo del archivo CEDAR-ASCII

Clase strcns2cedar

Metodo cns2cedar

Lectura del archivo *.cns, y escribe resultado en formato CEDAR.


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

23

__create_madfile(self) Escribe los arreglos en formato CEDAR-ASCII, aquí se usa el método __info_cedar() Entradas: Ninguna

Retorna: Vacio

__info_cedar(self) Contiene la información del Header y Catalogo para el archivo CEDAR

Entradas: Ninguna Retorna:

kindatDesc - Informacion del Kindat, cadena de caracteres comments - Descripcion de los datos, analyst - Informacion de la persona responsable history - Informacion Historica de los datos principaleInvestigator - Principal Investigador a cargo del

experimento

4.2. Bltr High Resolution. Según el diagrama de programación

corresponde a la clase “HighResProc”.

4.2.1. Lectura de Datos

sswma.py Clase ReadRawData

Metodo Open

Metodo HeaderFile

Metodo DataBlock

Metodo Close

Realiza la lectura del Header o cabecera del archivo.

Lee, ordena y valida el arreglo de datos obtenidos del archivo.

Se inicia el puntero de lectura y variables de control.

Si se ha llegado al final de un archivo cierra el puntero de lectura.


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

24

Clase ReadRawData __init__(self)

Inicia las propiedades o elementos de la clase Entradas: Ninguna Retorna: Vacio

Open(self,filename)

Inicia el puntero de lectura e inicia variables de control Entradas:

filename - Indica la direccion completa del archivo que se desea leer

Retorna: Vacio HeaderFile(self)

Lee el header del archivo y extrae las variables utilizadas para el procesamiento. Inicia una reserva en memoria para los arreglos de datos Entradas: Ninguna Retorna: Vacio

DataBlock(self,status_value) Se ordena el arreglo de datos para los parametros observados Se filtran todos los valores de acuerdo al valor de status_value. Los parametros observados se actualizan como miembro de clase

Entradas:

status_value - valor entero que se utiliza para extraer datos validos dentro del blque de datos

Retorna: Vacio

Close(self) Cierra el puntero de lectura Entradas: Ninguna Retorna: Vacio


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

25

4.2.2. Procesamiento

Clase ProcRawData __init__(self)


SetData(self,time,height,snr_ref,zon_ref,ver_ref,mer_ref,nmodes,nchannels, nranges,year,month,day,lat,lon,siteFile)

Asigna los arreglos de datos que van a ser procesados y los parametros necesarios para el procesamiento. Entradas:

time - tiempo en segundos UT (arreglo de tipo flotante) height - rangos de alturas en Km (arreglo de tipo flotante) snr_ref - relacion señal - ruido (arreglo de tipo flotante, sus

dimensiones dependen del numero de canales) zon_ref - velocidad zonal (arreglo de tipo flotante, sus

dimensiondes dependen del numero de modos de operacion)

ver_ref - velocidad meridional (arreglo de tipo flotante, sus dimensiones dependen del numero de modos de operacion)

mer_ref - velocidad vertical (arreglo de tipo flotante, sus dimensiones dependen del numero de modos de operacion)

sswma.py

Carga los arreglos de datos para el procesa-miento.

Realiza filtrado de los valores que esten por debajo de un umbral de relacion señal-ruido.

Realiza la seleccion y filtrado de los arreglos de datos.

Calcula el 'smooth' o suavizado a un arreglo de datos.

Calcula la mediana en un arreglo de datos.

Se encarga de seleccionar solo los datos correspon-dientes a un periodo de tiempo.

Calcula el promedio para un arreglo de datos.

Metodo SetData

Metodo SnrFilter

Metodo OutLiersFilter

Metodo Smooth

Metodo Median

Metodo TimeSelect

Metodo Average

Clase ProcRawData


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

26

nmodes - numero de modos de operacion (int) nchannels - numero de canales (int) nranges - numero de rangos (int) year - años del experimento (int) month - mes del experimento (int) day - dia del experimento (int) lat - valor en latitud (float) lon - valor en longitud (float) siteFile - cadena de caracteres: 'peru1' o 'peru2'.

Retorna: Vacio

OutLiersFilter(self,svalue,svalue2,metodo,factor,filtro,npoints)

Entradas: svalue - string, 'zonal', 'meridional','vertical'; indica que

arreglo ha de ser procesado svalue2 - string, 'inTime', 'inHeight'; indica con respecto a que

eje se realiza el procesado metodo - valor entero: 0 - Calcula el suavizado, 1 - Calcula la

mediana factor - valor flotante, considerado para establecer el valor de

umbral segun la desviacion estandar filtro - indica si se realiza filtrado por la desviacion estandar npoints - tamaño de la ventana a considerar en el calculo de la

median y del suavizado Retorna:

output_array - Arreglo de tres dimensiones resultante del proceso

Smooth(self,input,width,edge_truncate ) Entradas:

input - Arreglo de entrada width - Tamaño de la ventana edge_truncate - seleccion de datos

Retorna: output - arreglo resultante

Median(self,input,width) Entradas:

input - Arreglo de entrada width - Tamaño de la ventana

Retorna: output - arreglo resultante

TimeSelect(self) De acuerdo a la fecha del experimento selecciona el periodo de tiempo en segundos UT en el que se consideran datos validos. Entradas: Ninguna Retorna:

f_timedate - arreglo de tiempo en formato datetime f_height - valores de rango en Km f_zon - velocidad zonal f_mer - velocidad meridional f_ver - velocidad vertical f_snr - relacion señal - ruido

Average (self,aver,nhaver)

De acuerdo a la fecha del experimento selecciona el periodo de tiempo en segundos UT en el que se consideran datos validos. Entradas:


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

27

aver - valor entero que indica el periodo de tiempo para el calculo del promedio. Este valor puede ser de 0 - 7, donde: 0: 1 hora 1: 2 horas 2: 3 horas 3: 4 horas 4: 6 horas 5: 8 horas 6: 12 horas 7: 24 horas

nhaver - valor entero que indica el intervalo de rangos

que se promedian por secciones Retorna:

startDTList - Lista que contiene el tiempo en formato datetime

data_fHeigths_List - Lista que contiene el valor de rango para cada periodo de tiempo

data_fZonal_List - Lista que contiene el valor de velocidad zonal para cada periodo de tiempo

data_fMeridional_List - Lista que contienes el valor de velocidad meridional para cada periodo de tiempo

data_fVertical_List - Lista que contiene el valor de velocidad vertical para cada periodo de tiempo

4.2.3. Conversión a CEDAR

bltr_data_conv.py


Realiza la escritura de un archivo en formato CEDAR-ASCII del promedio o consenso de datos en un periodo de tiempo, por defecto el periodo de tiempo es por cada hora del dia en formato UT

Metodo sv2cedar


Metodo __info_cedar

Realiza la escritura de un archivo en formato CEDAR-ASCII. Por cada modo de operación se genera un archivo.


Carga los arreglos de datos para la escritura de datos en formato CEDAR-ASCII

Clase sv

Metodo __info_cedar


Clase cns

Metodo cns2cedar

Carga los arreglos de datos para la escritura de datos en formato CEDAR-ASCII


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

28

Clase sv __init__(self)


sv2cedar(self,output, nmodes, time,height,zon,mer,ver,snr,nchannels,lat,lon) Carga los arreglos de datos para la escritura de archivos CEDAR-ASCII. Por cada modo de operacion se genera un archivo. Dentro de este metodo se llama a __create_madfile Entradas:

output - Archivo de salida, nmodes - modos de operacion time - arreglo de tiempo UT en formato datetime height - arreglo de rango zon - velocidad zonal mer - velocidad meridional ver - velocidad vertical snr - relacion señal - ruido nchannels - numero de canales lat - valor en latitud lon - valor en longitud

Retorna: Vacio

__create_madfile(self,mode,height,zon,mer,ver,snr)

Escribe un archivo en formato CEDAR-ASCII por cada modo de operacion. El modo 1 es para el experimento High Resolution mode 1 y el mode 2 corresponde al experimento Hight Resolution mode 2. Siendo el primer modo para rangos desde 0 - 3 Km. Y el segundo modo para rangos desde 0 - 10 Km. Entradas:

mode - Modo de operacion, valor entero height - arreglo de rango zon - velocidad zonal mer - velocidad meridionl ver - velocidad vertica snr - relacion señal - ruido

Retorna: Vacio

__info_cedar(self) Entradas: Ninguna Retorna:


experimento

Clase cns __init__(self)


cns2cedar(self,output,time,height,zon,mer,ver,lat,lon) Carga los arreglos de datos para la escritura de archivos CEDAR-ASCII. Por cada modo de operacion se genera un archivo. Dentro de este metodo se llama a __create_madfile


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

29

Entradas: output - Archivo de salida, time - arreglo de tiempo UT en formato datetime height - arreglo de rango zon - velocidad zonal mer - velocidad meridional ver - velocidad vertical lat - valor en latitud lon - valor en longitud

Retorna: Vacio

__create_madfile(self,time,height,zon,mer,ver)

Escribe un archivo en formato CEDAR-ASCII por cada modo de operacion. El modo 1 es para el experimento High Resolution mode 1 y el mode 2 corresponde al experimento Hight Resolution mode 2. Siendo el primer modo para rangos desde 0 - 3 Km. Y el segundo modo para rangos desde 0 - 10 Km. Entradas:

time - arreglo de tiempo UT en formato datetime height - arreglo de rango zon - velocidad zonal mer - velocidad meridionl ver - velocidad vertica

Retorna: Vacio

__info_cedar(self) Entradas: Ninguna Retorna:


experimento

4.3. Aplicación Principal. Según el diagrama de programación

corresponde a la clase “bltr_app”.

4.3.1. Módulos. Corresponde al código desarrollado en Python para esta aplicación, se debe diferenciar de aquellos módulos que vienen por defecto en la versión de Python.

customFtp.py

Clase Ftp

__init__(self,host,username,passw,remotefolder) Inicia los miembros de la clase y realiza la conexión FTP según los parámetros de entrada Entradas: host - Define la ubicación o dirección de la pc username - Define el usuario passw - Define el password remotefolder - Define la carpeta o folder remoto Retorna: Vacio

download(self,filename,localfolder) Realizala descarga de un archivo remoto en una carpeta local Dentro de este metodo se llama a __handleDownload Entradas:

filename - Define el nombre del archivo remoto


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

30

localfolder - Define la carpeta de descarga Retorna:

status - Con valor igual a 1 si hay error en la descarga

__handleDownload(self,block)

Maneja la escritura de un bloque de datos Entradas:

Block - bloque de datos

Retorna: Vacio

upload(self,filename,remotefolder) Realizala la transferencia de un archivo local a una carpeta remota Entradas:

filename - Define el nombre del archivo local remotefolder - Define la carpeta donde se transfiere el

archivo Retorna:

status - Con valor igual a 1 si hay error en la transferencia del archivo

dir(self,remotefolder) Indica el folder de trabajo. Con esta función se direcciona a carpetas de una pc remota Entradas: Remotefolder - Define la carpeta remota Retorna:

infoList - Lista que contiene el nombre de los archivos de la carpeta y su tamaño en bytes

folderList - Listado de las subcarpetas existentes dentro de la carpeta actual de trabajo

close(self) Cierra la conexión FTP Entradas: Ninguna Retorna: Vacio

logfile.py

Clase log

__init__(self,parmList,typeList,filename) Crea un log-file personalizado donde se definen el dato y el tipo de datos a registrar. Entradas:

parmList - Listado de parámetros a registrar typeList - Define el tipo de dato de los

parámetros filename - Define el nombre del archivo que será

el log-file Retorna: Vacio

add(self,row,parm,value) De acuerdo a “row” asigna al parámetro un valor. Con “row” igual a cero se tiene en cuenta que el parámetro a crear será “FILENAME” con value que indica el nombre del archivo. Entradas:

row - Indica el nombre de la fila que se va actualizar


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

31

parm - Indica el parámetro dentro de una fila que va a modificar

value - Indica el valor del parametro Retorna: Vacio

get(self,row,parm)

De acuerdo a “row” lee el parámetro indicado. Entradas:

row - Indica el nombre de la fila que se va leer parm - Indica el parámetro que será leido

Retorna:

value - Valor del parámetro, si el parámetro solicitado no existe retorna None.

4.3.2. Métodos. Son las funciones que corresponden a la clase

bltr_app.

__init__(self)

Inicia los atributos de la clase bltr_app. Entradas: Ninguna Retorna: Vacio

setScriptState(self)

Lee los parámetros de entrada que son ingresados desde línea de comandos. Los parámetros desde líneas de comandos son: Requeridos: -- expName -Define el nombre del experimento -- site -Define la ubicación (lugar o ciudad) del

instrumento -- configPath -Define la diección de donde se lee el archivo de

configuración Opcionales: -- year - Indica el año del experimento -- month - Indica el mes del experimento -- day - Indica el dia del mes del experimento Retorna: Vacio

readConfigTable(self)

Realiza la lectura del archivo de configuración y asi se determinan los paremetros necesarios para realizar el procesado de los datos, trasnferencia de archivos por FTP. Entradas: Ninguna Retorna: Vacio

__getValueFromArg(self,strList,sub,float,lower)

Metodo que devuelve el valor de un parámetro del archivo de configuración. Entradas:

strList -Listado de caracteres sub -Parametro a buscar en la lista de

caracteres float -Si es True retorna valor de tipo float


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

32

lower -Si es True retorna cadena de caracteres en minúsculas.

Retorna: val -Valor del parametro

createPath(self)

Crea las carpetas de trabajo temporal. Estas se indican en el archivo de configuración: Local -carpeta principal de trabajo Temp -subcarpeta que contiene los datos de entrada (rawdata)

y los datos de salida (cedardata) resultado del proceso logPath -carpeta donde se guarda el log-file de la aplicación. logBackup -carpeta donde se trabaja temporalmente una

copia del contenido de logPath, cuando el proceso es realizado sin errores se actualiza el contenido de logPath

removePath(self)

Elimina las carpetas de trabajo que fueron creadas para los datos de entrada (rawdata) y de salida (cedardata).

createLog(self)

Crea un log-file personalizado de acuerdo a cada experimento. Se usa el moudlo logfile.py con la clase log().

getFiles(self)

Realiza la descarga de archivos de acuerdo al formato de archivo requerido en cada experimento. Se usa el modulo customFtp.py con la clase Ftp() y el método download. Cada archivo descargado se registra en el log-file

putFiles(self)

Tranfiere los archivos que han sido procesado y convertidos a formato CEDAR-ASCII. Se usa el modulo customFtp.py con la clase Ftp() y el método upload(). Por archivo transferido exitosamente se actualiza el log-file con el método updateLog().

updateLog(self)

Realiza la actualización del log-file


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

33

4.4. Actualización en el servidor JRO1.

Clase createExpWithDir __init__(self,madPath,expTitle,permission,fileDesc,optChar)

Inicia los atributos de las clase. Entradas:

madPath -Directorio de archivos madrigal para agregar a la base de datos

expTitle -Nombre del experimento permission -Con valor igual a cero es un

experimento público y con valor igual a uno es un experimento privado

fileDesc -Es un comentario descriptivo del experimento

optChat -Es el carácter que corresponde al experimento, utilizado para diferenciar las carpetas por cada experimento

Retorna: Vacio

setScriptState(self) Se utiliza para verificar los parametros de entrada necesarios para el proceso de actualización.

createExpWithFiles(self,files,madPath,expTitle,permission,fileDesc,

instCode,category,optChar,dirName,kindat,binPath) Entradas:

files -lista de archivos madPath -ubicación actual de los archivos expTitle -Nombre del experimento permission -define el acceso al experimento fileDesc -descripcion del experimento instCode -valor entero que indica el código del

instrumento category -para indicar si el experimento es en

tiempo real optChar -carácter asignado al experimento dirName -nombre de la carpeta del experimento kindat -valor entero que indica el

procesamiento del experimento. binPath -es la ruta de ejecución de madrigal, en

este caso seria /usr/local/madrigal2/bin. Retorna:

value -Número de archivos agregados a la base de datos

4.5. Ejecucion desde Linea de Comandos.

4.5.1. En el servidor JRO_PROC

./bltr_app.py --expName=”Bltr High Resolution” --site=”Piura”

--configPath=”/home/user/bltr_app” --year=2010

4.5.2. En el servidor JRO1

./createExpWithDir.py --madPath=/usr/local/madrigal2/cedarData

--expTitle=”Bltr High-Res mode 1”

--permission=0

--fileDesc=”Testing Bltr Experiment”

--optChar=”h”


Teléfonos (+51-1)317-2313 - Fax (+51-1)317-2312

34

5. Códigos de las Librerías desarrolladas en Python.

Se adjunta carpeta de archivos con los scripts en Python

Documents

RAADDIIOO VO OBBSSE ERRVA ATTORRIIOO DDE …jro.igp.gob.pe/publications/tecnical_reports/2010/Op_201003.pdf · archivo producto de los experimentos en cada uno de los distintos instrumentos