|
[Sponsors] |
July 17, 2012, 06:37 |
CFX error code 24
|
#1 |
New Member
Join Date: Oct 2010
Posts: 29
Rep Power: 16 |
Hi,
I'm studying the coupling between a thermal-hydraulic 1D-code and CFX. I wrote some junction box routines in order to transfer data between the code every time step. The transfer seems to work correctly and the coupling procedes through the time steps, unfortunately I get a "random error": In different runs, without any change in both the junction box program in or the case setup (both CFX and 1D code), I get the following error at different time steps (in a random way...). _______________________________ERROR______________ _______________ ... File E:\Work\Work_CFX\hk2b\JunctionBox_02\InletVelocity _27.txt opened LOCDAT VEL_IN (CRESLT):GOOD LOCDAT VEL_IN (CDTYPE):REAL LOCDAT VEL_IN (ISIZE): 1 LOCDAT VEL_IN (JADRES): 255424 Check before read VEL_IN +--------------------------------------------------------------------+ | An error has occurred in cfx5solve: | | | | The ANSYS CFX solver exited with return code 24. No results file | | has been created. | +--------------------------------------------------------------------+ __________________________________________________ _______________ With some print debugging of the junction box results (that in part can be seen above) I found that the error comes during the READ of a value (written in the "E:\Work\Work_CFX\hk2b\Prova_JunctionBox_02\InletV elocity_27.txt" text file into a previosly defined MEMORY DATA AREA=VEL_IN (which is checked for existence with the LOCDAT function whose result are printed). I don't know what kind of error the "code 24" is and how can this come in a random way (at different and not predictable time steps) Thanks in advance Lorenzo |
|
July 17, 2012, 20:23 |
|
#2 |
Super Moderator
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,872
Rep Power: 144 |
The CFX error numbers are not defined and I don't know why they use them. It is a bit silly really.
Have you checked that you are not read or writing the file while the other package is reading or writing? This could cause random failures. You need a good handshaking technique to avoid this. |
|
July 18, 2012, 04:05 |
|
#3 |
New Member
Join Date: Oct 2010
Posts: 29
Rep Power: 16 |
Actually the file to be written (and read by the CFX) is very short, in this case just a real number. I checked that the other code write the file and close it. I tried to set a little delay before reading the file from CFX, even if this could cause quite a dead time in long transients, but the random error keep coming...
Is it possible that somehow the memory area VEL_IN is corrupted or changed in position by other programs? If this is possible, how can I protect those areas? I cannot immagine other ways that can bring to this random error.... If anything else works, maybe the next step is to go from Windows to Linux.... I write below the part of the fortran routine where the CFX stops (more or less the part of the code that produces the output I posted before) ___________________PART OF JUNCTION BOX ROUTINE_____________________ ... C Read data from file. C ICHANNEL=79 OPEN(ICHANNEL,FILE=INPUT_FILE) C C Send any diagnostic messages via master process. CALL MESAGE('WRITE','File '//INPUT_FILE//' opened') C C Locates the DATA AREA 'VEL_IN' if exists and gives information CALL LOCDAT('VEL_IN',CDTYPE,'SKIP',ISIZE,JADRES,CRESLT) C C Send any diagnostic messages via master process. CALL MESAGE('WRITE','LOCDAT VEL_IN (CRESLT):'//CRESLT) C IF (CRESLT .EQ. 'GOOD') THEN CALL MESAGE('WRITE','LOCDAT VEL_IN (CDTYPE):'//CDTYPE) CALL MESAGE('WRITE','LOCDAT VEL_IN (ISIZE):'//CFROMI(ISIZE)) CALL MESAGE('WRITE','LOCDAT VEL_IN (JADRES):'//CFROMI(JADRES)) ELSE C C Create space for VEL_IN CALL MAKDAT('VEL_IN','REAL','STOP',1,pV, CRESLT) C C Send any diagnostic messages via master process. CALL MESAGE('WRITE','CRESLT (MAKDAT): '//CRESLT) CALL MESAGE('WRITE','Creating Data Areas VEL_IN: OK!') END IF C C Little delay to be sure that file to be read is ready. I=0 DO WHILE (I .LE. 10000) I=I+1 END DO C CALL MESAGE('WRITE','Check before read VEL_IN') C C Read data in VEL_IN (Where probably things goes wrong, checking the output file) READ (ICHANNEL,*) VEL_IN CALL POKER('VEL_IN',1,VEL_IN,'STOP',CRESLT,RZ) C CALL MESAGE('WRITE','CRESLT (POKER): '//CRESLT) CALL MESAGE('WRITE','VEL_IN:'//CFROMR(VEL_IN)) C CLOSE(ICHANNEL) C CALL MESAGE('WRITE','CLOSE: OK!') __________________________________________________ __________________ Thank you very much for your help Lorenzo Last edited by Silmaril; July 18, 2012 at 04:27. |
|
July 18, 2012, 06:19 |
|
#4 |
Senior Member
Join Date: Jul 2011
Location: Berlin, Germany
Posts: 173
Rep Power: 15 |
How is your input file you want to read and save into VEL_IN looking like (first line will be enough).
Why I am asking...as far as I can remember FORTRAN only reads one value at a time. So if you have several values in one line it can cause a problem. Even so if in the first line of the file you have a "Header" Nevertheless your "READ (ICHANNEL,*) VEL_IN" will only read one single value. VEL_IN certainly is a scalar variable (?!?) if not the increments for a vector are missing and the read command will be executed only once.... Meaning you open the file read the first value close the file as far as I can see in your code. |
|
July 18, 2012, 06:39 |
|
#5 |
New Member
Join Date: Oct 2010
Posts: 29
Rep Power: 16 |
Actually the file contain at the first (and only) line, just one single real value
(say 2.097373E+00, that I've copied from the actual file that returns the error). The VEL_IN memory area is defined as a single REAL data (not a vector) as written in the MAKDAT part of the code (that I repeat below) __________________________________________________ _______ ... C Create space for VEL_IN CALL MAKDAT('VEL_IN','REAL','STOP',1,pV, CRESLT) ... __________________________________________________ ________ Also, the strange thing is that if the error was in the definition of the data area or in the value written in the file, the CFX should stop at the first call (first time step, @User Input), and not in some random time step later.... I also checked that the same data that in one run cause the crush, in a different call doesn't cause any problem..... Don't know how to deal with this random error.... Thanks for helping Lorenzo |
|
July 18, 2012, 07:03 |
|
#6 |
Senior Member
Join Date: Jul 2011
Location: Berlin, Germany
Posts: 173
Rep Power: 15 |
Hmm...is the value in the file being changed troughout your calculation run?
Meaning, can it be that at some point there is no or wrong data in the file??? |
|
July 18, 2012, 09:26 |
|
#7 |
New Member
Join Date: Oct 2010
Posts: 29
Rep Power: 16 |
The value is changed every time step, actually a new file is created every time step, where the CFX should read the value to be used as boundary condition. After the CFX error I also checked for existence of the file and its contents, and value seems right: only 1 line, only one REAL value, exponential notation and no strange characters....
|
|
July 18, 2012, 09:58 |
|
#8 |
Senior Member
Join Date: Jul 2011
Location: Berlin, Germany
Posts: 173
Rep Power: 15 |
Strange...
Are we looking at wrong location maybe? Do you print out the VEL_IN variable each time (write (*,*) VEL_IN)? Maybe you can see then what happens before the crash...Maybe there is a point in the simulation were suddenly there isn't a number anymore...??? |
|
July 18, 2012, 10:10 |
|
#9 |
New Member
Join Date: Oct 2010
Posts: 29
Rep Power: 16 |
Will try this too....
I think the problem rises somewhere between the file creation and the read.... I tried to do the same simulations without the external coupling but putting directly the same files (already created and written by me manually) in the working folder. In this way the problem seems to vanish...... |
|
July 18, 2012, 10:48 |
|
#10 |
Senior Member
Join Date: Jul 2011
Location: Berlin, Germany
Posts: 173
Rep Power: 15 |
definitly seems as if there is smth strange happening during the calculation leading to a situation where u suddenly have smth in the file that does not correspond to the expected value anymore...
Could only guess that there might be an error (?) in the routine with which u recalculated VEL_IN before writing it to file. |
|
July 18, 2012, 11:11 |
|
#11 |
New Member
Join Date: Oct 2010
Posts: 29
Rep Power: 16 |
Can be, but why the error happens randomly....?
I don't know what to search that can cause the randomness of the crush. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
CFX Treatment of Laminar and Turbulent Flows | Jade M | CFX | 18 | September 15, 2022 08:08 |
High Resolution (CFX) vs 2nd Order Upwind (Fluent) | gravis | ANSYS | 3 | March 24, 2011 03:43 |
CFX pressure in Simulations problem | nasdak | CFX | 1 | April 14, 2010 14:22 |
PhD using CFX | Rui | CFX | 9 | May 28, 2007 06:59 |
FSI using CFX and ANSYS | Bi Chang | CFX | 2 | May 10, 2005 05:47 |