drjfloyd
commented
1 year ago I have done something like this before in development of FSSIM. There isn't a generic way in Fortran to read in an input file and have it change an arbirtrary source variable. Each source variable you want to change requires its own development effort. Even with something like json. We could use some existing git fortran project for reading a json file, but the parsing of that file into changing FDS variables means code is needed for every variable in FDS that gets changed.
Easiest would be things we can tie to existing control function capability or ramps:
- For example, opening/closing a door in FDS is done by assigning a DEVC_ID or CTRL_ID to an OBST or HOLE. If we had a special control function type, say 'EXTERNAL', then in the routine for updating control functions we could read the file and set the control function state.
- We could add an EXTERNAL flag to the RAMP namelist input. In this case we would not look to read in a list of T,F vaues. Instead, in the function for evaluating a ramp, it would look for the file and take the value that is there. Things like sprinkler flowrates, particle paths, vent flow rates, etc. could all be handled like this with minimal development effort.
Any new output also requires development effort and long term maintenance effort. We already write a number output files with QUANTITY choices that cover pretty much everthing FDS computes. Is a new output file really needed? For example, if a sprinkler hydraulic tool needs to know what heads have operated, it can just look at the existing devc_ctrl_log file. For a particle representing an agent, we can get data for that particle's exposure via the normal devc.csv file (Though here I think we'd need to add logic so that we use the particle X,Y,Z to set the IJK for the device. I don't think we do that now).
bwklein
I know you are busy with FDS 7 development now, and this isn't an urgent feature request, but I wanted to document some ideas that have come from past discussions with Kevin, and some interested users of FDS.
The high-level concept is to provide a way to pass information into and out of FDS through a text file that can be updated manually or by tools external to FDS and then be read/used by FDS to set variables and states as more dynamic input to the simulator.
The file format should be something easy to read by people, but even easier for programmatic updates. I can imagine it working well in a format the provides key/value pairs at a minimum, with a potential for more complex data structures as needed. One very common/popular format would be JSON, but I can imagine other formats working as well. I could see something as simple as CSV working too, but it would require more repetitive data in columns for more complex data types.
FDS would look for this file in the run directory and if it exists, parse it to initialize these variables in memory. During the run this file would be read for updates to the data values and if they are changed in the file, the changes would be reflected in FDS. If something in FDS changes what those values should be, then it writes the updated values to the file.
External tools could also be monitoring the file and performing the same kind of read/write updates to values.
Through this mechanism, an external tool could provide information to FDS to change the simulated state and likewise use updated information in the file to change the external application state.
Through this bidirectional coupling the FDS simulation can be updated dynamically.
Here are a couple of example use cases where this could be useful.
I am sure many other examples can be developed. Overall, making this as generic as possible would be flexible and should accommodate any number of use cases.