[jyothishkumar]

Hi antonio

Thanks for your help. (Please do not mistake me for my previous post as i was very curious to see the p and u and the control dict file thats it) I could manage to run the Axial_Rotor_MRF without any divergence. This i have done by adjusting the exit pressure (by lowering its value).

Now I am moving to my actual problem and is a centrifugal compressor.

I have attached a pdf (just single page), please have a look in to it. I have mentioned about the interfaces in the presentation. I just want to confirm the following things

There are totally six interfaces (3 for stationary and 3 for rotating) and are as follows

entrance interface - one for the rotor (rotating one) and one for the shroud part (stationary one) - 2 interfaces

Middle interface - one for the rotor part (rotating one) and another for the shroud part (stationary one) -2 interfaces

Rotor with exit interface (volute-rotor interface) - one for the rotor part (rotating one) and another for the volute part (stationary one ) - 2 interfaces. So there are 6 interfaces (3 rotating and 3 stationary)

In the MRFZones file I am mentioning like as follows

rotatingpatch (rotating_wall (means the rotor - rotating wall) and the three rotating interfaces)

nonrotatingpatch (I am prescribing all except the patches in rotating patch (mentioned above) here it includes the other three interfaces also (stationary one)

I am going to give mass flow inlet and pressure outlet boundary condition.

Is there anything that you want to suggest me.

Thanks

Jyothish

[antoniofct]

Hi,

I am not sure if I understood your question.

About your pdf, regarding the CFD of the problem you have one inlet ( entering the rotor ), two outlets ( one exiting the shroud at the middle of the blade and another at the end of the blade going to the volute ) you have two physical walls ( the hub itself that is of course the outside of the shaft and the shroud ). Here you have 5 patches ( boundary conditions ) plus the extra one you call Main Entry.

Regarding interfaces, and I mean the ability to compute with differente mesh sizes (implementing the volute and maybe a tube connecting the outlet in the middle of the shroud to the inlet of the rotor) I just see 3 interfaces ( one for the end_of_blade--->volute, one for shroud_middle_outlet-->tube, one for tube-->inlet_rotor)

I am not sure how you will implement this but how will you physically feed the rotor with the incoming air from the shroud? Because if you are not going to do that physically ( meshing that tube) you just have one interface that is what connects to the volute). Anyway it is almost certain that if you want to do this all in one computation you will need GGI interfaces.

About the MRFZones, just think phisically: what is moving? the hub and blade with omega velocity. All the other should be at rest ( meaning all of them shoud be specified in the non rotating patchs).

I think that's all and a sugestion would be to calculate first what goes out of the blade and put it as a inlet condition for the volute.

Oh, oh course, you will have another outlet from the volute

Antonio

[jyothishkumar]

Hi Antonio,

Thanks.

Sorry that I missed out one important word, Its a ported shroud compressor. Now please see the attachment things will be very clear. Also my doubt was
that anyway we will give rotating wall as rotating patch but the interface associated with these things. For eg. consider the volute and wheel alone.

There will be 2 surfaces where volute and the wheel joins which belongs to interface boundary condition. Out of 2 surfaces one belongs to the rotor (wheel) and the other belongs to volute. Now in my rotating patch whether i have to give like the rotating wheel + the rotor interface side with volute and in the nonrotating patch I have to give like the volute --> volute wall etc + the volute interface side with the rotor

Is this right ?.

Thanks

Jyothish

[antoniofct]

Hi,

I am sorry, I explained wrong.

Concerning the connection between volute and wheel you will have two boundary conditions, they will be of type ggi or mixing plane ( whatever it suits you better )( I think it is what you have said).

Regarding those boundaries in the MRFZones, the interface that belongs to the wheel is non-rotating and the interface from the volute is non rotating. So If you agree with this I think you are correct!

I had some questions about the interface of the wheel, but in steadystate calculations the mesh isn't really spinning. The zones you define in MRFZones are just given coriolis and centrifugal forces ( you can check this in the code) so in fact you only need the two interface if the outlet-of-wheel mesh is diferent from the inlet-volute mesh.

Feel free to point some mistake

Antonio

[jyothishkumar]

Hi,

Just on the fourth line of your reply (regarding boundaries in the MRF ZONES). Please confirm whether the interface belongs to the wheel is non-rotating (what you have mentioned ) or rotating. The other one I accepts as the interface from the volute is non rotating.

Regarding your question

Let us take a steady case situation

Rotor is the only rotating domain.

Rotor and volute
---------------------
Interface with volute will be rotating (as we discussed) (two interfaces one belongs to rotor side (rotating) and other belongs to volute side (stationary))

Rotor and ported shroud
------------------------------
In my case since it is a ported shroud compressor, rotor interface with shroud cavity will rotate.
Shroud cavity interface with rotor will be a stationary one.

