External Control: adding a Pause at external DT for read results and process new RAMP and CTRL values

[RIO4FDS]

The idea is to allow an iteration between external codes and FDS by making a Pause at external DT for external codes to read FDS results and process new RAMP and CTRL values.

[drjfloyd]

I don't think we want the behavior to be to stop and wait. For engineering calculations you already have many seconds of wall time for 1 s of simulation time. If FDS progresses a few timesteps (generally ~1E-3 s for engineering calcs) while waiting for new inputs, that is unlikely to cause large timing errors except for very simple test case type geometries. I am going to close this for now. I'd like to better understand the use case were you would need FDS to wait.

[RIO4FDS]

Hi Jason, I have not changed the default behavior.
I am trying to create a connection for future interactions. I can give you one example of use: for the last couple of months I have been running cases where a python code runs at the same time as FDS and calculates values for mass flow of fuel and loss in HVAC ducts based on FDS results for pressure and thermocouples in order to recreate a real test scenario. Both codes exchange data and flags during the FDS running.
Back when we had a two-way coupling procedure between FDS and FEM, the framework was the same. Pause FDS until FEM runs and returns results to be input in FDS. Does it take time? Yes. Is it needed? Depends on the case.

I totally understand your concerns about running time. In the actual procedure (which is still default) I can read FDS results and write new inputs to be read in the next External DT. It will always have one DT as delay. For some applications, it could be necessary to follow the input in external file more closely and the time invested in it is not that high. Let's assume a case that runs for 3600s of simulation and DT is 2s. If the pause and go procedure takes 10s (exaggerating), it will be 5 hours of communication time. Some of those complex scenarios can run for 5 days (or more). However, the user can still decide if this time is necessary, or change the DT. If DT changes for 5s, the communication time reduces to 2 hours. Keep in mind I am exaggerating in the 10s prediction for the pause and go procedure. Of course it depends on how much calculation you need to do to create a new input file, for most applications it is very short, for two-way coupling with FEM this time was larger for most FEM applications (but still needed).

As I said in the beginning, I am trying to create a connection for future interactions. I do not intend to change the default behavior without a discussion about that. It will be my pleasure to talk with you about it if you want to.

Regards,
Julio

[drjfloyd]

Thanks for the explanation. I agree this would be useful. I'll add the concept in.

[drjfloyd]

Juilo,

See this PR: #13136

I made a few tweaks to your concept.

-changed inputs DT_EXTERNAL_HEARTBEAT and EXTERNAL_HEARTBEAT_FILENAME (both must be set). This file is serving the function of a heartbeat process.
-we don't want to have an infitnite loop waiting for another process. So changed so that if this feature is enabled, it checks once a second up to DT_EXTERNAL_HEARTBEAT. Then either continues on or fails FDS with an error error (default behavior is to stop FDS using the flag HEARBEAT_FAIL).
-It occurred to me that it might be useful for debugging / QA to know what all the inputs to FDS to were. So set it that you could specify a filename in the heartbeat file. If the heartbeat file is empty, FDS just uses the last filename, otherwise uses what the heartbeat file gives.

[RIO4FDS]

Jason,

Added your changes to my procedure here.
FDS was not deleting the EXTERNAL_HEARTBEAT_FILENAME.
In order to get everything working I needed to change line 599 of func.f90 from:

OPEN(LU_EXTERNAL_HEARTBEAT,STATUS='OLD',ERR=100)
to:
OPEN(LU_EXTERNAL_HEARTBEAT,FILE=EXTERNAL_HEARTBEAT_FILENAME,STATUS='OLD',ERR=100)

Also, from your message, I think you want from line 600:
READ(UNIT=LU_EXTERNAL,END=300,ERR=300,FMT=) TEST_FILENAME
to be like this:
READ(UNIT=LU_EXTERNAL_HEARTBEAT,END=300,ERR=300,FMT=) TEST_FILENAME

Let me know if you agree and I can send a pull request.

Regards,
Julio

[drjfloyd]

That looks correct. Thanks.