Can I modify gas ejector block to work in this cycle?

Hello,

I am modelling my jet ejector refrigeration cycle, I managed to represent every other component according to their real-life parameters, but I fail to do the same with jet ejector.

The most suitable library block to use seemed to be gas ejector (Ejector G), by elimination, as the jet pump works with liquid, and moist air ejector has to high droplets component for my application. However, I encounter a problem, as Ejector (G) block requires pure vapour, which in certain conditions I cannot provide (for certain pressure ranges I locally have sudden gas condensation from rapid flow in a supersonic nozzle).

From analysing the single block model (only ejector) I assumed it is the problem, because working with real gas (R1234yf refrigerant), it shows error and breaks when detects conditions close to condensation. I attach a block with ideal gas, that works, as well as the refrigeration cycle to show you the whole picture.

Please, can someone confirm, if the problem really comes from the component? If so, which block would be of better use? If not, please tell me how to repair it

I read in a different post, that we can modify the component, and to code a part of its behaviour, but as I don't have much expertise, I cannot assess if it of higher benefit to code it from zero (and how?) or to modify the already existing block (and how). I can provide working maps, critical points, I have CFD simulation results, would it be possible to implement them? How?

Thank you

Paulina

[Yifeng Tang]

Hi @Paulina, could you please describe what kind of CFD results you have? For ejectors, the most useful data would be maps of primary flow and entrainment ratio as functions of primary, secondary, & outlet pressures.

[Paulina]

Sure, I have the maps, I have the pressures, temperatures, mass flows, velocity distributions..... full simulations, everything that you mentioned and more!

Answer 1

[Yifeng Tang]

Hi @Paulina,

I like your idea of trying to use library block as much as possible, in this case the Ejector (G) block. I think the limitation in your current implementation comes from the Interface (2P-G) block. This block enforces equal pressure, temperature and mass flow, but this can be insufficient/wrong when phase change happens. I would assume the A & S ports are always superheated vapor, but when they mix, the B port can become a mixture; is that what you observed, too?

A workaround I can think of involves a bit more coupling between the G & 2P domain, but has to be done manually. I attached a proof-of-concept.

The three reservoirs on the left represent where the ejector will be connected to in your bigger model. The infinite flow resistance blocks are there just to avoid needing multiple property blocks. Sensors are placed at the three locations to assign P & T to the reservoirs in the Gas domain. We then left the Ejector (G) block to calculate the mass flow, sense them, and apply to the 2P side. As this happens, we can also measure the ejector outlet condition and apply to a controled reservoir in 2P. Instead of P & T, we can measure P & enthalpy so the state is uniquely determined, and energy conserved. This, however, requires that you have the proper properties in the Gas Property block on the right.

Just an idea. Haven't done this before. Hope it works :)

Thanks,

Yifeng

[Paulina]

Hello and thank you for your answer. I am not sure about the energy balance in this case. It looks like the output from the ejector will not be the realistic result, as we are still dealling with a gas approximation within it, am I right? If you could explain more precisely what you intended to do.

It makes me think that the most realsitic results could be obtained by trating this block, probably redefined as a pure code, to be a black box fed with my maps... does it make sense to you?

[Yifeng Tang]

Is it OK to "assume the A & S ports are always superheated vapor", as I mentioned earlier? If so, the unrealistic part here is that the outlet of the Ejector (G) block sometimes "should" be a mixture but is treated by this Gas domain component as ... gas. This is handled by bringing in the pressure and enthalpy at the outlet to the 2P domain, and the 2P properties will make a mixture if necessary. This ejector block assumes adiabatic relations, so it being gas doesn't bothers me much as we are not losing any energy. Of course, you'll need to make sure the gas properties and the 2P vapor properties are consistent AND you'll need to "fake" more gas properties that would otherwise be in the vapor dome (maybe use ideal gas law?). Otherwise the enthalpy from the gas domain will give you a completely different state.

Was there anything else you were concerned with that may not be realistic enough?

That said, yes, it's possible to do this as a black box with look up tables filled with CFD data. I believe the primary flow is a function of the primary and outlet pressures, while the secondary flow depends on all three pressures. So it's a 2D table + a 3D table. There may needs to be some density dependency on the secondary side, but I'm not sure whether it's necessary in your case. I previously needed to do that when dealing with multiple gas species mixed together, but you are working with only one fluid. I'll leave it to you to find out :p Keep the mass flow sources "power added" option as "none" instead of "isentropic", so you retain the energy conservation. If you have enough CFD data to cover all the inputs and ranges of interest, this should work.

My personal opinion is to try the first approach as much as possible, as it should be more predictive and useful if successfully implemented. But it's just an idea that I THINK will work. The 2nd approach I've done it before. If you have enough data, I'm confident it will work. The downside of course is you need new CFD data if anything about the ejector or operation range ever changes.

Hope this helps.