Rotor and entrance interface (I have mentioned in the previous pdf files that i have sent)
----------------------------------
Third one is the interface between the rotor and the flow coming from the inlet

So as a whole we have 3 stationary interfaces (belongs to volute, ported shroud cavity and entrance to the rotor) and 3 rotating interfaces (all belongs to the rotor --> rotor side interface with volute, rotor side interface with ported shroud cavity and the rotor side interface with entrance from the inlet flow

Is this detail answer your question. Please tell me if you feel something is wrong.

Also can you please check the attachment for (U, P, T and MRFZones file)

My boundary condition is mass flow inlet and exit pressure. My actual rotation speed is 64000 rpm but i am starting with low omega values. Even my exit pressure value is around 140000 pa but i am trying initially with low values.

During the iteration the solver is showing the inlet mass flow as different value (actual value is 0.27kg/s but it is showing 0.8 kg/s etc.). Temperature at the inlet also it is showing very low value. Same problem with density also (obviously because of temperature). Please tell me where I am doing the mistake.

Thanks

Jyothish

[antoniofct]

Hi,

Originally Posted by jyothishkumar

Rotor and volute
---------------------
Interface with volute will be rotating (as we discussed) (two interfaces one belongs to rotor side (rotating) and other belongs to volute side (stationary))

If you are really going to simulate with the volute you will need a mixing plane in that interface. Both patches of the mixing plane will be non-rotating. In fact it is irrelevant if it is rotating or not, that only matters if you want to specify a Vteta in the patch which normaly it isn't done.

Originally Posted by jyothishkumar

Rotor and ported shroud
------------------------------
In my case since it is a ported shroud compressor, rotor interface with shroud cavity will rotate.
Shroud cavity interface with rotor will be a stationary one.

Do you have a stator in your ported shroud? If you have you will need to use a mixing plane as it is for the volute. If not, it is just an outlet.

Originally Posted by jyothishkumar

Rotor and entrance interface (I have mentioned in the previous pdf files that i have sent)
----------------------------------
Third one is the interface between the rotor and the flow coming from the inlet

I don't understand what you mean, for me it is just an inlet.

Originally Posted by jyothishkumar

Also can you please check the attachment for (U, P, T and MRFZones file)

My boundary condition is mass flow inlet and exit pressure. My actual rotation speed is 64000 rpm but i am starting with low omega values. Even my exit pressure value is around 140000 pa but i am trying initially with low values.

I hadn't the time to look closer the files but you should not start with massflow. The temperatureDirectedInletVelocity is better. First try simple than go complex.

Your internal field in pressure is too low (15000 pa?).

By the way, how many cells does your mesh have? Have you managed to converge with the volute alone? or with the ported shroud alone?

Antonio

[jyothishkumar]

Hi antonio,

My mesh size is around 0.7 million to 1.0 million only.

Regarding the boundary condition, it is really confusing me a little. Right now i have a mass flow inlet value and exit static pressure. (also just for an information i have already run the same case in starccm+)

You advised me not to start with mass flow condition in openfoam. Can you please little more clear about which boundary condition i should go with in the open foam.

Can you please tell me little bit about the temperature directed inlet velocity.

Thanks

Jyothish

[antoniofct]

Hi,

TemperatureDirectedInletVelocity allows you to specify a fixed Vteta (the omega entry), for me it is the great thing about this boundary.That and the ability to change between coordinates system makes it very helpfull (cylindrical or cartesian). Then it makes a correction based on the total temperature so that the velocity at the boundary is always good. This is what I understand of it.

You should go with this boundary condition at inlet.

Use isentropicTotalTemperature at inlet and just a fixed value (static pressure) at outlet.

With this, if your mesh is good it must converge.

Make sure you are doing OK the mixing planes.

Make sure your first cell at the wall and at the blade are compatible with your modeling of turbulence ( with or without wall functions).As an example, the test case use wall functions and a first cell with 10^-4 m . If your values are like this you should be OK, If not calculate your Y+ and you either refine your mesh or you don't use wall functions)

sorry for the delay in replying!

Antonio

[jyothishkumar]

Hi,

Thanks for your reply.

In applying temperature directed inlet velocity i have some query

In my case I know my mass flow rate at the inlet and the static pressure at the exit and the rotational speed of the wheel (around 64000 rpm). Even in starccm+ initially it was very difficult to converge. So I did ramping of CFL no, rotational rpm and the exit pressure.

For eg. the exit static pressure i started with 26000 pa and linearly ramped this value to reach the final value (156000 pa) in first 500 iterations and after 500 iterations this value remains there.

Similarly for the rpm and cfl no. In 500 iterations the value of N and cfl gradually reaches the final value. This is to reduce the initial instability which arises in the flow due to some numerical errors.

As you said the pressure outlet boundary condition that is fine.

1 For temperature directed inlet velocity, after the omega (0 0 0) what is the velocity that i should prescribe. Whether it is the Compressor inlet velocity (x,y,z) or the rotational speed (U --> Pi * D * N /60) alone. Because there should be some relation between my mass flow rate and the velocity at the inlet.

2. Similarly here also i would like to start with lower exit pressure value and rpm value

(I am trying with laminar flow only now (after getting convergence i can switch on the turbulent))

If you have any suggestions please tell me.

thanks

Jyothish

[antoniofct]

Hi,

So you have succeed in converging in Starccm+.

You can take the values of total pressure and total temperature from your converged solution and put it in the respective files in the 0 folder(inlet) of your OpenFOAM case.

About your initial fields, you could use the funkySetFields utiliy to start a better velocity field, pressure, temperature. From my experience is better than nothing but it won't speed up the convergence that much. I think you might get rid of bounded variables with this.The utility allows you to apply an internal field based on expressions like a linear distribution of pressure along radius or whatever you want.

About your velocity, the value uniform (? ? ?) entry that is in the temperatureDirectedInletVelocity patch is just an initial velocity vector, not like omega entry that is fixed.

So in your starccm+ simulation you should be able to see the vector at inlet. It is better if you know it but it isn't that important because it will change. It is important to know omega or Vteta (and it is why it is fixed) because it is a characteristic of the solution. Omega being set to zero means you only have axial velocity..but this you should probably know already.

I managed to converge with no scaling of Co number nor pressure. The solver is quite robust. You must take in account that it is slow..like a 1 million cells will normally take more than 3 days to converge in a 8 processor machine.

I don't think it is a good idea to simulate without turbulence models.It might work but you can have detached flows and I just don't know how can it behave because turbulence models can help converge.

Antonio

[jyothishkumar]

Hi antonio,

When I run these cases either my temperature remains low at the inlet (around 130 K) or very high around 3000 K in the domain). Second thing is the density, It always remains same (varys from 0.24 to 1.24). I think it is enough to specify air in the thermophysical properties file and no need to specify density value ? So again I got some doubt in the boundary condition. Please read the following explanation.

