Unirse

Cuidado con la herramienta sombras de SketchUp

  • Creado el 21-12-2014 con 8 publicaciones
  • VISTO 14358 VECES
  • Pablo Álvarez Pena
    el 21-12-2014

    Se ha tomado una foto de un edificio real a estudio y se ha comparado (en el mismo intervalo temporal) con la simulación de sombreamiento que incorpora SketchUp. Este edificio se encuentra en el municipio pontevedrés de Baiona, próximo a la ciudad de Vigo. La conclusión a la que llego es que hay que tener cuidado con esta herramienta, ya que por defecto elige el valor de la UTC del archivo climático introducido en OpenStudio. En la siguiente imagen se puede apreciar como en realidad el valor de UTC que más se correspondería con la realidad no sería el que viene por defecto en el archivo climático (+1:00), sino que sería +2:30 (valor que curiosamente no está incluido entre los disponibles, por lo que habrá que elegir entre +2:00 y +3:00).

    Lo curioso es que si se cambia el valor de UTC en SketchUp en el apartado "ajustes de sombras", esto puede afectar al modelo, y generar una advertencia a mayores durante la simulación. Aún estoy estudiando si tiene impacto en el resultado o simplemente es una advertencia que se puede despreciar, en principio parece que no es relevante.

    Puesto que EnergyPlus trabaja con la hora solar, dependiendo esta de la posición del edificio, la variación del valor de UTC en el fichero climático únicamente debería afectar a los schedules definidos. Si hay una desviación entre la realidad y el modelo, imagino entonces que habría que modificar en ese caso el valor de zona horaria del EPW o todos los schedules definidos.

    ¿Qué opináis de esto? ¿Hábeis tenido algún problema también relacionado con este tema? ¿Comprobáis los resultados arrojados por la herramienta con la realidad antes de tenerlos en cuenta?

    Josep Sole Bonet
    el 30-12-2014

    Creo que la heramienta de sombras de Sketchup no modifica para nada los datos introducidos en el fichero IDF. (de hecho en el pluguin de OpenStudio de Sketchup no se introduce el emplazamiento y este se introduce en OpenStudio application cuando se indica el fichero climatico) 

    En la herramienta de sombras de Sketchup se deben introducir los datos de la zona horaria que sea procedente.

    Lo que que se debe hacer es introducir los schedules en OpenStudio / Energy plus con hora solar para que sea coherente con los calculos del motor de Energy plus y después si se analizan resultados horarios se debe tener en cuenta que estos son con hora solar y no "oficial".

    Pablo Álvarez Pena
    el 31-12-2014

    He vuelto a realizar la comprobación, y pude obtener las siguientes conclusiones.

    1) Coincido contigo en que creo que no se modifican los datos, (pero lo curioso es que el EPW que cargamos en el OSM si que influye en el valor de UTC de la herramienta de sombras de SK). Como mucho, el cambiar el valor de UTC generará una advertencia a mayores (al realizar la simulación) de este tipo:
    “Weather file location will be used rather than entered (IDF) Location object. ..Location object=SITE 1 ..Weather File Location=Baiona - - MN6 WMO#=999 ..due to location differences, Latitude difference=[0.00] degrees, Longitude difference=[0.00] degrees. ..Time Zone difference=[1.0] hour(s), Elevation difference=[0.00] percent, [0.00] meters.”
    Pero los resultados se mantienen idénticos en ambos casos (con el valor inicial de UTC y el nuevo).

    2) Acerca de lo de introducir los datos de zona horaria que correspondan precisamente es en lo que discrepo, ya que el problema es que introduciendo los datos de zona horaria que corresponderían a esta zona (UTC +1:00) en la herramienta de sombras de SketchUp, esta simulación no se corresponde con la realidad (aparece en la imagen que subí arriba una fotografía del edificio real comparada con el modelo), por lo que si tenemos en cuenta los datos que arroja este procedimiento podemos llegar a conclusiones imprecisas. Por si fuera un error mío lo comprobaré en futuros edificios, pero creo que no hay error.

    Recapitulando: Puede ser necesario cambiar el valor de UTC de la herramienta de sombras de SK para que coincida (lo simulado con ella) con la realidad. Esto puede generar una advertencia a mayores al realizar la simulación mediante OS, pero esta no afecta a los resultados.

    Otro tema a debate es que CREO que la herramienta de sombras de SketchUp no tiene en cuenta el horario de verano (algo que en cambio si se puede especificar en en OpenStudio Aplication).

    Aprovecho para desearte un feliz y próspero año nuevo, a ti y a todos los usuarios. Felices fiestas.

    Josep Sole Bonet
    el 31-12-2014

    1) el warning que indicas qparece siempre que en el objeto del idf site:location aparecen datos (longitud / latitud/zona horaria / altura) no son 100 % coincidntes con los del fichero. En caso de no coincidencia se usan los del Fichero por lo que no hay que preocuparse del dato site:location

    2) lo que visualiza Sketchup en su modelador de sombras no tiene ninguna relacion (aparte de la geometria) con lo que se introduce en OpenStudio/Energy plus. Convendria mirar mejor en las informaciones de Sketchup como se efectua la modelizacion en relacion a la zona horaria y horario de verano

    3) OpenStudio/Energy + efectuan los calculos con "hora solar" y no con hora oficial debe tenerse en cuenta esta circunstancia al introducir los perfiles horarios y al interpretar los datos de los resultados.

    Pablo Álvarez Pena
    el 02-01-2015

    1) el warning que indicas qparece siempre que en el objeto del idf site:location aparecen datos (longitud / latitud/zona horaria / altura) no son 100 % coincidntes con los del fichero. En caso de no coincidencia se usan los del Fichero por lo que no hay que preocuparse del dato site:location

    Totalmente de acuerdo.

    2) lo que visualiza Sketchup en su modelador de sombras no tiene ninguna relacion (aparte de la geometria) con lo que se introduce en OpenStudio/Energy plus. Convendria mirar mejor en las informaciones de Sketchup como se efectua la modelizacion en relacion a la zona horaria y horario de verano

    Sobre esto yo diría que sí que tiene que ver, pero que en realidad no afecta a los resultados, tan sólo hay que tener en cuenta que mejor revisar los valores en SK porque pueden cambiar. Si jugamos con el valor de zona horaria en los EPW, el valor de UTC en la herramienta de sombras puede verse afectado. Viceversa también, pero como se coje el valor de zona horaria del EPW entonces da igual, ignorandose la advertencia en el caso de que apareciese.

    Dejo en el siguiente link un archivo .doc en el que he ido tomando notas sobre la marcha acerca del procedimiento que he seguido para llegar a estas conclusiones.

    https://dl.dropboxusercontent.com/u/66291364/Doc01.docx 

    Voy a intentar preguntar al soporte de SK, o buscar en la ayuda, acerca de la otra cuestión, a ver que me responden y así lo confirmo, pero CREO que no se tiene en cuenta el horario de verano en la herramienta de sombras, por lo que habría que cambiar entonces manualmente el valor de UTC dependiendo de si es "verano" o en "invierno" para obtener conclusiones rápidas y precisas como paso previo a las simulaciones con E+.

    3) OpenStudio/Energy + efectuan los calculos con "hora solar" y no con hora oficial debe tenerse en cuenta esta circunstancia al introducir los perfiles horarios y al interpretar los datos de los resultados.

    Totalmente de acuerdo. La única duda que me surgió era si los schedules estaban asociados a la hora oficial en lugar de la hora solar, y si era el valor de zona horaria en el EPW el que realmente relacionaba la hora oficial con la hora solar, puesto que al variar únicamente el valor de zona horaria en el EPW los resultados varían. Aclarado, por lo que me olvido de la hora oficial.

    De todos modos, si realmente se trabaja para todo con la hora solar, no entiendo muy bien que pinta el dato de zona horaria. Que la hora solar dependa del dato de longitud y latitud es lógico para poder obtener resultados precisos, pero el dato de zona horaria realmente ¿qué aporta? (porque afectar afecta a los resultados) más teniendo en cuenta que es una decisión en algunos casos "política" y que no se ajusta a la lógica.

    Jordi Rodriguez
    el 04-01-2015

    UTC Vs SOLAR

    Intentaré exponer mis conclusiones que justifican que hay que tener tanto en cuenta el horario solar como el UTC. Antes de todo enseñar-te Pablo, que a mi no me ha dado problemas el UTC, en un edificio que he estudiado a fondo tengo un correcto parametro de sombras, teniendo en cuenta el improvisado metodo trigonometrico de toma de datos.

    Comentais que solo se puede introducir el emplazameinto desde OS, correcto, aunque desde SKP también se puede geolocalizar siempre se prioriza los datos introducidos desde OS, pero el horario solar ya estaria introducido con esta geolocalización sin tener que pasar por OS.

    Pablo, como bien dice Josep no sirve de nada modificar UTC desde el editor de sombras de SKP, haz-lo solo en el .epw, però es necesario canviar el convenio de todo un pais para un estudio?
    En una cosa tienes razón, aunque tengas horario de verano introducido en OS, las sombras en SKP no aparecen modificadas, siempre tienenun valor UTC +1 o el del fichero climatico introducido.

    CASO DE ESTUDIO, BARCELONA VS PONTEVEDRA

    Estoy en total desacurdo con lo expresado por Josep Solé que "sólo" se tiene que tener en cuenta el horario solar. Esto me genera muchas dudas de procedimiento.

    Para poder entender mejor la conveniencia de tener en cuenta tanto los horarios solares como "politicos" he creado este estudio improvisado. El estudio se basa en comparar un mismo volumen, de un mismo UTC, pero en dos horarios solares distintos, uno en Barcelona y el otro en Pontevedra. El sistema utilizado para la comparativa en tu doc, Pablo, está bien, pero en este caso no he encontrado otro sistema más idoneo y visual que la luz. Cuando en ambas localidades tenenmos una hora de 09:55, en Barcelona tenemos una hora solar de 08:55 (y algunos segundos de diferencia) y en Pontevedra de 08:16. Estas diferencias se pueden observar en las imagenes de las dos localidades, ambas tomadas a las 10:00 del 21/06 (siempre Pontevedra a la izquierda y Barcelona a la derecha). Las dudas que me genera trabajar solo con horario solar provienen de aquí, si existen dos ofcinas a estudiar, una en cada localidad y las dos tienen un horario igual, de 8 a 20 horas por ejemplo, tenemos que adaptar las 08:00 de la mañana a una hora menos en el caso de Barcelona y a una hora y 39 minutos menos en el caso de Pontevedra? y hay que tener en cuanta este desfase en todos los schedules introducidos?

    En estas imagenes se demustra que el horario solar está perfectamente definido con el emplazameiento dado por .EPW, tenemos más luz en Barcelona que en Pontevedra a la misma hora del mismo dia del año. Ya tendriamos justificado empíricamente la diferencia de un horario solar en un mismo UTC. Pero vamos a darle numeros, mediante los resultados de consumo.

    Os propongo esta comparativa con la que se podra visualizar bien la diferencia entre el horario solar y el UTC. Volumenes de cristal con sensores de iluminación. Supongamos que estas dos oficinas, Pontevedra y la otra en Barcelona tienen exactamente el mismo regimen de iluminacion "inteligente". Y que tienen un horario identico, abren de 08 a 20. Solo se abrirá la luz cuando el espacio esté por debajo de los 500 lux, con estas diferencias de consumo veremos como afecta el horario solar en un mismo UTC. (siempre POntevedra izquierda y Barcelona derecha)

    Prueba 1- UTC +1 sin horario de verano

    Prueba 2- UTC +1 con horario de verano desde OS, desde el primero de marzo hasta el primero de Octubre

    Tambien he creado una hipotesis con un UTC 0 en Barcelona i el valor final a sido de 32.162 kWh

    A ver a que consclusiones llegais?

    Pablo Álvarez Pena
    el 07-01-2015

    UTC VS SOLAR

    Antes de todo enseñar-te Pablo, que a mi no me ha dado problemas el UTC, en un edificio que he estudiado a fondo tengo un correcto parametro de sombras, teniendo en cuenta el improvisado metodo trigonometrico de toma de datos.

    Interesante que siendo improvisado te ha dado bastante precisa la comparativa en Barcelona entre realidad y resultados. Gracias por compartirlo.

    Si realmente la herramienta de sombras de SK no tiene en cuenta la aplicación del horario de verano, habría que tener cuidado con el valor de UTC porque para un mitad del año realidad y “modelo” coincidirían, pero para la otra mitad si no se cambia el valor de UTC estaríamos perdiendo precisión en las conclusiones que pudiésemos obtener porque la diferencia entre el valor de UTC sería de 1 hora. En el caso de que la herramienta sí que tuviese en cuenta en horario de verano, entonces para el caso de Barcelona imagino que no habrá problemas en este sentido.

    Pablo, como bien dice Josep no sirve de nada modificar UTC desde el editor de sombras de SKP, haz-lo solo en el .epw,

    Para el análisis de resultados en OS coincido contigo y con Josep en que no sirve de nada (ya que como dije, no influye). Me refiero para el análisis de resultados en SK con la herramienta de sombras, es decir al análisis de sombras sólo en SK como paso previo a la simulación con OS, no me debí explicar bien.

    però es necesario canviar el convenio de todo un pais para un estudio?

    No se cambia el convenio de todo un país para un estudio, sino que se hace un estudio para ver el impacto acerca de cambiar dicho convenio y después tomar decisiones. En Galicia (también valdría para cualquier zona de la península) no hace mucho surgió el debate de si modificábamos la zona horaria a la de Portugal con el objetivo de ahorrar energía. Aquí se afirmaba que con tan solo esa medida ya se ahorraba mucha energía, pero ¿eso es cierto? y ¿cuánta? para saber si merece la pena. Las medidas de gestión pueden tener gran impacto en el ahorro energético, como por ejemplo la implantación del horario de verano, y simplemente son medidas “políticas” que creo que pueden ser interesantes en lo que eficiencia energética se refiere. Creo que estudiar el impacto del cambio de zona horaria puede ser interesante de cara a obtener una postura de a favor o en contra.

    CASO DE ESTUDIO, BARCELONA VS PONTEVEDRA

    Muy interesante y visual tu demostración acerca de la relación entre el horario solar y la información del EPW.

    tenemos que adaptar las 08:00 de la mañana a una hora menos en el caso de Barcelona y a una hora y 39 minutos menos en el caso de Pontevedra? y hay que tener en cuanta este desfase en todos los schedules introducidos?

    Para intentar averiguarlo, estoy intentando este procedimiento.

    1)      Construcción de un “edificio” para “experimentar” (un simple cubo de 5x5x5 metros con 2 ventanas y materiales de plantilla para hacerlo rápido y sencillo). Se reduce el periodo de simulación a 1 semana. Se introducirá el EPW con las coordenadas latitud longitud de la localidad 1.

    2)      Analizar la evolución de la energía “hora a hora” en dicho período, y almacenar esos resultados.

    3)      Definir un pico de consumo de 1 hora (en el schedule se utilizaría la hora “oficial” y luego ya se vería lo que pasa en los resultados de la simulación que estarían con la hora solar), para visualizarlo en los resultados “hora a hora”.

    4)      Luego hacer lo mismo pero introduciendo un EPW exactamente igual salvo por el dato de longitud latitud que sería el correspondiente a la localidad 2. Y guardar los resultados para comparar y obtener las conclusiones. También variaría el valor de zona horaria en el EPW para ver su efecto, aunque imagino que tan sólo movería hacia adelante o hacia atrás dicho pico 1 hora cada valor a mayores o a menores que introduzcamos de zona horaria)

    El problema es que me estoy encontrando que en OS 1.5 al definir el pico de consumo (ahora hay 2 maneras diferentes de definir las "loads" al parecer, una desde “space types” y otra desde “facility”)  en los resultados no aparece su influencia, cosa que no me ocurría al manejar versiones anteriores. Es decir, me sale que el resultado es el mismo con cargas que sin cargas, estoy intentando solucionarlo para poder dar una respuesta y sino probaré a hacerlo con versiones anteriores.

    (Aunque me gusta tu procedimiento estoy probando con otros porque aún no tengo mucha soltura programando iluminación “inteligente” en los modelos. De todos modos tanto con uno como con otro deberíamos llegar a los mismos resultados)

    Jordi Rodriguez
    el 11-01-2015

      No  te engañare si admito haber-me perdido un poco. Estamos complicando esto demasiado, es todo mucho más simple. Resumiré:

    - El horario solar viene determinado por la posición del inmueble mediante el archivo ckimatico.

    - En este mismo archivo epw viene el valor UTC del pais en el que se encuentra.

    - En aquellos paises que se aplique horario de verano, se debe seleccionar desde OS, no viene asociado al archivo climatico ni sus sombras son visibles en SKP.

    Los resultados que quieres los tienes arriba, tienes resultados de UTC 0, UTC 1 (con y sin horario de verano). Para mejorar su visualizacion he ampliado los graficos (Pontevedra arriba y Barcelona abajo).

    Para que puedas hacer tus propios estudios con esta misma plantilla te la adjunto en el link:

    https://www.dropbox.com/s/z313mfgws1pzt1q/test%20light.osm?dl=0

    Calculalo con un UTC +2. Pero ten en cuanta que este es solo un pequeño parametro dentro de todo el consumo de un pais, no se puede determinar si usamos un horario correcto comprobandolo solo con la iluminacion inteligente. Hoy en dia, la inmensa mayoria de empresas, cuando abren persianas, abren tambien luces.