You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(1) I am considering how to dump evacuees' moving data to a binary data file. A function is added in data_func.py. In sum I learn from FDS, and the output binary data (version 2.3) is compatible with fds prt5 data.
A good thing is that prt5 data file can be visualized by smokeview.
Currently there are problems unsovled for using smokeview to visualize our binary data file. Maybe I will try f2py in numpy to call a Fortran subroutine to dump data. So far the binary data is dumped by using a python script modified from Topi's work.
In fact, numpy provides an easier way to dump data, but probabaly not in prt5 format. For example there is an easy way to save npz data by using numpy.savez(). However, this npz data format is easily handled by python, but not compatible with other program languages. Let me think about it. Comments are welcome.
(2) main.py includes a Tkinter GUI (graphic user interface). I would like to get a simple version with no GUI also. The reason is that there is slight change from Python 2 to Python 3 when Tkinter is used. So I think it is a good idea to separate GUI from the core computation code and get a long-lasting version of core code. GUI will be develop on another thread. --Done (main.py)
The above work is mainly done in the past few weeks. I have realized a non-gui version of the source code, and the GUI is packaged as an independent module in ui.py. As a result GUI is outsourced from the core computation code. The source is also updated from Python2.7 to Python 3. Now the code can be run in both Python 2.7 and Python 3. One problem is whether I should keep using Tkinter GUI or not. Maybe wxPython is also a good choice. A user-friendly GUI is required, but I am not an expert on this issue. Comments are much welcome.
(3) I should pack up main.py into a simulation class and apply OOP method to this program. This idea will be applied soon in version 2.0 of source code. An advantage of using OOP is extracting an independent component to visualize the simulation result. Currently pygame is used to visualize the simulation result. other graphic library can also be applied in this framework. --- Done after Code Version2.0
(4) Add some functions to add walls and doors quikcly in the visualizer screen (show_geom). These functions will greatly facilitate users to create walls and doors before simulation and bing more fun to users. The most difficult thing is using pygame to realize the idea. This is not easy in pygame. -- Done after code version 2.3
The text was updated successfully, but these errors were encountered:
@akmalkhalid Hi, it seems that your fork repo is dis-coupled with my original one. Would you like to fork it again? I have updated the project recently. If you would like to contribute anything, please feel free to let me know. Thank you for your interest.
@zarooba01 Hi, It seems that you are interested in studying the pre-evacuation behavior. Our program also includes this feature, and we highlight the social aspects of this important feature. Would you like to try our program with FDS and let me know what you think? This program is being developed, and please report any bugs if you find one. Your ideas or contributions are much appreciated. Many thanks.
To-Do List:
(1) I am considering how to dump evacuees' moving data to a binary data file. A function is added in data_func.py. In sum I learn from FDS, and the output binary data (version 2.3) is compatible with fds prt5 data.
A good thing is that prt5 data file can be visualized by smokeview.
Currently there are problems unsovled for using smokeview to visualize our binary data file. Maybe I will try f2py in numpy to call a Fortran subroutine to dump data. So far the binary data is dumped by using a python script modified from Topi's work.
In fact, numpy provides an easier way to dump data, but probabaly not in prt5 format. For example there is an easy way to save npz data by using numpy.savez(). However, this npz data format is easily handled by python, but not compatible with other program languages. Let me think about it. Comments are welcome.
(2) main.py includes a Tkinter GUI (graphic user interface). I would like to get a simple version with no GUI also. The reason is that there is slight change from Python 2 to Python 3 when Tkinter is used. So I think it is a good idea to separate GUI from the core computation code and get a long-lasting version of core code. GUI will be develop on another thread. --Done (main.py)
The above work is mainly done in the past few weeks. I have realized a non-gui version of the source code, and the GUI is packaged as an independent module in ui.py. As a result GUI is outsourced from the core computation code. The source is also updated from Python2.7 to Python 3. Now the code can be run in both Python 2.7 and Python 3. One problem is whether I should keep using Tkinter GUI or not. Maybe wxPython is also a good choice. A user-friendly GUI is required, but I am not an expert on this issue. Comments are much welcome.
(3) I should pack up main.py into a simulation class and apply OOP method to this program. This idea will be applied soon in version 2.0 of source code. An advantage of using OOP is extracting an independent component to visualize the simulation result. Currently pygame is used to visualize the simulation result. other graphic library can also be applied in this framework. --- Done after Code Version2.0
(4) Add some functions to add walls and doors quikcly in the visualizer screen (show_geom). These functions will greatly facilitate users to create walls and doors before simulation and bing more fun to users. The most difficult thing is using pygame to realize the idea. This is not easy in pygame. -- Done after code version 2.3
The text was updated successfully, but these errors were encountered: