Hi!

I've moved ground.f, main.f and q1 from one machine running PHOENICS 3.2 (where everything works fine) to another running PHOENICS 3.5. I've adjusted the non-user section at the top of ground.f and changed NFDIM in main.f. Compiling and linking to produce earexe works fine as well as running satexe to read in the grid, the q1 and produce the eardat file. When executing earexe the run starts, but fails as soon as the integration of the equations begins with following error (clipped from the tail end of the file result):

--- INTEGRATION OF EQUATIONS BEGINS ---

stop because F(1) over-written in aftgrx location= 19 indvar = 13 izstep = 1 isweep = 1 istep = 1 ithyd = 1

error stop

Any ideas anyone? //Olof

Just two things, Firstly did you cut and paste your old code into a newer V3.5 ground.f If not it may be worth carefully checking the top of ground to see if anything has changed, such as the common blocks. Also use the newer V3.5 main.f, otherwise you will have to compare the two carefully for any changes.

Then I would binary chop with write statements, to see which line in ground.f, (assuming this is the faulty file), causes the overwrite.

What it is likely to be is that you have zero storage for one of your variables, therefore the L0F location is zero and hence any F(L0F+icell) statement is likely to be overwriting the start of the F-Array.

You mention ground.f and not ground.for, if you are using UNIX, it is possible that you are losing your L0F location between calls to ground. If this is the case make sure you are saveing the variable with a SAVE statement after the variable declarations.

Good luck, shouldn't be too difficult to track down.

Hi, Mick!

We've stripped ground down to bare essentials, and then did the same with the q1-file. Everything worked until I introduced the buoyancy term in the k-eps model:

PATCH(KEBUOY,PHASEM,1,NX,1,NY,1,NZ,1,LSTEP) COVAL(KEBUOY,KE,GRND4,GRND4) COVAL(KEBUOY,EP,GRND4,GRND4)

Adding these lines in q1 produces the error I reported. This works in 3.2 but not in 3.5. Unfortunately I do not have a web browser on the Linux server where 3.5 is installed and I can't find POLIS on the CHAM web site anymore. Any ideas?

//Olof

Hi again!

I've tried mostly everything, stripping away lines in q1 and user-coding in ground.f, but the only change that works is removing the buoyancy source for EP, i.e. removing the line

COVAL(KEBUOY,EP,GRND4,GRND4)

This is all that is required. I'm still using the k-eps model, with buoyancy, wind-induced surface sources, etc. All settings have been used by us for many years in different versions of PHOENICS. Strange, isn't it?

I am running PHOENICS 3.5 on a Linux RedHat server.

//Olof

Olof, How are you? This may be cause of your problem:

DESCRIPTION OF PROBLEM: If KE buoyancy patches are active and EPKE is not stored, then a crash will occur from a F-array overwrite in gxgenk- sub gxkegb. This does not happen if KELIN=3, hence has remained unnoticed to date.

CAUSE OF THE PROBLEM TO BE FILLED IN WHEN KNOWN: In GRP 13 SCT 16 of GXKEBG, the following line will cause the problem.

IF(LBEPKE.EQ.0) F(L0EPKE+IJ) = GEPDK

As EPKE is not stored, writing to F(L0EPKE+IJ) will cause an F-array overwrite. The fix I have forwarded to the customer is to rewrite the line as

IF(LBEPKE.EQ.0)THEN

L0EPKE=L0F(LBEPKE)

F(L0EPKE+IJ)=GEPDK

ENDIF

ACTION: Cause known

PASSED TO DEVELOPMENT ON (date): 15.04.05

STATUS (ie corrected or outstanding): JCL 13.05.05 The analysis of the problem appears to be faulty. If LBEPKE=0, attempting to get an L0F of it will result in an error stop. The line higher up which allocates L0EPKE is protected by (IF(LBEPKE.NE.0). This is what should be used in group 13 as well.

I recommend that the erroneous line be replaced by

IF(LBEPKE.NE.0) F(L0EPKE+IJ) = GEPDK

A modifed GXGENK.HTM is placed in G:\D_36BUGS\EARTH\021\GXHENK.HTM.

Best regards, Mike

I had gotten an F(1) overwritten error when trying to run CHEMKIN runs written for version 3.4 in version 3.6.0 (after adjusting for the different CKlinking files). One way I was able to get them to run was by re-writing the entire model from scratch in the VR-Editor. There may be parsing errors in the VR-Editor's interpreter - maybe the VR-Editor should also keep a binary file that the user can't modify?