Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Partition_plate_leak pressure drop issue #462

Open
Aymeric-La opened this issue Oct 27, 2023 · 4 comments
Open

[FEATURE] Partition_plate_leak pressure drop issue #462

Aymeric-La opened this issue Oct 27, 2023 · 4 comments
Labels
✨enhancement New feature or request

Comments

@Aymeric-La
Copy link

What is your precise need ?

I have used the partition_plate_leak from the WaterSteam/Reheater (and it is made the same way in the SuperHeater and the DryReheater). Analyzing the results of the failure, we noticed that the water that goes by the partition_plate_leak stream meets the same pressure drop as the water going through the tubes. It means there is no natural preference for the water to go a way or another.

Thus, if we have two heat exchangers in parallel branches and that one has a partition_plate_leak, then, the flowrate splitting between the two branches will not be changed although it should be. Indeed, the exchanger which has the failure should have a total pressure drop lower than the total pressure drop of the non-failing exchanger.
image
This can become a problem for the creation of the failure signature of some partition_plate_leaks.

What solution do you see ?

I think the partition_plate_leak should be taken before the pressure drop in the Graphics view of the Reheaters. Maybe it should also have its own pressure drop, different from the main one.
image

@Aymeric-La Aymeric-La added the ✨enhancement New feature or request label Oct 27, 2023
@pierre-eliep-met
Copy link
Collaborator

Hello Aymeric, thanks for this issue !

We agree on the fact that currently the partition_plate_leak does not affect the pressure loss, and because of that it does not affect the total flowrate in the line.
We use to model partition plate leaks that way in the past, and decided to change it because it seemed weird to us that a fault on one HX of one line affects a parralell one.

Also, we are wondering if this change is not a bit negligible, in the end, since we're talking of half the leak flow rate being compensed on each line, which is very small compared to the total feedwater flow rate.

In the meantime, you can simply manually model partition plate leaks as external leaks in your faulty model if you really need it.

@Aymeric-La
Copy link
Author

Hello,

I have double checked and it affects the signature of our faults in a quite important way (compared to what we usually have). Of course, the total flowrate is not changed much but since faults signatures are about zooming on the little differences, the little flowrate difference represents a big gap when we look at symptoms. Besides, on this fault signature, there are not much observables which are highly impacted. Thus, the gap over a few flowrate symptoms strongly affects the global signature.

So, indeed, we can manually correct this by making a fluid stream outside of the component but I think it is interesting for your component to represent this flowrate repartition when the fault is on.

Maybe a solution would be to take the leak before the pressure drop of the cold side, to add a pressure drop on the leak line and to configure this pressure drop as equal to the cold side pressure drop (thus, it doesn't change anything for most of the people). Then, we will be able to play on the fouling of this new pressure drop to change it and thus simulate the flow repartition.
image

@pierre-eliep-met
Copy link
Collaborator

Putting both pipes and a default equation that would be overriden is not satisfactory from our point of view. We'll have to see with a bit more details what's the difference to see if we prefer before or after the pipe, but it will take us some time as we don't have lot of bandwidth right now.
In the meantime, you can get back to putting an external fault, eventhough I agree it would be better to have that internally.

@Aymeric-La
Copy link
Author

Ok, I can manage on my side so there is no rush, it is more a recommandation.

I don't intend to override the equation, I intend to act on the fouling fault of the new pipe :


Added things in the reheater component
// configuration of the new pipe same as the cold_side_pipe
partition_plate_leak_pipe.delta_z = 0;
partition_plate_leak_pipe.Kfr = Kfr_cold;


In the faulty model using the component (like a test)
model Reheater_faulty
extends Reheater_direct(reheater_corrected(faulty=true, partition_plate_leak_pipe(faulty=true) ));

equation

reheater_corrected.fouling = 0;
reheater_corrected.water_level_rise = 0;
reheater_corrected.partition_plate_leak = 20;
reheater_corrected.tube_rupture_leak = 0;

reheater_corrected.partition_plate_leak_pipe.fouling = 0.5;

end Reheater_faulty;


In this way, it doesn't change anything for a normal user who doesn't use this fault (except the Start Values). But I understand that it makes the component a bit "heavier".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants