Radiation daysim not running in Ubuntu

[jimenofonseca]

The problems seems to happen due to Daysim. The MIT senseable lab just released Daysim with a license that allow us to absorb it. could we do this so we install daysim automatically with CEA? that will be just perfect so we avoid further bugs.

The repository is this: https://github.com/MITSustainableDesignLab/Daysim

[daren-thomas]

I'll take a look at this. What is the timeframe? What milestone are you aiming for?

[jimenofonseca]

@daren-thomas here i found a solution for Ubuntu MITSustainableDesignLab/Daysim#1 (comment)

[roglen]

After installing daysim on ubuntu with the MIT link above i get the following error when executing the radiation_main file.
Daysim sems to run at least to some degree just before the error, but the .wea file is never created.

[roglen]

I have just encountered the same error when installing CEA on windows.
I believe that the error stems from the fact that the TEMP variable path is not being read correctly because my username has a blank space.

I have added the following to the \CityEnergyAnalyst\docs\known-issues.rst in my current branch (i1031).

Error encountered if User name has a blank space.
In the daysim_main.py file, an error is called that the .wea weather file cannot be found.
In the subfiles inputlocator.py -> tempfile.py, the environment variable is not correctly read if the username contains a space.
E.g. if the original path for the TEMP environment variable is:
C:\Users\Mister Tester\AppData\Local\Temp
it is read as:
C:\Users\MisterT~1\AppData\Local\Temp
As this directory does not exist, an error is called.

[daren-thomas]

@roglen hm... seems like those are two different issues, but i need to investigate. also... i wonder if a "known issues" document is necessary or if we should just point to the issue tracker? (saves us the maintenance of the document and the issue tracker will always be more up-to-date...)

[roglen]

I added it to the existing known issues document under:
\CityEnergyAnalyst\docs\known-issues.rst
which already contains some other points.

It was @jimenofonseca 's idea so i think i'll pass the question on to him.

[jimenofonseca]

@daren-thomas great idea, we can definitely point to here in the documentation. @roglen thanks for defining the problem in the docs anywise

[daren-thomas]

@roglen, yes, thanks for debugging this! i hope to get around to working on it tomorrow. i will create an issue for linking to the issues from the known issues document.

[daren-thomas]

@roglen, I was able to reproduce the error you got, pushing updates to your pull request. I am now trying to fix the problem.

[daren-thomas]

First step: pyliburo just assumes epw2wea is in the $PATH. You can fix this by doing something like: export PATH=/home/user/Daysim/bin:$PATH (or similar, depending on how and where you installed Daysim). This then brings a new error message:

Traceback (most recent call last):
  File "/home/user/anaconda2/envs/cea/bin/cea", line 11, in <module>
    load_entry_point('cityenergyanalyst', 'console_scripts', 'cea')()
  File "/home/user/temp/CityEnergyAnalyst/cea/interfaces/cli/cli.py", line 33, in main
    script_module.main(config)
  File "/home/user/temp/CityEnergyAnalyst/cea/resources/radiation_daysim/radiation_main.py", line 225, in main
    radiation_singleprocessing(rad, geometry_3D_zone, locator, config.weather, settings)
  File "/home/user/temp/CityEnergyAnalyst/cea/resources/radiation_daysim/radiation_main.py", line 182, in radiation_singleprocessing
    daysim_main.isolation_daysim(chunk_n, rad, building_dict, locator, weather_path, settings)
  File "/home/user/temp/CityEnergyAnalyst/cea/resources/radiation_daysim/daysim_main.py", line 153, in isolation_daysim
    solar_res = rad.eval_ill_per_sensor()
  File "/home/user/anaconda2/envs/cea/lib/python2.7/site-packages/pyliburo/py2radiance/__init__.py", line 717, in eval_ill_per_sensor
    res_dict_list = self.eval_ill()
  File "/home/user/anaconda2/envs/cea/lib/python2.7/site-packages/pyliburo/py2radiance/__init__.py", line 697, in eval_ill
    ill_file = open(ill_path, "r")
IOError: [Errno 2] No such file or directory: '/tmp/temp0/res/temp0.ill'

[daren-thomas]

@roglen - the error above seems to also be a pyliburo problem, this time with the Rad.eval_ill_per_sensor() function. I don't know when the temp0.ill file gets written. You might want to contact Kianwe for this (@chenkianwee could you please help diagnose this bug?)

[daren-thomas]

@jimenofonseca it seems we are running on an outdated version of pyliburo - it's not even called that anymore, but instead py4design. Are you still in contact with @chenkianwee? We should probably upgrade.

[jimenofonseca]

Hi, i think we cannot afford an update at this time. It took a year to get it up and running... what about pipe dreams??? On 27 Feb 2018, 22:28 +0800, Daren Thomas <notifications@github.com>, wrote: @jimenofonseca<https://github.com/jimenofonseca> it seems we are running on an outdated version of pyliburo - it's not even called that anymore, but instead py4design. Are you still in contact with @chenkianwee<https://github.com/chenkianwee>? We should probably upgrade. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#964 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIjrguGzyrmKqRqFeEYqdGsFtnJ7eWb_ks5tZBD6gaJpZM4RffGu>.

[daren-thomas]

@jimenofonseca - problem is, we're running into issues with the current version. And even if we fix the errors - we can't get those back into py4design, so the would get lost. I was hoping @chenkianwee would have an idea of how much work it would take to upgrade? Is it just the name of the library that changed? Or did the rest of the package also move around?

[chenkianwee]

Hi pyliburo went thru a major refactoring. I told Jimeno about it when I was refactoring it to make sure it wont affect CEA. Some of the modules are moved around and some functions name and inputs are changed to improve the usability of the API. But the error shown here is from the py2radiance module, which did not went through major changes. It is essentially looking for the result file from DAYSIM, and the fill is either not there, so what I think looking at the error msg, it seems like its either one of these 1.) there is an error in specifying the file directory 2.) the daysim simulation was not successful.

[daren-thomas]

@chenkianwee I noticed with the first error, that pyliburo was not checking the return codes of the programs it runs. that is how our error was not found earlier - when using subprocess, the proc object also includes information about the return code (0 for a-ok, non-zero for error) and stderr.

[chenkianwee]

true I should have capture the message so that it is easier to debug.

[daren-thomas]

@jimenofonseca, @roglen - I'm bumping this to the next milestone. We don't have time before the executive course to upgrade pyliburo dependency (#1088) and i believe we need to do that to move this issue forward.

[jimenofonseca]

It runs since the PR #1747