Edit Records Directly via the Record View
Make it possible to edit the FDS input file directly within PyroSim's record view.
In this community, you can submit ideas, vote on existing ideas, or add comments.
To submit an idea, please click the new idea button below. You will then be asked to add a title and choose a campaign for the new idea. You will also have the option to add tags to the idea. To vote on an idea, simply click the up or down thumb to the left of the idea title/description. And to add a comment, click in the box below the idea.
If you would like to see all ideas created with a specific tag, you can click on the word or phrase via the tagcloud in the left navigation area under "What we're discussing". You can also view ideas sorted by Campaigns from the left navigation area. To return to this page, click the All Ideas link.
Make it possible to edit the FDS input file directly within PyroSim's record view.
Make it possible/easy to queue multiple FDS runs, so that a new case begins after the completion of another.
For example, I want to vary input parameters for a given scenario with a relatively short run time. I set up my cases in advance, run them overnight, and look at the results the following day.
The possibility of adding slicefiles and isosurfaces to Pathfinder for combined visualization of evac and smoke. Maybe even the smoke? :-)
Ability to run PyroSim or Pathfinder on the Mac without a Windows virtual machine.
Basically extending the group functionality to other items than just geometry
Don't allow any more that Obstacles are not align with the MESH-Grid. That would be a good and easy tool.
Currently, Pathfinder provides an option to set the pre-movement time as either constant, uniform or normal distribution. I'd like to see this being expanded to at least a log-normal distribution which has been shown to more accurately represent pre-movement time of people in buildings.
While I'm at it today, how about another. Currently, to put in discrete points from curve to an FDS input parameter (e.g. HRR, thermal properties) you either need the raw data itself or you need to manually pick the points of the curve and input them line by line. Currently, I use Plot Digitizer (http://plotdigitizer.sourceforge.net/) to make this process smoother. With that, you import an image of a curve, set the axes ...more »
While I'm at it today, how about another.
Currently, to put in discrete points from curve to an FDS input parameter (e.g. HRR, thermal properties) you either need the raw data itself or you need to manually pick the points of the curve and input them line by line. Currently, I use Plot Digitizer (http://plotdigitizer.sourceforge.net/) to make this process smoother. With that, you import an image of a curve, set the axes and scale, and start clicking data points on a curve. What you get is a columnized data output that you can copy and paste into Pyrosim.
Pyrosim would be just THAT much sweeter if I didn't have to take the extra steps to input HRRs, cone data or whatever else requires a curve. Happy Friday.
« less full details »
Ability to run PyroSim on Linux without a Windows virtual machine.
Would it be possible to expand the note taking capabilities of Pyrosim beyond that of FDS? I would like to have a feature that at a minimum allows you have the same "FYI" capability for any particular line in an input file. At the moment, the FYI input feature only exists for reactions, materials, and surfaces. It does not exist for things like devices, obstructions, holes, etc. For fire reconstructions, this would ...more »
Would it be possible to expand the note taking capabilities of Pyrosim beyond that of FDS?
I would like to have a feature that at a minimum allows you have the same "FYI" capability for any particular line in an input file. At the moment, the FYI input feature only exists for reactions, materials, and surfaces. It does not exist for things like devices, obstructions, holes, etc.
For fire reconstructions, this would aid me in hypothesis testing and version control. At the moment I will keep a hand-written log, but the digital copy would streamline my process (for safety, I will keep hand-written notes still).
What would really put the icing on the cake is if I could effectively mirror my FDS simulation logbook in Pyrosim. For any one particular case, I might have a lot of notes I need to take about why I put particular input parameters into the simulation. Right now, that amount of note taking information would exceed the amount of information that seems reasonable for the FYI tag. Nevermind, when I reach my final simulation iteration, I would like to quickly and easily remove that information to make my input files readable to my peers, instead of having to manually delete each note.
I'm not sure how useful this might to others, but I've always had to make multiple iterations for any simulation (including simple homework problems) and take notes to keep myself in check. Thanks!
« less full details »
Make it possible to name timer device controls. When reading the input file, names like TIMER1 and TIMER2 make it difficult to tell at a glance what a particular timer is controlling.
Now you have to right-click and go properties for a obst to define it as display-outline. Could this be implented directly via right-click menu in same way as hide/show objects?
An algorithm that optimises the evacuation time based on choice of exit of occupants. I guess it needs to be a iterative algorithm. This would be very useful to benchmark the hydraulic capacity of the provided exits.
The most obvious function or tool would have to be "Soot Deposition".. Clearly there have been many scrutinizing feedback on the soot concentration that FDS produces..
When more than one path lead to the same exit, the current way to specify the desired route is by using waypoints. However, this could lead to undesired counter-flows of "impatient" occupants when finding an alternative to the shortest path because they still try to go back to their first waypoint. One way to avoid this is by including a black list of internal doors for each behavior that cannot be trespassed by those ...more »
When more than one path lead to the same exit, the current way to specify the desired route is by using waypoints. However, this could lead to undesired counter-flows of "impatient" occupants when finding an alternative to the shortest path because they still try to go back to their first waypoint.
One way to avoid this is by including a black list of internal doors for each behavior that cannot be trespassed by those occupants.
« less full details »
It would be great if some doors between rooms could be identified as "one way doors", to avoid undesired counter-flows.
I thought it might be useful to be able to specify a room or area that would override occupant characteristics whilst agents were located in that room/area. The primary example I’m thinking of is related to walking speed. If I want to model a scenario of a particular room being smoke logged or where the lights are assumed to fail in that room, the occupant walking speed (which under the occupant attributes is set to 1 ...more »
I thought it might be useful to be able to specify a room or area that would override occupant characteristics whilst agents were located in that room/area. The primary example I’m thinking of is related to walking speed. If I want to model a scenario of a particular room being smoke logged or where the lights are assumed to fail in that room, the occupant walking speed (which under the occupant attributes is set to 1 m/s for arguments sake) would be overridden when an agent enters that room, reducing the walking speed by some factor (down to say 0.3 m/s). This may be useful for other occupant attributes, but I’m not sure.
It would be even better if this could also incorporate a temporal aspect such that for the time period t1 to t2 the walking speed within the area is reduced by X% and for the time period t2 to t3 the walking speed within the area is reduced by Y%. This would provide a way to take account for results from fire / smoke modelling without actually having to fully integrate the fire model.
« less full details »
Add the option to use non-scientific notation for numbers in the record view. This would make debugging decimal place errors easier and make the input file cleaner and more presentable.
would it be possible to make a new box under the fds simulation info for the ini file to be able to change colors for iso files and that kind of stuff
The color-picker in Pyrosim is quite extensive, but does not allways match the colors supported by FDS/Smokeview: http://fire.nist.gov/fds/color_table.html
It would be a great help for visualization if the FDS-colors could be picked as a separate tab (a fourth tab?!).
Social Web