GENK prblems  a bug ?????
I was using the GXGENK (unix system version 2.1) in cylindrical coordinate system. I print out the LGEN variable at finish GXSQUR subroutine (inside GXGENK) and compare with GENK variable print out by PIL command in Q1 STORE(GENK). Two things was unexpected: in first term of dissipation function (DU/DX+J*V/R) was calculate only with DU/DX when NX = 1; the GENK variable print out by STORE(GENK) was different of LGEN, print out in the end of GXSQUR, only at boundary. GXKESO use the field of GENL or calculate the turbulent source terms. I think this very unusually and I can't understand this one. In other version, like 3.3, the GXGENK subroutine is different of version 2.1, but I can't see anything to explain this kind of change at boundary. I see change to fix the first term of dissipation. If anyone know something, I will appreciate to explained this one. Thanks.
Ricardo Mazza 
Re: GENK prblems  a bug ?????
V2.1 is so archaic that it is difficult to comment on any of this, but I do recall that in earlier releases of PHOENICS the contents of GEN1 were printed in GENK and vice versa. Here, GEN1 is supposed to be the mean rate of strain and GENK the product of turbulent kinematic viscosity ENUT and GEN1, i.e. the volumetric turbulent generation rate, GENK=ENUT*GEN1. This problem may have been present in V2.1, and it is easy for you to verify if you use STORE(ENUT,GEN1,GENK)in the Q1 and then make a run and then inspect the RESULT file.

