|
[Sponsors] |
How to add a source term on the nodes of the cells |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
February 18, 2019, 04:36 |
How to add a source term on the nodes of the cells
|
#1 |
New Member
Amina Yaakoubi
Join Date: Feb 2019
Posts: 2
Rep Power: 0 |
Hi,
The aim of the project I am working on is to run a one phase flow simulation by adding a source term which will model the effect of a swarm of bubbles. To do so I need to use the data of the two phase flow simulation containing the volume fraction of the air. I used the Auto Save feature of Fluent to get a data file on each node. To add the source term I used a DEFINE_SOURCE udf. Now I need to read the data file and use it properly in each cell. The problem is that I could only use the CENTROID function to add the source term in the center of the cell but i have no idea in which order Fluent reads the cells (since I have an unstructured mesh) and when I tried to plot the coordinates given by CENTROID at each iteration I got very random values who do not correspond to the order of the data flle that I got from the autosave of the two phase flow. I am really confused and want to find a way to make sure that when I read the 6 th line from the data file (for example) and use it in the formula it would be added in the right cell. Here's the UDF I wrote that is just adding a constant source term for now. Thank's in advance for helping me out. #include "udf.h" #include "mem.h" DEFINE_SOURCE(cell_x_source, cell, thread, dS, eqn) { #if RP_NODE, RP_HOST, PARALLEL real pos[ND_ND]; real source; real x; real y ; C_CENTROID(pos,cell,thread); x=pos[0] ; /* correspond à l'ordonnée */ y=pos[1] ; /* correspond à l'abcisse */ if ((x<=0.13)&&(0.08<=y)&&(y<=0.15)) /* 1ère zone */ {source = 981 ; dS[eqn] = 0 ; } if ((x<=0.25)&&(0.15<=y)&&(y<=2.5)) /* deuxième zone */ {source = 343.35 ; dS[eqn] = 0 ; } else {source = 0 ; dS[eqn] = 0 ; } #endif return source; } |
|
February 18, 2019, 20:28 |
|
#2 |
Senior Member
Join Date: Sep 2017
Posts: 246
Rep Power: 12 |
Hi Amina,
Here are some slightly incoherent thoughts: 1) You need to be clear about whether you are converting the results from one mesh to apply to a different mesh. This is a completely different problem from storing existing results from a mesh (in a file or in memory) and applying to the same mesh. 2) Also, please be clear about about the terms: are you actually dealing with "the nodes of the cells"? (What does that mean?) Or does the saved file provide values at cell centroids? These are significantly different points in space, and they would need completely different numerical approaches. 3) You are correct in finding that a saved file of results is a difficult format for inputting results. The order of the saved values is not guaranteed to correspond to any current order of current values. (As one example, consider saving some results in parallel, then opening with a different number of parallel processes. Even with the same mesh, the cells are handled in different lists on different processes.) 4) To read cell-centroid values from a file and put them into cell values in the same mesh, a crude method would be to consider each new input value: search through every cell and find (presumably) one within some geometric distance much less than a cell dimension. This is a slow method, but possibly acceptable for a 2D case, which it seems you have. 5) An alternative would be to use a UDF to store results in User-Defined Memory, so that each stored value is automatically connected to an individual cell. Then change the model (for example, by GUI) in mid-session. Then use a different UDF to transfer the values into a new model. This sounds to me like an easier solution. Good luck! Ed |
|
February 18, 2019, 20:35 |
|
#3 |
Senior Member
Join Date: Sep 2017
Posts: 246
Rep Power: 12 |
Oh, by the way, there is a fault in your listed code:
Code:
if(... in zone 1...) { source = 111; } if(... in zone 2...) { source = 222; } else { source = 333; } Code:
if(... in zone 1...) { source = 111; }else if(... in zone 2...) { source = 222; }else{ source = 333; } |
|
February 19, 2019, 12:46 |
|
#4 |
New Member
Amina Yaakoubi
Join Date: Feb 2019
Posts: 2
Rep Power: 0 |
Hi,
Thank you for your quick answer . 1) I am actually working on the same geometry and using the same mesh. The aim of this project is to estimate the effect of the bubbles in a two phase flow and model them with a volumic force using an UDF in a one phase flow so I kept the same mesh file. 2) When I use the autosave feature of Fluent I have two choices, wether to export data at the nodes (so I think it would be the left bottom point of the cell) or at the center of the cells. When I exported them at the center of the cells (because it would be more convenient since I am using CENTROID in my UDF to add the source term) I got a very random order of the coordinates. I thought aboout trying to figure out how the DEFINE_SOURCE does its loops in order to organize my data file in the same way as the DEFINE_SOURCE loops but when I exported the coordinates that CENTROID calculates in a text file I got an even more random order with a different number of points (it seems like the CENTROID function doesn't calculate all the coordinates or maybe it's a problem with the exported file). However, when I tried exporting at the nodes, the data was quite organized (it goes in horizental lines from left to right) so I thought maybe if I find a function like CENTROID but which calculates the nodes of the cells it would also be a bit more organized than the CENTROID one (it's still just an assumption), and even if it's not not having at least the data clearly organised can make it easier for me to adapt the calculation in the UDF (maybe by searching the coordinates and then adding the source term at the right place). 3) I am using the same parallel processes and the same computer so I hope it I won't have to worry much about it . 4) Yes I thought about doing that. 5) I don't really get the point of changing the model mid session. Why should I do that ? And yes I think it would be great if there's a way to call cells by their ID's it would make it a lot easier for me but I need to search a bit more to find how to do that in a DEFINE_SOURCE type of udf (it's a bit complicated for me since this UDF does the loops on it's own so I don't know if I can really control it), (it's my first time working with udf's so if you have a suggestion I would really appreciate it). And thank you so much for pointing out the error I made in my UDF it completely changed the results (it was a simplified model to test if the method of adding a source in a one phase flow can give acceptable results and they weren't until I added the else before the if ) |
|
February 19, 2019, 19:25 |
|
#5 |
Senior Member
Join Date: Sep 2017
Posts: 246
Rep Power: 12 |
Hi Amina,
You really should abandon all hope that the order of a saved file will correspond to your model in any convenient way. This is true even if the file originated from the same model. You assume that a node-based output will give the cell values, but labelled by the coordinates of the bottom-left node. This is a major unjustified assumption, and I would guess differently. So we agree that this needs testing. (We might well ask why the documentation does not tell us exactly what to expect.) I really recommend option (5): store values in User-Defined Memory, then change the model, then use the values to influence the new model. The benefit of this is that the information from each cell is stored at that cell, and can be accessed at the relevant cell. Good luck! Ed |
|
Tags |
coordinates, coordinates from .txt, fluent, udf code |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Trouble compiling utilities using source-built OpenFOAM | Artur | OpenFOAM Programming & Development | 14 | October 29, 2013 11:59 |
"parabolicVelocity" in OpenFoam 2.1.0 ? | sawyer86 | OpenFOAM Running, Solving & CFD | 21 | February 7, 2012 12:44 |
OpenFOAM on MinGW crosscompiler hosted on Linux | allenzhao | OpenFOAM Installation | 127 | January 30, 2009 20:08 |
DxFoam reader update | hjasak | OpenFOAM Post-Processing | 69 | April 24, 2008 02:24 |
DecomposePar links against liblamso0 with OpenMPI | jens_klostermann | OpenFOAM Bugs | 11 | June 28, 2007 18:51 |