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

Property naming conventions for vapor pressure and saturation vapor pressure #1481

Closed
kurbansitterley opened this issue Sep 3, 2024 · 4 comments · Fixed by #1482
Closed
Assignees
Labels
Priority:High High Priority Issue or PR

Comments

@kurbansitterley
Copy link
Contributor

I have relative_humidity = vapor_pressure / saturated_vapor_pressure.

According to the IDAES docs page on IDAES property naming conventions, vapor_pressure should be pressure_sat, which I am not sure I understand (since vapor_pressure would not be saturated unless relative humidity is 100%... or maybe I am missing something). But then does that mean saturated_vapor_pressure should be pressure_sat_equil? In this case, vapor_pressure is the partial pressure of water under given conditions and saturated_vapor_pressure is the vapor pressure of water in equilibrium with an open liquid surface.

I suppose the issue here is:

  • how to name these properties such that they would adhere to the current IDAES naming conventions
  • if pressure_sat on the docs page should be pressure_vap (or something else)
  • if there needs to be a new conditional qualifier _sat... or really how the IDAES community feels about this in general?
  • separated but related issue: the IDAES docs pages has conc_phase_comp['liq', 'H2O'] as a valid property name, but does concentration not require a basis? What would be the units of such a property?

Or maybe there is a different way to do it that would adhere to the conventions as they are already laid out?

(This may be better suited as a discussion rather than an issue so I am happy to move it if so)

@andrewlee94
Copy link
Member

@kurbansitterley I think the source of your confusion is that you are thinking of a fairly specific use case where as the IDAES names are general (i.e. they have no concept of a liquid surface, boundary layer or anything like that). Note that "vapor pressure" is somewhat ambiguous (hence the IDAES names), as there are different states at which you might want the partial pressure of a component. Thus, we went with somewhat more technical, but hopefully more specific naming.

  • what you are referring to as "vapor pressure" is the partial pressure of H2O at the current state, which by naming conventions is pressure_comp["H2O"] (or whatever name you gave water).
  • what you are calling "saturated vapor pressure" is the partial pressure of water at saturation, which is pressure_sat_comp["H2O"].

Hopefully that clears things up a bit.

R.e. conc_phase_comp is not a valid name, and should be comp_BASIS_phase_comp - if you can point us to where it says that (or correct it yourself) it would be appreciated.

@andrewlee94
Copy link
Member

And an after thought - the above assumes only a vapor phase is present. If you have a multiphase system then you would want pressure_phase_comp and pressure_sat_phase_comp.

@kurbansitterley
Copy link
Contributor Author

@andrewlee94 I appreciate the response and had not thought of pressure_comp["H2O"]. I agree this a specific use case and I went down the rabbit hold of wanting to conform to conventions.

I have opened #1482 to address the conc_phase_comp question. And now that I am looking at it - does flow_comp["H2O"] not also require a basis?

@andrewlee94
Copy link
Member

Yes, it should be flow_BASIS_comp.

@ksbeattie ksbeattie added the Priority:Normal Normal Priority Issue or PR label Sep 5, 2024
@ksbeattie ksbeattie added Priority:High High Priority Issue or PR and removed Priority:Normal Normal Priority Issue or PR labels Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:High High Priority Issue or PR
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants