Mesh UDF problem
I have strange problem with results of my UDF.
As you can see, my UDF loops over a cell fluid cell thread and inside every cell does a loop over all faces. In the face loop it takes values from the adjacent cells (dudux1, ...) and performs simple operations (SRT1, Sface, multiplication by flux/density - still inside the face loop). The result of the face loop is tensor DS. As of now, I have 2 problems:
1) As you can see in thumbnail DS-Partition there is a slice which has reversed sign. The contours have right shape, but opposite colours. I wondered whether it may be caused be a partition crossing periodic boundary condition (Partition1) so i repartitioned the mesh (Partition2) and repeat calculations. It turned out to be a dead end, since DS for Partition2 looks almost exactly the same.
My next idea was as follows: As I understand it, it isn't precisely defined which cell is C0 and which one is C1 (adjacent cell). Thus the flux between them can be taken with opposite sign. So I just fabs-ed the flux. Resulting distribution is shown in DS-fabsflux. It looks nice and smooth, but what are the chances that it is correct? Does anyone know reliable solution to a problem like this?
2) There is clear problem with my periodic boundary condition. It seems that the value is set to 0 there. Since my UDF is to set the value to zero on all wall faces, I thought that Fluent treats pbc as a wall and tried to include appropriate condition in the if sentence, based on the ID value of the pbc. But it failed horribly. Can somebody push me in the right direction as how to deal with this?
Also, in the DS for both Partition1 and Partition2 there are horizontal lines of 0 value at the level of the rib. They seem to vanish in the DS-fabsflux. May this all situation be connected somehow with the way how the model is meshed? (Thumbnail: Mesh). For the record, according to fluent:
- Minimum Orthogonal Quality = 9.99873e-01
- Maximum Aspect Ratio = 3.52643e+01
In my opinion you should calculate the inner product of the strain-rate tensor (Sface) and the flux vector, i.e., F_FLUX()*F_AREA(), rather than a scalar F_FLUX times the tensor Sface. For the record, C0 and C1 are well defined and can be unambiguously distinguished.
I do not quite understand your second question, but F_R and C_R are the same thing. So if the storage is not allocated you should receive the segmentation fault error or things alike.
Thank you for the answer, blackmask.
What you mean is something like this:
First assign flux_vector - vector F_FLUX()*F_AREA() and then
Good to know that C0 and C1 are well defined. I misunderstood some other thread when I was searching for the similiar topic. Thanks for clreaing it up.
As for the second question: I copied the part with C_R and F_R from UDF manual, 2.7.3. DEFINE_UDS_FLUX example. As I understand, it is supposed to check whether density is defined on the face and read this face density (F_R) or density from cell centre (C_R) if otherwise.
As for the periodic boundary condition stuff. If you look at the DS-fabsflux thumbnail, strange (unphysical) drop of DS values appears at the very periodic bc, that is on the left, right and middle vertical lines (I didn't state it explicitly, but the pictures are /Views/Define Periodic Repeats twice, so oly half is computed actually). However, when I inspect present results I don't see this drop anymore. I don't really know why it behaves like this (I don't recall any changes that I have done), but it seems like the question is gone. Hope this makes some sense now.
Sorry, You are right on the second question. While "F_R" and "C_R" are identical, I did not notice that "f" and "tf" in
DS[ii][jj][kk] = Sface[ii][jj]*flux_vector[kk]
Anyway, you must be better than me in this topic and you have a good explanation for the DS you calculated.
Of course, you're right, my tensor-vector multiplication was a total brainfart.
What I'm trying to do is calculate the substantial derivative of the strain rate tensor. Menter-Smirnov article on which I base my attempts explicitly states following formula for it:
DS/Dt =(SumOverFaces( StrainRateTensor@face * VelocityNormal@face * face_area))/volume
I'm trying to compute the Vel_normal as flux-through-face/(face_area*density), as also stated in the source article, but this simple implementation leads to the different sign of the DS in some region, as pictured in my first post.
During the conversation with my supervisor we came to the conclusion that it is most probably just the sign of the flux, and if it can be assigned properly, results are going to be fine. So for now I'm going to focus on this. Thank you for all your help, blackmask.
|All times are GMT -4. The time now is 10:14.|