# Mass Fraction F_YI yields weird results

 Register Blogs Members List Search Today's Posts Mark Forums Read

 May 4, 2018, 09:41 Mass Fraction F_YI yields weird results #1 New Member   Join Date: May 2018 Posts: 29 Rep Power: 7 Hello everyone, I'm currently developing an ON_DEMAND UDF for post-processing, well, on demand. My mesh is 2-dimensional and pretty simple as of now. So now my problem: I loop over the faces of a specific wall (boundary to fluid) and get my adjacent cells via F_C0. After that I loop over all faces (should be 4, squared mesh). Within this loop I look up the mass fraction of my components. Weirdly, one mass fraction is completely wrong. And it is always the mass fraction on face id = 3. Although the contour diagrams show the mass fractions correctly, even at the boundary. To further clarify "how wrong" the resulting mass fractions are, here is one example for one cell: The mass fraction on each face should be roughly the same. Face ID = 1 is the face directly at the wall. The wrong face, ID 3, is the opposite face. ID = 0 w comp_A = 2.315070e-07 ID = 1 w comp_A = 2.432911e-07 ID = 2 w comp_A = 2.441669e-07 ID = 3 w comp_A = 7.257045e-01 Here is roughly the code I'm currently using to "debug" my problem: Code: ```#include "udf.h" DEFINE_ON_DEMAND(myudf) { Domain *d = Get_Domain(1); Thread *t = Lookup_Thread(d, 136); face_t f; cell_t c0; Thread *tf0; int n; face_t fn; Thread *tfn; int i_h2o = SV_SpeciesIndex("h2o"); real xc[ND_ND]; real xcf[ND_ND]; begin_f_loop(f, t) { c0 = F_C0(f, t); tf0 = THREAD_T0(t); C_CENTROID(xc, c0, tf0); c_face_loop(c0, tf0, n) { fn = C_FACE(c0, tf0, n); tfn = C_FACE_THREAD(c0, tf0, n); F_CENTROID(xcf, fn, tfn); printf("\n\tw H2O = %e\tID = %d", F_YI(fn, tf0, i_h2o), n); printf("\nx = %f\ty = %f\tID = %d\n", xcf[0], xcf[1], n); } } end_f_loop(f, t) }``` I appreciate all your help! Thanks! If I need to clarify anything, ask me!

 May 5, 2018, 19:50 #2 Senior Member   Join Date: Sep 2017 Posts: 246 Rep Power: 11 Hi CFDJonas, In the help files, F_YI is said to apply to boundary faces only. As soon as you go looking at interior faces (or indeed symmetry etc -- is this boundary or not?), you are on your own. C_YI is safer (in fluid cells, at least). Good luck! Ed CFDJonas and souza.emer like this.

 May 5, 2018, 20:27 #3 New Member   Join Date: May 2018 Posts: 29 Rep Power: 7 Thank you for your answer! You're right, the help indeed says the macro is meant for boundary faces. But thats kind of unlucky: I want to multiply the mass fraction of the faces with the total mass fluxes through the faces to get the mass flux of one species (through one face). After that I want to add the results of the three faces (in this case) together, to get the net mass flow of the species in this cell. Using the cell mass fraction however does not represent the right fluxes then, does it? Maybe I'm also thinking completely into the wrong direction; so I appreciate all your help, thanks!

 May 6, 2018, 05:46 #4 Senior Member   Join Date: Sep 2017 Posts: 246 Rep Power: 11 As for the question of whether it would be correct to use the cell values of species: well, Fluent has to calculate these fluxes somehow, and it only has cell values to play with. (The reason that F_YI is not available is not that Fluent stores it but does not share it; the reason is that Fluent does not store it. I'm guessing, but this is true in most cases where you want quantity X and it is not available.) If we are defining "correct" to mean "what Fluent does internally", then you have to start guessing how Fluent uses the cell values. It could be upwind, or upwind+diffusion, but it is interesting to read the discussion in the help files for DEFINE_UDS_FLUX. One approach is to use the average of the two cell values bordering each face -- and this has an important benefit that if the fluxes all make sense (perfect continuity), then the species fluxes will too. There might be some corrections to species fluxes when continuity has not yet converged, but we don't know. In general, species behaviour should make more sense if you can converge continuity super-thoroughly. So, yes, unlucky -- you will have to do a lot of the work yourself. I can't see any way round this. If you use User-Defined Scalars (UDSs) rather than species, you can take control of what is going on via DEFINE_UDS_FLUX, but then you might miss out on some clever corrections/stabilisations. (And species have reactions, of course.) If you are interested only in boundary cells, then more information is stored on the boundary faces. Good luck! Ed CFDJonas likes this.

 May 6, 2018, 07:00 #5 New Member   Join Date: May 2018 Posts: 29 Rep Power: 7 Again, thank you for your thorough answer! That somehow makes sense to me. But the UDS example also just shows the total mass flux, not species wise. And I'm not able to/should not change the species/reaction from my model. So I have another UDF running, a DEFINE_PROFILE macro. That one sets the mass fraction of a species on a wall. And of course (by diffusion) this "generated" mass gets into the interior. But when I look onto the boundary/wall, the mass flux is zero. But thats exactly the quantity I want to determine with this ON DEMAND UDF: the (diffusive) mass flux from that wall of a species. It may also be important to note that the mass fractions of this component are rather low. What do you think about that?

 May 6, 2018, 14:55 #6 Senior Member   Join Date: Sep 2017 Posts: 246 Rep Power: 11 Small mass fractions should not be a problem. Some people would change to double-precision Fluent: it might not help, but it really can't hurt here. (You'll have to recompile your UDFs.) So far, I've been discussing convective transfer. So the situation at the wall makes sense: zero mass flux of fluid; zero convective transport of species. I realise now that this may not have been useful. For diffusion, you probably want to look at C_YI_G(c,tc,i) (or C_YI_RG) -- the vector of species-i gradient. I don't know whether the variable called SV_SPECIES_FLUX includes diffusion or not. If it does, then the boundary faces might have come to your rescue. To use it, you need to check whether it is a flux, with units [kg/(m2.s)], or a transfer rate, with units [kg/s], or one of those two but somehow using mass fractions. A comment in storage.h says that this contains boundary fluxes, so I would expect that you can access its values using something like "specflux = F_STORAGE_R_XV(f,tf,i);" for species i and boundary face/face-thread f/tf. CFDJonas likes this.

 May 9, 2018, 05:49 #7 New Member   Join Date: May 2018 Posts: 29 Rep Power: 7 Thank you very much! The SV_SPECIES_FLUX in combination with F_STORAGE_R_XV seems to work like a charm.

 May 9, 2018, 09:34 #8 Senior Member   Join Date: Sep 2017 Posts: 246 Rep Power: 11 Great! For posterity, please can you tell us what you found about SV_SPECIES_FLUX? Is it a total flowrate in [kg/s]? Positive=into model, negative=leaving? Have you tried it for boundary faces other than walls? Have you tried it with turbulent wall functions (low y+ or high y+)? Any quirks to warn us about?

 May 9, 2018, 10:22 #9 New Member   Join Date: May 2018 Posts: 29 Rep Power: 7 I'm currently validating my results. But the status as of now is: It's a mass flow (kg/s); At least in my model I divided by the area of the face and got values in the order of the wanted magnitude of flux (kg/m^2s). But I may add additional information to this post when I validated everything. I only got fluxes into the interior, and all my fluxes are positive. So I don't know if the sign will change if the flux turns around. But I may see this, when I transfer the UDF to the more complex geometry. I'm not using any turbulent model, so I can't tell you anything about that. obscureed likes this.