Sprint 1
| Fecha: | 2014-12-01 a 2014-12-08 |
|---|---|
| Participantes: | @Juanlu001, @AlexS12, @newlawrence, @AunSiro y Carlos Dorado |
| Tareas: | Hito "Sprint 1" |
En esta primera reunión se decidió implementar una función para calcular algunas propiedades termodinámicas básicas a partir de la altura en las tres primeras capas de la Atmósfera Estándar Internacional. Para ello se establecieron la interfaz y los requisitos de la función de forma que se pudiesen traducir en pruebas unitarias:
def atm(h, deltaT=0.0):
"""Standard atmosphere.
"""
pass
- Debe dar el resultado correcto, tabulado en la Atmósfera Estándar de los Estados Unidos (COESA) http://hdl.handle.net/2060/19770009539 (idéntica a ISA hasta 50 kilómetros)
- Las unidades son las del Sistema Internacional, es decir: altura en metros, temperatura en Kelvin, presión en Pascal, densidad en kilogramos por metro cúbico
- La entrada es altura geopotencial, es decir, normalizada con g0 = 9.80665 m / s2.
- Debe aceptar arrays de alturas y devolver arrays de propiedades, para integrarse de forma transparente con otras funciones de NumPy y matplotlib
- En cambio, si el argumento de entrada es un escalar entonces debe devolver escalares también
- Para alturas fuera del rango de validez de la función, se debe emitir un warning y rellenar las posiciones correspondientes con NaN
Aquí están detalladas las Instrucciones para subir el código.
Había tres opciones para el manejo de alturas fuera de rango:
- Continuar con el cálculo sin hacer comprobaciones.
- Emitir un error si alguna altura estaba fuera de rango.
- Emitir una advertencia y continuar el cálculo para los valores válidos.
Se consideró adecuado dar algún tipo de feedback al usuario (esto descartaba la opción 1), pero interrumpir el cálculo sobre un array de alturas cuando uno de los valores es inválido parecía exagerado y posiblemente poco operativo (opción 2), así que al final se optó por la tercera posibilidad.
- Se comentó la posibilidad de diseñar la implementación para permitir modelos arbitrarios de temperatura, es decir, que pudieran ser no lineales. Puesto que esto complicaría el código y no estaba clara la utilidad real, se abrió la tarea #2 para investigarlo.
- Se propuso vectorizar el argumento ΔT para contemplar algunos casos de uso particulares, pero daba lugar a confusión y complicación en el código así que se descartó.