Extremely Long CFAST Runs

[Sari-Alkhatib]

I would like to check the opinions on when CFAST runs take extremely long time, i.e., extremely small time steps in the magnitude of 10^(-7) to 10^(-9).

I am encountering such cases in two situations:

• When there is limited ventilation or flow to the compartment and the fire is large, i.e., under-ventilated fires. I observed that with small natural vents defined in the lower portion of the compartment, CFAST would be unable to complete the run (I left it for one whole day and it did not move 1 sec in the simulation). I think this issue is similar to what was discussed here and here.
• When the fire base is above the layer height for long time during the fire time (i.e., very large flame length ratio). I am not sure if the fire location or the flame impingement are the main issues here. I still think it is about the ventilation and oxygen levels in the upper zone (same as the first point above) since if there is good ventilation, these cases would run just fine.

Are there any documentations or stated limitations/guidelines that would help understanding this behavior in CFAST in both cases?

Thanks in advance!

[bewygs]

I'm also experiencing the same issue where CFAST runs take extremely long times with very small time steps for under-ventilated cases (example: a simulation that run for a entire month and never end slow.txt)

Currently, it seems there is no available solution to speed up the process other than changing some input values to be outside of under-ventilated cases. 🙁

Previously, I was using version 7.1.2 of CFAST and did not encounter this issue. Perhaps running your specific case with this version might help ?

However, the problem with that old version is that I encountered another error that caused the CFAST simulation to stop for some random inputs values. This issue has since been resolved as of #669 .

I personally tried modifying the source code to manually fix the time step dt, so it does not go below a threshold value. Unfortunately, I encountered the same issue as with CFAST version 7.1.2.

From what I understand, the simulation runs through a while loop until the final time you indicate is reached.

cfast/Source/CFAST/solve.f90

Line 366 in e50b502

do while (idid>=0 .and. t+0.000001_eb<=tstop)

I might be wrong, but inside this while loop, various checks and computation are made. One important check determines which is the value of the next time step to compute inside ddassl subroutine.

cfast/Source/CFAST/numerics.f90

Line 44 in e50b502

subroutine ddassl(res,neq,t,y,yprime,tout,info,rtol,atol,idid,rwork,lrw,iwork,liw,rpar,ipar,jac)

The error I encountered when putting a treshold to the next time step to compute is this one :

cfast/Source/CFAST/numerics.f90

Lines 611 to 613 in e50b502

	! idid = -7, repeated convergence test failures occurred on the last attempted step in ddassl. an
	! inaccurate or ill-conditioned jacobian may be the problem. if you are absolutely certain
	! you want to continue, you should restart the integration.

I don't know if there is a way to bypass this verification while not violating the model output.

I aslo use gprof to see which routine takes the most time to runs and I got this for a long run (that I killed before it finished).

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ts/call  Ts/call  name    
 71.96    210.06   210.06                             hflow_routines_mp_wall_flow_
  5.58    226.34    16.28                             conduction_routines_mp_conductive_flux_
  2.69    234.19     7.85                             __libm_pow_l9
  1.74    239.28     5.09                             conduction_routines_mp_conduction_
  1.50    243.66     4.38                             mflow_routines_mp_mechanical_flow_
  1.14    246.99     3.33                             solve_routines_mp_calculate_residuals_
  0.86    249.50     2.51                             solve_routines_mp_update_data_
  0.84    251.96     2.46                             numerics_routines_mp_dnrm2_
  0.79    254.26     2.30                             fire_routines_mp_do_fire_
  0.74    256.41     2.15                             hflow_routines_mp_flogo_
  0.73    258.54     2.13                             fire_routines_mp_fire_
  0.70    260.59     2.05                             numerics_routines_mp_ddot_
....

[preneke]

I would be interested in seeing the gprof analysis for a number of runs. Ones that run fast and ones your are having problems with. There are several issues to be aware or when you do this. One is the amount of time the code spends calculating any particular specific phenomena is directly impacted by the scenario specified. Your analysis suggests that the case you ran has a lot of doors and windows, and possible leaks. Because CFAST is solving an ODE my expectation is that the ratio of different phenomena called will be related to the case. I would be interested to see my hypothesis proved.

Our experience is that oxygen limiting of the fire is the biggest culprit of slow runs. Combustion is a very locally specific problem and it is difficult for a model using broad generalizations to solve. We are working on this but I don't want to make any promises or implications. At the moment be aware it is a known limitation and we have not given up on dealing with it.

Also, I would suggest that you not try to set the DT. The solver is making the DT that small because it cannot converge to an answer with a larger DT. It increases the DT when it can. There MIGHT be times when the DT can or should be larger than the solver uses but if those situations exist they are going to be for very specific conditions and not a general case.

[Sari-Alkhatib]

I think this is exactly what is going on in some of my runs. I am not concerned with door jet fires, but also, in the context my sensitivity analysis, I can't just reduce the HRR. I decided to isolate these cases and discuss them as "cases that challenges CFAST solver," would that make sense?

If such conditions/configurations (that challenge the solver) are obtained using a real-life case (e.g., based on a precise data collection of a certain compartment), and basically, you have limited freedom on what to modify and adjust in the input structure, would you recommend investigating it further using CFAST? Or a more advanced tool would be needed?

[preneke]

That is perfectly reasonable. My suggest just to be clear and not to push to do it, would be to find the point where it slows down and adjust the HRR there, meaning set a timepoint where you want to start lowering the HRR and set the HRR at what it would be originally then set another point further on that is say 110% of what the actual HRR is. work that way. It could take some time but it might give you a better idea of what the actual hazard might be. Obviously it is your call and just discussing the cases CFAST is struggling with is a completely reasonable thing to do.

[Sari-Alkhatib]

Thanks a lot! I think my problem is now clear.

Just one more question, what "key performance measures" would be recommend to judge this issue? For example, one thing I am doing is to compare the 'expected' HRR I inputted into CFAST vs the 'actual' HRR and evaluate the difference between them (given that I want my fire to be fully developed). Another example, based on our discussion here, I am now extracting the relative relationship between the layer height and 1) the fire base height, and 2) the upper edge of the single natural vent (both of which are random in my study). Would there be any other parameters that can strongly connect the influential and relevant factors in this case?

[preneke]

The only other thing I would add is to look at the oxygen level in the layers, both upper and lower. Otherwise I think you are covering it.

[Sari-Alkhatib]

I guess that makes sense too. Thanks a lot. This was extremely helpful!