ThermofluidStream.Examples.SimpleAirCycle
Isses about ThermofluidStream.Examples.SimpleAirCycle;
-
I first thought the two sides of the model represent left and right pack of an aircraft. It took a while, until i understood, that this is not intended by the model and that the sides are actually two seperate models, that would never be combined into one aircraft. Therefor i suggest to highlight it by using seperate inlets and outlets for simple cycle and three wheel bootstrap cycle.
-
It would be beneficial to explain the ram air boundary conditions, i.e.
p_in = 0.3 baris the total pressure,T_in = -30 °Cis the total temperature andp_out = 0.22 baris the static pressure. Those values correspond to a static temperatureT = -50.6 °Cand velocityv = -203.5 m/s = 730 km/h. The static pressure and static temperature approximately correspond to an altitudeh = 11.1kmand a temperature difference ofdT = 5.9 Kto ISA0 (Actuallyh = 11.1kmis slightly above the limit of troposphereh = 11kmand i did not check the exponent in the tropopause but the 100m dont matter a lot i guess). That means: the boundary conditions are meaningful, but one needs some knowledge to check where they come from. -
The fan has a pressure ratio
pr = 0.53/0.3 = 1.76, the compressor has a pressure ratiopr = 3.0/2.5 = 1.2which does not seem realistic to me. In my opinion the main reason is the rather bad implementation ofThermofluidStream.Processes.Internal.TurboComponent.dp_tau_const_isentrop. The example prooves that even for an official example we can not manage to design turbocomponents using the function. I made another issue for this implementation. -
The simple cycle yields outlet temperature
T_out = -2.37°Cand a mass flow ratem_flow = 0.514 kg/s, the three wheel bootstrap cycle yields outlet temperatureT_out = -1.57°Cand a mass flow ratem_flow = 0.507 kg/s, i.e. from this example one would conclude that a simple cycle yields better performance (lower outlet temperature and higher mass flow rate) at lower complexity/weight/higher safety than a three wheel bootstrap cycle. I think we should reconsider that. -
It might be beneficial to use
displayInstanceNames,displayParameters, rename components and order them correctly to simplify the use of the example. -
For a better overview sensors/displays might be beneficial too.
- To further improve this we might consider using corrected speed and mass flow rates https://en.wikipedia.org/wiki/Compressor_map for compressor curves
This is the form in which we usually receive component data from vendors.
Yes we might consider if some one wanna write a thesis and implement a nice compressor/fan/turbine component, im not sure if i have enough time...
Sorry if I am a bit confused. I tried to applaud your suggestion on using corrected speed and corrected flow as an answer to the mail sent on #217, where that suggestion was included. But on the web page the text differs from the mails and the suggestion is only in #218. The mail for #218 is empty…
But anyhow. Good suggestion!
Yes sorry, first I got it wrong :)
@RaphaelGebhart Your comments are all fine. Additionally, this shall be documentad accordingly in the model. (I suppose you are not the only person who misunderstand the example.)