[DaRumpel]

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 fluid-solid-interface. 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 User-Fortran coding. A hint in the right direction or even more an example would be very useful.

Thanks in advance,

Rumpel

[ghorrocks]

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.

[Josh]

To elaborate on Glenn's first point, define several probe points (create expressions) in Pre using the following syntax:

probe(<var|Expression>)@<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.

[DaRumpel]

Originally Posted by Josh

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)

I was already thinking about using probe points. However, the problem is that I'm talking of ten- or hundredthousands of line-integrations. 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...

[ghorrocks]

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.

[stumpy]

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.

[DaRumpel]

Originally Posted by ghorrocks

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.

Maybe I didn't describe my problem clear enough. In my 3D model, I have a 2D fluid-solid interface (fsi), consisting of some 10000 mesh points. On one side of this interface is - of course - a fluid domain. Now for every single fsi-point, I need to integrate over a line which starts at that point, perpendicular to the fsi-surface, across the fluid domain. I know the direction for every fsi-point 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.

[stumpy]

OK, that clarifies things. No, I can't see any way to do that easily.

[ghorrocks]

I think you would have to do this in fortran.

[DaRumpel]

Originally Posted by ghorrocks

I think you would have to do this in fortran.

I've done other things with Fortran in CFX, yet I don't even have an idea how to do this. Any suggestions?

[stumpy]

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 1-way 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.

[ghorrocks]

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?

[DaRumpel]

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.

[stumpy]

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?

[DaRumpel]

Originally Posted by stumpy

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?

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.

[pavitran]

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. Extracted the co-ordinates of inlet from *.cfx5 file and placed in *.dat file.
2. Then recorded a simple session file in which I create a line with two points with 20 samples on it.
3. Then I used a loop in the session file where I create lines from each node at the inlet( node co-ordinates are read from *.dat file).
4. Finally in the session file I included the function calculator using perl syntax to calculate the lengthIntegral of a variable. And the output is written to a file with the below fields.

Line No LengthInt(Velocity)
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

[DaRumpel]

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 cfx5-file (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 cfx5-mesh-files, although / because I've done that before ...

Regards,

Rumpel