Please note in starccm+ I am giving the mass flow inlet boundary condition and exit pressure boundary condition

Also temperature (293K) is specified at the inlet thats it.


From the starccm+ results I have the following values (also includes the bc prescribed)

Velocity inlet (0 0 30.0) (and no rotational component and purely axial) (from starccm solution)

Total pressure at the inlet (~ 104000 pa) (from starccm solution)

Total temperature at the inlet 293 K (already given in starccm+ at the inlet)

Temperature at the exit (343 K) (from the starrcm solution)

Pressure outlet - 156000 pa (already given in starccm+ as bc)

rpm - 64000 rpm (6072.06 rad/s)

Now in OpenFOAM i am giving the temperature directed inlet velocity in the velocity file

U -file
--------
It is as follows

internal field (0 0 30.2);

type temperatureDirectedInletVelocity;
inletDirection uniform (0 0 1); // Direction of absolute velocity in cartesian coordinates
phi phi; // just needed in compressible case to check dimensions
T T; // name of the static temperature field
T0 uniform 293.0; // value of the total temperature
cylindricalCS no; // specifies if inletDirection is in cartesian or cylindrical coordinates
omega (0 0 0); // angular velocity
value uniform (0 0 30.2); // Initial Value


P -file
--------

I am giving total pressure at the inlet (using the type totalPressure) as follows

type totalPressure;
p0 uniform 104924.5;
value uniform 104924.5;
U U;
phi phi;
gamma 1.4;
rho none;
psi psi;

Also I am giving the exit pressure value (156000)

Here I have the following question

i. If I give this total pressure, exit pressure and temperature directed inlet velocity whether the problem will become over specified ? Or is .it ok

ii. The exit pressure 156000 pa, do i need to start from lower value (like from 40000 pa then 60000 pa etc )

In specifying the rotation (omega - 6072.06 rad/s) in MRF ZONES file whether i should start from lower value (like 500 rad/s, 1500 then 2500 rad/s etc) ?.

T - file
----------------------
inlet

type isentropicTotalTemperature;
p p; // name of static pressure field
T0 uniform 293.0; // absolute total temperature field
p0 uniform 104924.5 ; // absolute total presure field
value uniform 293.0; // initial value


Please tell me your valuable suggestion

thanks

Jyothish

Originally Posted by antoniofct

Hi,

So you have succeed in converging in Starccm+.

You can take the values of total pressure and total temperature from your converged solution and put it in the respective files in the 0 folder(inlet) of your OpenFOAM case.

About your initial fields, you could use the funkySetFields utiliy to start a better velocity field, pressure, temperature. From my experience is better than nothing but it won't speed up the convergence that much. I think you might get rid of bounded variables with this.The utility allows you to apply an internal field based on expressions like a linear distribution of pressure along radius or whatever you want.

About your velocity, the value uniform (? ? ?) entry that is in the temperatureDirectedInletVelocity patch is just an initial velocity vector, not like omega entry that is fixed.

So in your starccm+ simulation you should be able to see the vector at inlet. It is better if you know it but it isn't that important because it will change. It is important to know omega or Vteta (and it is why it is fixed) because it is a characteristic of the solution. Omega being set to zero means you only have axial velocity..but this you should probably know already.

I managed to converge with no scaling of Co number nor pressure. The solver is quite robust. You must take in account that it is slow..like a 1 million cells will normally take more than 3 days to converge in a 8 processor machine.

I don't think it is a good idea to simulate without turbulence models.It might work but you can have detached flows and I just don't know how can it behave because turbulence models can help converge.

Antonio

[antoniofct]

Hi,

I have already told you this before but maybe you missed that point: when defining totalpressure or isentropicTotalTemperature you are giving the p0 and T0 correctly but the "value" entry is wrong because that is referred to static quantities. So, putting them the same you are saying you have no velocity at inlet!

It should not have problem putting totalPressure but it is better to leave zeroGradient because you are already giving that information in isentropicTotalTemperature and might conflict. Once you converge once you can try whatever you want.

The inlet with temperatureDirectedInletVelocity seems fine but your internal field is not so good because at outlet you almost dont have z-velocity.

Also make sure of your rotation sign.

Density is one of the variables..it is a compressible case; density is always changing, that is the one of the consequences of increasing pressure in air!

I think that's all.Apart from this, I don't see any problem..after this modifications if it still doesnt work, if you want to send me your case I can see..

Antonio

[jyothishkumar]

Hi antonio

Thanks for the reply. Now i have started running the case in OpenFOAM. This time with turbulence model also (as you advised). Let me see how it goes. I will update you about that.

thanks

Jyothish

Originally Posted by antoniofct

Hi,

I have already told you this before but maybe you missed that point: when defining totalpressure or isentropicTotalTemperature you are giving the p0 and T0 correctly but the "value" entry is wrong because that is referred to static quantities. So, putting them the same you are saying you have no velocity at inlet!

It should not have problem putting totalPressure but it is better to leave zeroGradient because you are already giving that information in isentropicTotalTemperature and might conflict. Once you converge once you can try whatever you want.

The inlet with temperatureDirectedInletVelocity seems fine but your internal field is not so good because at outlet you almost dont have z-velocity.

Also make sure of your rotation sign.

Density is one of the variables..it is a compressible case; density is always changing, that is the one of the consequences of increasing pressure in air!

I think that's all.Apart from this, I don't see any problem..after this modifications if it still doesnt work, if you want to send me your case I can see..

Antonio

[prasant]

Hello Jyotishkumar,

Did you able to resolve your problem. Is this "isentropicTotalTemperature" boundary conditions is available in the OpenFOAM-1.6-Extd version? I am also solving compressor case using current version of OpenFOAM. In my case temperature is getting very less value at outlet. Please help me regarding this.

Regards
Prasant.

[immortality]

hi
how can i write average values like JK has done?

MassFlows: inlet_0 = 12.5882
MassFlows: outlet_0 = 9.82064
Averages of p : outlet_0 = 90000 inlet_0 = 83291.3
Averages of rho : outlet_0 = 1.07251 inlet_0 = 1.04512
Averages of T : outlet_0 = 291.689 inlet_0 = 277.008
Averages of U : outlet_0 = (0.908873 49.7794 141.731) inlet_0 = (0 0 179.234)

I want to simulate wave rotor that is like turbocharger.how can i make its mesh in to stationary and moving meshes?
all of nice helps would be appreciated.

[immortality]

hi prasant.how did you solve the problem of very low temperature?please let me know youe progress too.

[prasant]

No, I am not able to solve the issue. I tried to modify the h.Eqn code. But still I am getting low temparature values at outlet.

Regards
Prasant.

[prasant]

Hello ehson,

For your task, You should use rhoPorousMRFSimpleFOAM if it is compressible. For that, you should have multidomain mesh. you need to specify the MRF for the rotor domain in MRFZones file, which was situated in the constant directory.

Coming to Averages, There is a library called fieldValues. you need to incorporate that fieldValues in the controlDict dictionary. you can find this file under following locaition

$FOAM_SRC/postProcessing/functionObjects/field/fieldValue/controlDict file

Let me know, If you success with enthalpy issues in compressible flow solvers

Regards
Prasant.

[immortality]

hi Florian
thus how did you get the results before setting proper boundary conditions?

[immortality]

then how did you get results before setting appropriate BC's?