Re: GENK prblems  a bug ?????
I know that v 2.1 is very old. Our version has 6 years old, we bought in 1994. But I use this version and is not very easy chance for the knew one. I don't know exactly what happen with the newer version, but in 2.1 version GEN1 is calculate with LGEN and VISUT in GREX3.F subroutine at line 1075. I printed out the field of GEN1, VIST and GENK and check this one. In my first email maybe is not clear what I am trying to do. I want to run one problem that recommended use cylindrical system, but I need use a Cartesian system. The influence of tensor transformation is made by source terms and porosity. To check, I compared the result with a classical cylindrical system. Now I am trying to compare the results with KEEP models and divergence of GENK calculate at boundary (only on boundary) with that presented by LGEN1 is the source of diverge results, I think so. By the way, if I can't to calculate LGEN1 exactly how phoenics polar system do it, my results never will be like the Phoenics one. I can't see in theory nothing changing the GENK or LGEN at boundary. This must be calculate like: GENK = LENG1 = 2*( (DU/DX + V/R)**2 + (DV/DY)**2 + (DW/DZ)**2) + (DU/DY –U/R+ (1/R)*DV/DX)**2 + ( (1/R)*DW/DX + DU/DZ)**2 + (DV/DZ + DW/DY)**2 at all dominion. If you or someone else have more explanation for me, I will appreciate. Thanks.
Ricardo Mazza 
Re: GENK prblems  a bug ?????
I read this and your earlier message several times, but in the end I am sorry to say I had to give up, as I found the description largely incomprehensible and devoid of all clarity.
It seems like you are trying to solve a problem having a cylindrical flow domain on a cartesian background mesh using porosities to carve out the required cylindrical shape. If this wild guess is near the mark, I guess this representation may include the use of partial porosities or it may be restricted to a staircase approximation, but who can tell. Further, you seem to be reporting a discrepancy between two sets of results that should be the same, i.e. the solutions obtained in polar and cartesiancoordinate systems. In particular, you seem to report some differing solutions at a boundary? What boundary? Wall boundary? Internal boundary next to blocked cells? Free boundary? Who knows? I may be wrong, but I don't think your description of the problem, what you have done, what results you are getting, etc is sufficiently clear for anyone to help you. CHAM itself does not support V2.2 and the diagnosis of discrepancies between two sets of solutions for the same problem usually requires diagnostic work that CHAM' support team can only carry out for maintained users. I think you need to provide a much more clear and detailed description of your problem and requirements. Maybe then some member of this discussion group will be able to help. 
Re: GENK prblems  a bug ?????
I will try to explain better my problem and I hope with this information someone can help me. Using polar system with KEEP turbulence model, the GXSQUR gives the production of turbulence energy by shear stress like (when NX=1): GENK = LENG1 = 2*( (DU/DX + V/R)**2 + (DV/DY)**2 + (DW/DZ)**2) + (DU/DY –U/R+ (1/R)*DV/DX)**2 + ( (1/R)*DW/DX + DU/DZ)**2 + (DV/DZ + DW/DY)**2 If I print out the field of LGEN variable at the end of subroutine GXSQUR, I get: IZ 10 7.19E+01 1.07E+04 1.46E+04 1.04E+04 7.64E+03 5.73E+03 4.42E+03 3.50E+03 2.84E+03 2.48E+03 9 5.62E+01 1.01E+04 1.35E+04 9.60E+03 6.97E+03 5.19E+03 3.98E+03 3.15E+03 2.55E+03 2.21E+03 8 4.39E+01 8.39E+03 1.11E+04 7.92E+03 5.67E+03 4.17E+03 3.18E+03 2.50E+03 2.01E+03 1.72E+03 7 3.47E+01 6.38E+03 8.54E+03 6.15E+03 4.36E+03 3.19E+03 2.41E+03 1.89E+03 1.52E+03 1.28E+03 6 2.80E+01 4.52E+03 6.15E+03 4.50E+03 3.17E+03 2.31E+03 1.74E+03 1.36E+03 1.09E+03 9.06E+02 5 2.32E+01 2.98E+03 4.12E+03 3.06E+03 2.15E+03 1.56E+03 1.17E+03 9.12E+02 7.30E+02 6.02E+02 4 1.98E+01 1.78E+03 2.48E+03 1.87E+03 1.31E+03 9.47E+02 7.12E+02 5.54E+02 4.43E+02 3.62E+02 3 1.75E+01 9.00E+02 1.26E+03 9.62E+02 6.74E+02 4.86E+02 3.65E+02 2.84E+02 2.27E+02 1.84E+02 2 1.61E+01 3.25E+02 4.55E+02 3.49E+02 2.44E+02 1.76E+02 1.32E+02 1.03E+02 8.19E+01 6.64E+01 1 1.54E+01 1.45E+02 2.04E+02 1.57E+02 1.10E+02 7.87E+01 5.89E+01 4.57E+01 3.65E+01 2.95E+01 IY 1 2 3 4 5 6 7 8 9 10
But, if I store the GENK variable in q1, I get: IZ 10 1.96E+06 4.59E+05 6.14E+04 4.51E+04 3.55E+04 2.83E+04 2.31E+04 1.93E+04 1.64E+04 1.48E+04 9 5.62E+01 1.01E+04 1.35E+04 9.60E+03 6.97E+03 5.19E+03 3.98E+03 3.15E+03 2.55E+03 2.21E+03 8 4.39E+01 8.39E+03 1.11E+04 7.92E+03 5.67E+03 4.17E+03 3.18E+03 2.50E+03 2.01E+03 1.72E+03 7 3.47E+01 6.38E+03 8.54E+03 6.15E+03 4.36E+03 3.19E+03 2.41E+03 1.89E+03 1.52E+03 1.28E+03 6 2.80E+01 4.52E+03 6.15E+03 4.50E+03 3.17E+03 2.31E+03 1.74E+03 1.36E+03 1.09E+03 9.06E+02 5 2.32E+01 2.98E+03 4.12E+03 3.06E+03 2.15E+03 1.56E+03 1.17E+03 9.12E+02 7.30E+02 6.02E+02 4 1.98E+01 1.78E+03 2.48E+03 1.87E+03 1.31E+03 9.47E+02 7.12E+02 5.54E+02 4.43E+02 3.62E+02 3 1.75E+01 9.00E+02 1.26E+03 9.62E+02 6.74E+02 4.86E+02 3.65E+02 2.84E+02 2.27E+02 1.84E+02 2 1.61E+01 3.25E+02 4.55E+02 3.49E+02 2.44E+02 1.76E+02 1.32E+02 1.03E+02 8.19E+01 6.64E+01 1 1.54E+01 1.45E+02 2.04E+02 1.57E+02 1.10E+02 7.87E+01 5.89E+01 4.57E+01 3.65E+01 2.95E+01 IY 1 2 3 4 5 6 7 8 9 10 Comparing the two fields I see that all values are equal, except for IZ = 10 for all IY. This control volume is the region of wall boundary condiction, which I define in q1 like: PATCH( PH, HWALL1,NX, 1,NY,NZ,NZ,1,1) COVAL(PH,W1,GRND2, 0.0) COVAL(PH,U1,GRND2,GRND) At GROUND I define a function that calculates the U1 velocity at this wall. This is the problem. At wall boundary condition the LGEN values calculated by GXSQUR are different from GENK. I was expecting the same values for all control volume. Initially, I think that the LGEN that I printed out at end of GXSQUR was wrong. To check for this, I calculated with velocity field the LGEN value using Excel program and LGEN definition above. To evaluate the differential I used second order central difference, except for the system boundary where I used a first order upwind or downwind. All the values that I got with this procedure were the same calculate for LGEN by GXSQUR subroutine. After this check I think that the GENK field is not the same used to calculate the turbulence sources. To check, I found the location in the GXTURB subroutine where the turbulence source was calculated and I printed out the LGEN field. I got the same values presented by GENK variable, instead of LGEN values calculated by GXSQUR. I think this is very strange and I can't understand why the values at wall boundary for GENK and LGEN are different and I can't find where the change is made. For this reason I wrote the first message. I hope with this explanation you (Mike Malain) or someone else would understand my problem. Tanks again. RM 
All times are GMT 4. The time now is 00:03. 