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

Update documentation with feedback from Maaike #935

Open
datejada opened this issue Nov 25, 2024 · 4 comments
Open

Update documentation with feedback from Maaike #935

datejada opened this issue Nov 25, 2024 · 4 comments
Labels
Type: improvement Better way of doing something Zone: documentation Improvements or additions to documentation

Comments

@datejada
Copy link
Member

datejada commented Nov 25, 2024

Description

Hi, here some comments from @maaikeelgersma on the documentation:

  • The table: wow nice table, but how have the formulas for computing the resolution of the constraints been determined?!
  • Storage balance: I understand how the resolution of the constraint is determined here based on the formula max(asset, min(incoming flows, outgoing flows)), but intuitively I do not understand this formula. Is there a logical explanation that I missed?
  • Consumer balance:
    • Would be nice to repeat exact computation for the resolution here for consistency with the explanation of storage balance, so: min(incoming flows, outgoing flows) = min(3, -) = 3. (or give an intuitive explanation behind the formula first)
    • “as with the storage balance, the flows are multiplied by their duration” I don’t see this in the equations, am I misunderstanding or is a 3 missing on the left-hand-side?
  • Hub balance: same remark as for consumer balance, nice to repeat formula for calculating resolution, would make it easier to follow.
  • Producer capacity constraints: the last wind max_output_flows_limit constraint is for time periods 4:6, so shouldn’t the right hand side be divided by 3 and the summation go from b=4 to 6?

@maaikeelgersma, please feel free to add more comments from your review of the documentation. Thank you for the feedback!

@datejada
Copy link
Member Author

Here my replies:

  • The key is on the Variables involved and Constraint Type columns. So, depending on whether the constraint is in power (i.e., lowest resolution) or energy (i.e., highest resolution) and the individual resolution of the involved variables, then you need to ensure that the constraint's resolution matches its definition. For example, the consumer balance is defined as “power”, and it involves the inputs and outputs, then the constraint resolution must be the minimum resolution among them to ensure it is on the “highest resolution = power”. Imagine you have an input of 1h resolution and an output of 2h resolution; then the constraint must be in 1h resolution (in power, the highest, the min(1h,2h)…etc.). The names are sometimes counterintuitive because you use the minimum function to find the highest resolution. I’m not too fond of the highest/lowest definition; I prefer the power/energy definition.
  • That is an energy constraint but involves the asset and the flows. The flows, as before, must be in power (the highest resolution, then the minimum), and since the constraint is in energy, you want to have the lowest resolution (i.e., the maximum) between the flows and the asset resolution. For example, if you have a pumped-hydro asset with a daily resolution that charges 1h and discharges every 2h, then the resolution of the asset is daily. You can achieve that by only having the maximum in the formula, but we want to cover the case that you have charging every 2 days, discharging 1h and storage balance daily. Then it would be best to have the max(asset, min(flows)) to guarantee the balance is still daily.
  • Consumer Balance:
    • Good point, it will be added
    • No duration is needed, it is a typo, I will create and issue to fix it
  • Good point! Thanks
  • Yeap! A typo again. Thanks 😊

@datejada
Copy link
Member Author

datejada commented Nov 25, 2024

Actions:

  • Fix identified typos
  • Add extra explanations for the users according to the answer in the identified sections
  • Fix constraints rendering on the UC section
  • Shorten the ramp and UC section to be less repetitive with the equations

@datejada datejada added Zone: documentation Improvements or additions to documentation Type: improvement Better way of doing something labels Nov 25, 2024
@datejada
Copy link
Member Author

Maaike's comments on the ramping and unit commitment section with flexible temporal resolution:

  • Ramping in Assets with Multiple Outputs:
    • I found this a bit hard to follow, partially because of the notation. As I understand it now, maybe (part of) the explanation can be changed to something like this: “The first constraint considers the ramping up of output flows of the gas asset from the first hour to the second (b_k =1:1 to 2:2). Note that since the flow(gas,ccgt) is defined in in blocks of 2 hours, we only need to consider the difference of the flow(gas,ocgt) variable in this constraint. However, the second constraint takes the difference between the output flows from b_k = 2:2 to 3:3. For this constraint, we need to consider the difference in both flow(gas,ocgt) and flow(gas,ccgt).”
    • Right now, no explanation is really given for why “In addition, the ramping parameter is multiplied by the flow duration with the highest resolution, i.e., one hour, which is the duration of the flow(gas,ocgt).” is needed. Can this be explained a bit more with 1 extra sentence/example?
    • The notation of the constraint looks strange for me. It would be nice if, for the first one for example, “b_k = 2:2” is on the first line, and the constraint on the second line. (Also for all subsections after this one)
    • Why is the right-hand side 1494?
  • Unit Commitment and Ramping in Assets with Flexible Time Resolution that are Multiples of Each Other:
    • Why are the investment variables not included here like in the section before in the limit_units_on constraints?
    • This section is quite lengthy, but I think that this concept is much easier to grasp than the section before, and it is not needed to write out all the min/max_output_flow constraints from b=1:1 to 8:8 (can skip 3:3-5:5 for sure, probably more). Can also skip some of the max_ramp_up constraints.
  • Unit Commitment and Ramping in Assets with Flexible Time Resolution that are NOT Multiples of Each Other:
    • Typo in the first paragraph: “unist_on” should be “units_on”
    • Limit_units_on(ccgt) constraint for b_k = 7:9 is given, but can be left out I think, concept is already clear from other 2 constraints.

@datejada
Copy link
Member Author

Maaike's comments on the ramping and unit commitment section with flexible temporal resolution:

  • Ramping in Assets with Multiple Outputs:

    • I found this a bit hard to follow, partially because of the notation. As I understand it now, maybe (part of) the explanation can be changed to something like this: “The first constraint considers the ramping up of output flows of the gas asset from the first hour to the second (b_k =1:1 to 2:2). Note that since the flow(gas,ccgt) is defined in in blocks of 2 hours, we only need to consider the difference of the flow(gas,ocgt) variable in this constraint. However, the second constraint takes the difference between the output flows from b_k = 2:2 to 3:3. For this constraint, we need to consider the difference in both flow(gas,ocgt) and flow(gas,ccgt).”
    • Right now, no explanation is really given for why “In addition, the ramping parameter is multiplied by the flow duration with the highest resolution, i.e., one hour, which is the duration of the flow(gas,ocgt).” is needed. Can this be explained a bit more with 1 extra sentence/example?
    • The notation of the constraint looks strange for me. It would be nice if, for the first one for example, “b_k = 2:2” is on the first line, and the constraint on the second line. (Also for all subsections after this one)
    • Why is the right-hand side 1494?
  • Unit Commitment and Ramping in Assets with Flexible Time Resolution that are Multiples of Each Other:

    • Why are the investment variables not included here like in the section before in the limit_units_on constraints?
    • This section is quite lengthy, but I think that this concept is much easier to grasp than the section before, and it is not needed to write out all the min/max_output_flow constraints from b=1:1 to 8:8 (can skip 3:3-5:5 for sure, probably more). Can also skip some of the max_ramp_up constraints.
  • Unit Commitment and Ramping in Assets with Flexible Time Resolution that are NOT Multiples of Each Other:

    • Typo in the first paragraph: “unist_on” should be “units_on”
    • Limit_units_on(ccgt) constraint for b_k = 7:9 is given, but can be left out I think, concept is already clear from other 2 constraints.

• Ramping in Assets with Multiple Outputs:
o I like it, I will add it to the issue to update the docs.
o It is because ramps are given as rates, i.e., MW/h or MW/min, so the parameter must be multiplied by the duration. We will add that to the explanation to make it explicit in the docs.
o Yeah, the rendering is not working properly, and the constraints look odd. We will update that too 😊
o That is the ramping parameter value, but it is not shown in the first table that shows the parameters of the example. We will update it too (nice spotted)
• Unit Commitment and Ramping in Assets with Flexible Time Resolution that are Multiples of Each Other:
o Because these are the constraints for the example, which is only operation (no investments), to make it simpler. But, I will add an extra comment to make it explicit, so the readers don’t have to go to the input data to check that there is no investments.
o I agree, we can shorten it a bit to make it less repetitive, thanks.
• Unit Commitment and Ramping in Assets with Flexible Time Resolution that are NOT Multiples of Each Other:
o Great! Thanks
o Good, we will make it less repetitive 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: improvement Better way of doing something Zone: documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

1 participant