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
This was originally posted by @DanielSarmiento04 as a comment in #77. I've re-posted it here because it's an interesting idea.
I have been using the library for the past few months in parallel to a thermodynamics course
I like the piromat ecosystem
I made this repository when I used for solve Brayton, Rankine and >combine Cicle, these example you can use for tutorials.
Another suggestion that I found is the next
Simply code
Normally, for optimize time processed and debugger I use state_x = 'fluid'.state('propierties')
this return a dictionary and for mapping the information we have to use .get dictionary method h_x = state_x.get('h')
something to improve is use the status type objects
I thought about doing this when I wrote the state methods. There are a couple of reasons I decided not to do it yet, but that doesn't mean it will never happen
It is awkward to write a single state class that can represent data from all substances. For example, quality and saturation properties are meaningless for an ideal gas. These are issues that can be dealt with, but they can also be dealt with by a dictionary.
In my opinion, promoting a dictionary to a class is best done only when implementing class methods is important. The state class would merely be a container for the property values.
There are plans to add additional properties soon, which would make this an awkward time to design a class that could represent all properties.
Still, I think this is still a good idea, so it's worth opening it for discussion.
2. In my opinion, promoting a dictionary to a class is best done only when implementing class methods is important. The state class would merely be a container for the property values.
Thinking out loud here, so please excuse. One method that would maybe be of value is wrappers for quickly converting the units for all properties an already computed state. But that doesn't necessarily have to be a class function as opposed to a function that can operate on the dict. The one advantage I could see for a class approach would be to carry the units along with the values as an extra field. In principle that could happen with the dict but might be messier?
This was originally posted by @DanielSarmiento04 as a comment in #77. I've re-posted it here because it's an interesting idea.
Originally posted by @DanielSarmiento04 in #77 (comment)
The text was updated successfully, but these errors were encountered: