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

Re-arrange parameter view in replaceable heat pump modules #1927

Open
2 tasks
FWuellhorst opened this issue Aug 28, 2024 · 2 comments
Open
2 tasks

Re-arrange parameter view in replaceable heat pump modules #1927

FWuellhorst opened this issue Aug 28, 2024 · 2 comments

Comments

@FWuellhorst
Copy link
Contributor

The current order of parameters and grouping in the available heat pump and chiller modules could irritate users, as it is not directly clear what they have to change and what they might change.
I would

  • move all automatically calculated parameters in a group (or tab) Calculated
  • move fine-tuning parameters to a group Advanced (here, smoothness and extrapolation) or group Data Handling

@mwetter : Any objections?

image

@mwetter
Copy link
Contributor

mwetter commented Aug 29, 2024

@FWuellhorst : I would not move all automatically calculated parameters to a separate group or tab. The pattern we usually follow is

  1. Group related parameters in the same "group" (or "groups" if some are on another "tab").
  2. Make sure every parameter that the user needs to enter, and every parameter that the user should see the default calculation, is on the main tab. Other tabs must not have parameters without a binding.
  3. Special settings that may not need review are on separate "tabs", such as settings for dynamics. Here I am thinking about "Refrigerant cycle inertia", a group which could be moved from the main tab to the existing "Dynamics" tab.

I agree with your 2nd point of moving smoothness and extrapolation to a group, or tab, called Data handling

@FWuellhorst
Copy link
Contributor Author

@mwetter Ok, thanks. Moving the refrigerant cycle inertia would be an option, but as the cycle itself is modelled as steady-state, I think it is important for users to explicitly neglect further dynamics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants