
[Sponsors] 
August 24, 2010, 11:52 
Integration along a line during solution

#1 
New Member
Join Date: Aug 2010
Location: Munich, Germany
Posts: 8
Rep Power: 7 
Hi,
following problem: I need to average a quantity (e.g. temperature) along a line through a given domain during the solution process, as this averaged value has to be used elsewhere during the solution.  I need to do this for every point of a fluidsolidinterface. I know the direction of the line for each of these >10000 points  The averaging has to take place during the solution process and I must be able to access the result during the solution  It must be limited to a given domain Actually, I have no idea how to do this. It is no problem if the solution requires some UserFortran coding. A hint in the right direction or even more an example would be very useful. Thanks in advance, Rumpel 

August 24, 2010, 18:55 

#2 
Super Moderator
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 11,277
Rep Power: 88 
Two options:
1) Put a sting of probe points along your line and average the values. 2) Define a small surface and use the areaAve() function. You cannot define a line as a region to evaluate stuff in the solver so make the surface thin so it is like a line. Both of these options can be done in the solver and used as CEL variables to do whatever you like with. 

August 24, 2010, 19:29 

#3 
Senior Member
Joshua Counsil
Join Date: Jul 2009
Location: Halifax, Nova Scotia, Canada
Posts: 366
Rep Power: 9 
To elaborate on Glenn's first point, define several probe points (create expressions) in Pre using the following syntax:
probe(<varExpression>)@<Location> So, for example, if I wanted to calculate the average temperature along the line (you mentioned you knew the coordinates of the line for each point), you could create several probes with syntax similar to this: probe(temperature)@Point1 where Point1 is the first point on the curve. Define Point1 in terms of Cartesian coordinates (e.g., [0, 0, 0]). Repeat for each point. It's a bit sloppy, but it works. 

August 25, 2010, 04:55 

#4 
New Member
Join Date: Aug 2010
Location: Munich, Germany
Posts: 8
Rep Power: 7 
I was already thinking about using probe points. However, the problem is that I'm talking of ten or hundredthousands of lineintegrations. I cannot create probe points for all of them. That means, I have to move one probe point from one location to another. Which I didn't manage to do by now...


August 25, 2010, 07:25 

#5 
Super Moderator
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 11,277
Rep Power: 88 
That's why I suggested option 2, make a small mesh surface region which is long and thin like a line. Then you don't need zillions of points but can just do a areaAve() or whatever function over the surface.


August 25, 2010, 13:48 

#6 
Senior Member
Join Date: Apr 2009
Posts: 529
Rep Power: 12 
How about using two subdomains that touch each other only along the line. I think you could then define an AV that is equal to 1 along the line and 0 everywhere else using the inside() funciton and a nested if():
if( inside()@Sub1, if( inside()@Sub2, 1, 0), 0) Now you just integrate your variable over one of the subdomains and multiply by the AV. I haven't tried this, so let us know if it works out. 

August 25, 2010, 15:23 

#7 
New Member
Join Date: Aug 2010
Location: Munich, Germany
Posts: 8
Rep Power: 7 
Maybe I didn't describe my problem clear enough. In my 3D model, I have a 2D fluidsolid interface (fsi), consisting of some 10000 mesh points. On one side of this interface is  of course  a fluid domain. Now for every single fsipoint, I need to integrate over a line which starts at that point, perpendicular to the fsisurface, across the fluid domain. I know the direction for every fsipoint and I know the distance I need to integrate. However, I don't see how this could be resolved by defining mesh surface regions or subdomains.


August 25, 2010, 16:19 

#8 
Senior Member
Join Date: Apr 2009
Posts: 529
Rep Power: 12 
OK, that clarifies things. No, I can't see any way to do that easily.


August 25, 2010, 17:52 

#9 
Super Moderator
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 11,277
Rep Power: 88 
I think you would have to do this in fortran.


August 27, 2010, 10:43 

#10 
New Member
Join Date: Aug 2010
Location: Munich, Germany
Posts: 8
Rep Power: 7 

August 27, 2010, 11:16 

#11 
Senior Member
Join Date: Apr 2009
Posts: 529
Rep Power: 12 
I'm no Fortran expert, but I really can't see any way to realistically do this either. Even if you had mesh nodes extruded out perpendicular to the FSI surface, so that you had a line of nodes corresponding to the line you wanted to integrate along, it's not going to help much since CFX is an unstructured code so there's no easy way to "select" those nodes. More generally you need something like a lagrangian particle track, then integrate along the track. Could you introduce fake particles at the FSI surface, make them 1way coupled, then give them a huge mass and velocity so that they don't deviate from the injection direction? That gets you your lines, now you just need to figure out how to integrate along them.


August 28, 2010, 06:46 

#12 
Super Moderator
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 11,277
Rep Power: 88 
Yes, it will be very tricky. You will certainly be an expert on CFX fortran if you get this working.
Why are you trying to do this? What are you trying to model? 

August 30, 2010, 13:47 
Subcooled boiling at low pressures

#13 
New Member
Join Date: Aug 2010
Location: Munich, Germany
Posts: 8
Rep Power: 7 
I'm trying to model subcooled boiling at low pressures (<10 bar) and want to compare different evaporation models. As far as I know, this can not be achieved by simply changing the parameters of the RPI boiling model. To do this, I need to implement some "classic" engineering formulas which rely on values like the average temperature of the fluid in the cooling channel (a narrow rectangular channel). To determine this value, I wanted to average the temperature along a line or integrate it and then divide that value by the length of the line.
It would already help if I knew how to determine the neighbours of one node. From the coordinates and the known direction of the line, I could easily choose the right node. 

August 30, 2010, 15:24 

#14 
Senior Member
Join Date: Apr 2009
Posts: 529
Rep Power: 12 
Can't you just keep each cooling channel as a separate volume, then use volume integrals divided by the volume to get the average temperature?


September 1, 2010, 15:00 

#15 
New Member
Join Date: Aug 2010
Location: Munich, Germany
Posts: 8
Rep Power: 7 
No, the wall heat flux within each channel is strongly inhomogeneous. The dimension of the (more or less) rectangular channel is about 0.2cm x 10cm, 70cm long. So a quite narrow channel. The heat flux to the fluid varies greatly in both directions, parallel and perpendicular to the flow direction.


September 2, 2010, 06:32 
Hi

#16 
Member
Dynampally Pavitran
Join Date: Mar 2010
Location: India
Posts: 73
Rep Power: 7 
I have done an exercise on a simple box domain to extract length integrals over a line drawn from every node from the inlet to the mid of the domain. The steps which i followed are:
1 2.3 2 2.5 . . . . n 2.6 If the above procedure which I followed helps you, Then I can share my script with you. Thanks 

September 2, 2010, 11:17 
An idea for a solution

#17 
New Member
Join Date: Aug 2010
Location: Munich, Germany
Posts: 8
Rep Power: 7 
Pavitran,
I've done similar things in Post, but I didn't manage to do that during the solution process (how to create the line?). Meanwhile I got at least an idea:  Prior to the calculation, I extract the coordinates ("X") of the FSI from the cfx5file (or a bit easier just export them via Post). For each X, I will calculate the contribution to the integral of any node "Y" in the fluid domain before the calculation starts. Finally, I will store a list of all the X in shared memory with associated Y coordinates and their contribution to the integral  During the solution process, the value of each Y will be weighted with its contribution for X and summed up and stored for X. In the next iteration step, this stored value will be used in the calculation. The X values are updated again (the updated values are copied to the "used" values in a junction box routine). This will involve a lot of hacking around with Fortran, but it will hopefully do what I need. The values in X are always one iteration behind the actual calculation, but I hope that won't affect the results too much. No beautiful solution, though. Oh, and it will probably take me ages to implement  I hate messing around with the cfx5meshfiles, although / because I've done that before ... Regards, Rumpel 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
grid dependancy  gueynard a.  Main CFD Forum  19  June 27, 2014 21:22 
OpenFOAM15 installables are incomplete problem with paraFoam  tryingof  OpenFOAM Bugs  17  December 7, 2008 05:41 
Install problem in linux  navaladi  OpenFOAM Installation  11  July 17, 2008 02:24 
errors  Fahad  Main CFD Forum  0  March 23, 2004 14:20 
Wall functions  Abhijit Tilak  Main CFD Forum  6  February 5, 1999 02:16 