[heling]

Hi there,

Does anyone know how to use User Locations as locators in the expressions?

I'm running a case (single rotor) where I put two user surfaces at the locations where the experimental surveys were performed (upstream and downstream of the rotor, respectively). Since all the parameters were recorded at those two stations, I want to monitor the convergence behaviour of the essential variables, e.g. pressure ratio and rotor efficiency, exactly at those faces. Unfortunately, the expression fails when the specified location is not a mesh or physics locator.

I was thinking about possible workarounds but haven't found anything with reasonably little implementation effort.

Cheers!

[Gert-Jan]

Why don't you create mesh locators in your geometry and then remesh it?

[AtoHM]

Hi heling,
I tried something similar recently, but I was not able to use the user surfaces in Pre as well.
However, if you are conducting a steady state analysis, whats the point of convergence behaviour monitoring for other values than default? As long as residuals are desireably low at the end, your desired output will not vary much.
If its a transient analysis, you can write trn output and extract values at each position you are interested in (with table). Then, use a session file to extract the table for each timestep of interest and process the data in matlab/excel/... .

[Gert-Jan]

@AtoHM, I disagree. Even in a steady state analysis, there are cases where variables tend to develop for a long time.

Therefore, you should always monitor:
- residuals
- imbalance
- variables in monitoring points

Judging convergence by residuals only is not enough. Always create several monitoring point in the domain where you monitor pressure, velocities, tke, temp etc. You have only achieved good convergence, if these become flat liners.

@heling, having said that, is it worth putting several monitoring points in your domain so you can judge convergence using this information.

[heling]

Thanks for your replies, guys!

@Gert-Jan: I tried this approach in TurboGrid, however, inserting planes or turbo surfaces doesn't help, as they're not exported as a mesh locator. In fact, they are completely ignored and don't appear in CFX-pre even as user locations. Do you know how to do this in TG?

Alternatively, I could shift my inlet and outlet interfaces to the desired position but it will mess up my mesh. Their current position is carefully selected for the best mesh quality at the given resolution.

@AtoHM: Well, the convergence can be very tricky. Even though it's a steady-state case and your main parameters seem to converge, your flow might do some crazy acrobatics somewhere inside of the domain, especially at sharp edges, in the transition/separation areas etc., I want to have an adequate insight into the flow physics in the critical regions. Also, in terms of the comparability with the measurements, it's better if you can see if your desired parameters converge towards the experimental value, and they won't if the monitors are at the domain boundaries which are far away from the experimental survey location

[heling]

Originally Posted by Gert-Jan

@AtoHM, I disagree. Even in a steady state analysis, there are cases where variables tend to develop for a long time.

Therefore, you should always monitor:
- residuals
- imbalance
- variables in monitoring points

Judging convergence by residuals only is not enough. Always create several monitoring point in the domain where you monitor pressure, velocities, tke, temp etc. You have only achieved good convergence, if these become flat liners.

@heling, having said that, is it worth putting several monitoring points in your domain so you can judge convergence using this information.

Exactly! Glad you mentioned that In general, there seems to be too less critical and thorough judgement regarding the convergence of steady-state flows. That's why I'm making the effort to monitor the parameters at the exact position of the experiment, plus in the critical areas as LE and TE, tip gap and some additional points at least at the suction side where a separation is likely to occur.

To better visualise what I want to achieve, I put a pic in the attachment. Do you think points will do that? I can't really output the mass flow for point probes and the quantities need to be mass flow avg. as it was done in the experiment.

[Gert-Jan]

I don't know TG.
If you put several points in the critical area (and far away), you will get a good indication of the progress of the convergence.
Don't forget to monitor energy balance. You'll see it will lag behind.

[heling]

Originally Posted by Gert-Jan

I don't know TG.
I don't see your picture. Sorry.
But if you put several points in the critical area (and far away), you will get a good indication of the progress of the convergence.
Don't forget to monitor energy balance. You'll see it will lag behind.

I uploaded it once again

Sure, we're used to say "heat is lazy"!

Points will work in terms of the convergence, but won't allow the monitoring of the mass and flow averaged quantities of interest. It's a way to go, however, should anyone know how to use the user locations in the expression or how to find a workaround with a subroutine, I would appreciate it to the moon and back That would be the cleanest solution, also very helpful for transient simulations.

[Gert-Jan]

As long as user surfaces won't work, the only option I see is to shift you rotor-stator-interfaces to the location of your user surfaces and remesh it.
This will work definitely since these interfaces can be used in the equations.

[heling]

Originally Posted by Gert-Jan

As long as user surfaces won't work, the only option I see is to shift you rotor-stator-interfaces to the location of your user surfaces and remesh it.
This will work definitely since these interfaces can be used in the equations.

Ok, I'll give it a try. However, as I said before, the position of the interfaces is not random as it is, as other configurations result in high mesh skewness and high deviation of the interface to LE and TE distance alongside the span.

See the pic for the difference in the position of the interfaces and the monitor planes.

[AtoHM]

Of course its better to monitor at the exact location, I agree with both of you. But since I was unable to create the exact type of monitors you are trying to set up (@user surfaces), I'd rely on residuals and check in Post if the results are consistent with my understanding of what happens in the domain.

your flow might do some crazy acrobatics somewhere inside of the domain

haha, I had those as well!

I guess the feature doesnt work because those locations can be anywhere in the mesh and dont coincide with mesh nodes. So the solver would have to go through additional calculations to put out your desired values at those locations.
To resolve this, you must somehow introduce mesh locators you can use or extract those values using Backup-Result-Steps and Tables.

Gert's suggestion, moving the interfaces sounds like a sweet workaround for that. Also I experienced that moving them away from the blade can lead to a better mesh actually. Are you using traditional or atm meshing?

[heling]

Hi AtoHm,

I agree with your rationale. In fact, it would require an additional interpolation from mesh on the monitor planes which CFX is not willing to do

Anyway, I'll move the interfaces and go with that approach. I use atm, and since I can't change the automatically generated topology, 'better mesh quality' is really subject to the region. At some points, it is better indeed (less skewness) but on the other hand, because of the twist of the blade, the mesh distribution at the tip is either too concentrated or too stretched depending on the location (see pics in the attachment).

I know this can be compensated by adding edge split and/or increasing global refinement but this deviates from the idea of having a basic mesh for initial calculations. On the other hand, since it's a preliminary mesh, probably there is not much to worry about the non-uniform mesh distribution.

[AtoHM]

Are you refering to the dense region at pressure side trailing edge and suction side leading edge? These are intended by the atm meshing algorithm and should not be considered bad. I figured they are included to better cover shocks and stall regions.
Actually, this looks like a pretty good mesh to me. Those orthogonality angles must be >30° I guess?

[heling]

I think it's the other way round, isn't it? Pressure side downstream the LE and suction side upstream the TE. Is this really an intended mesh design? I had this thought for a second but then I realised that the shock tends to occur exactly in the opposite areas: somewhere around the 1/3 chord length of the suction side.

[AtoHM]

Ups, I mixed up the flow direction^^ sry.

I checked and couldn't find any notes on whether thats actually intended. Was just my impression. I saw similar meshes used in papers, so I do not think its bad. If you are not sure about its influence on the result, do a convergence study and see how your values @ your locations vary.

[MangoNrFive]

I think the density of the mesh in this region is a result of the torsion of the blade and the periodic boundary. Turbogrid is limited to put all those cells in this region because the other blocks are strongly coupled through periodic boundarys and block connectivity with the rest of the mesh. So you wouldn't get such nice spacings in the inlet- and outlet-regions otherwise. But turbogrid has to use this many cells here because else the cells at the root would get to big, as you can already see they're bigger at the root in this region. So it is a trade-off between those cell-sizes, large at the root and/or small at the tip.