Error running input file in CFAST gfortran build #2100
-
I followed the instructions outlined in the wiki to build cfast from the makefile on windows intel 64 using gnu, which was successful with no errors. I used the latest repository for this build (no changes in the source files were made). I created an input file and ran a simulation (see input file below) in Cedit 7.7.4 with no problems. Input file: &HEAD VERSION = 7700, TITLE = 'CFAST Simulation' / !! Material Properties To test if my build works, I copied the .in file into the directory of the build and ran it, I get two types of errors depending on the HRR I specify in the first time step. If I specify zero HRR at time zero I get the following error: ***Error, at t (=r1) and stepsize h (=r2) the initial yprime could not be computed If I set the HRR at say 0.1 at time = 0 I get the following error: Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: I have tried specifying MAX_TIME_STEP = 0.01 on the &misc line but to no avail. Could you please assist me with this? Thank you in advance. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 3 replies
-
I ran your case in the CFAST 7.7.4, both versions of your case and they run fine. There appears to be a problem with you code. Unfortunately it is impossible for me to debug your code via messages. All I can say is that I have never seen that error before. Sorry I can't be of more help. Good luck. |
Beta Was this translation helpful? Give feedback.
-
The |
Beta Was this translation helpful? Give feedback.
-
OK, but that still leaves open the issue of why the job fails when compiled with full optimization. |
Beta Was this translation helpful? Give feedback.
-
Yea, you were right. Thanks.
From: Richard Peacock ***@***.***>
Sent: Friday, March 15, 2024 11:17 AM
To: firemodels/cfast ***@***.***>
Cc: Reneke, Paul A. (Fed) ***@***.***>; Comment ***@***.***>
Subject: Re: [firemodels/cfast] Error running input file in CFAST gfortran build (Discussion #2100)
Paul, you may want to create an issue with this test case to see why it's failing with gnu with optimized options.
-
Reply to this email directly, view it on GitHub<#2100 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADDV4MGY66EYJ64O25QDD5LYYMGGXAVCNFSM6AAAAABEXWFMHCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DQMBTGQ4DG>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
The
IEEE_UNDERFLOW
message probably means that the compiler does not automatically assume that 1e-99, say, can be considered 0. The gnu compiler can be fussy about such things and there is probably a flag to tell it to relax. As for the floating point exception, that might be a divide by zero or a square root of a very small negative number. Could you recompile using thegnu_win_64_db
build target and run the case again. That might provide us with a line number indicating where the problem is.