You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we only have one type of state in CADET-Core, i.e. the concentration of each component. However, when implementing models for new unit operations, such as filtration or extraction, we might also need additional information about temperature, viscosities, pressures, (partial) densities, etc.
Note that some of these properties are not really component specific but are rather properties of the carrier phase (e.g. temperature, pressure, or viscosity).
In the past, we would have simply used some convention, e.g., the first component is always the salt component, or the last component is the pH etc, and we could do something similar for some of these "new" properties. However, this can quickly become cumbersome when dealing with multiple units. Moreover, some of these properties also need to be treated differently (e.g. they there is no "dispersion" of pressure).
While I do understand that internally it's all "just state", we should have a discussion on how to expose these different state types to the user (for specifying boundary conditions) and also internally to the unit operations models. We could implement some checks which makes some of the state types optional for some systems (e.g. pressure is not currently relevant for our chromatography models). Moreover, it would enable us to write dedicated subroutines for each state type which might increase computational speed (e.g. first compute pH, then solve isotherms, or first compute pressures, then derive flow rates / velocities) by reducing the state size for each problem.
In addition, it would also be helpful to add some other properties to the individual components. For example, for filtration, we need information about the size (or rather, molecular weight), and density of each component. We could move these properties to the unit operation level, but it could also be useful to set some of them globally.
I don't expect any of this to be implemented in the near future, but we should keep it in mind and let it sink in for a while. It will become relevant eventually (and not so far into the future).
The text was updated successfully, but these errors were encountered:
Currently, we only have one type of state in CADET-Core, i.e. the concentration of each component. However, when implementing models for new unit operations, such as filtration or extraction, we might also need additional information about temperature, viscosities, pressures, (partial) densities, etc.
Note that some of these properties are not really component specific but are rather properties of the carrier phase (e.g. temperature, pressure, or viscosity).
In the past, we would have simply used some convention, e.g., the first component is always the salt component, or the last component is the pH etc, and we could do something similar for some of these "new" properties. However, this can quickly become cumbersome when dealing with multiple units. Moreover, some of these properties also need to be treated differently (e.g. they there is no "dispersion" of pressure).
While I do understand that internally it's all "just state", we should have a discussion on how to expose these different state types to the user (for specifying boundary conditions) and also internally to the unit operations models. We could implement some checks which makes some of the state types optional for some systems (e.g. pressure is not currently relevant for our chromatography models). Moreover, it would enable us to write dedicated subroutines for each state type which might increase computational speed (e.g. first compute pH, then solve isotherms, or first compute pressures, then derive flow rates / velocities) by reducing the state size for each problem.
In addition, it would also be helpful to add some other properties to the individual components. For example, for filtration, we need information about the size (or rather, molecular weight), and density of each component. We could move these properties to the unit operation level, but it could also be useful to set some of them globally.
I don't expect any of this to be implemented in the near future, but we should keep it in mind and let it sink in for a while. It will become relevant eventually (and not so far into the future).
The text was updated successfully, but these errors were encountered: