Assumptions should be available to the user in the front-end similar to input values

[ChaelKruip]

As @BerendSmits rightly pointed out, the input values currently featured in the edit-form are probably the least eligible for improvement of the whole data-flow. The assumptions (currently hidden under the hood) are more likely to lead to discussion and incremental improvement.

So, I think we should start to contemplate how to include them. My two cents would be to make to sections:

• Input values
  • Number of cars
  • Gas use per household
  • etc.
• Assumptions
  • Space heaters and hot water
  • Share of combi-boilers for space heating
  • Share of ...
  • Installed capacity of CHPs
  • ...

Including @jorisberkhout @AlexanderWirtz

[grdw]

The assumptions [..]

Just out of clearity: assumptions in this case means values (like demands, shares) which are derived from an initially scaled Dutch graph (; scaled to the number of residences relevant for that municipality, district or neighborhood).

[ChaelKruip]

Just out of clearity: assumptions in this case means values (like demands, shares) which are derived from an initially scaled Dutch graph (; scaled to the number of residences relevant for that municipality, district or neighborhood).

Yes. And possibly other values needed to massage the input data into something the ETM can use (a dataset).

[BerendSmits]

@ChaelKruip do you want all assumptions to be adjustable (thanks @TessColijn!)? Changing one of the shares or one of the demands should be done with caution, as one change affects the entire analysis.

I would propose a sort of step wise expansion of the current analysis, for instance: adding information about heat pumps, adding something about industry, something about insulation, etc. That would allow us to ensure the stability of the entire analysis, and keeps it accessible for external users.

[grdw]

These are the assumptions thusfar as sliders (there are still some missing though) but here is where you - @antw - might help me. I need to balance these sliders but I don't really know how to. Ofcourse this feature already exists in etmodel so if you could point me in the right direction? My guess is that most of the magic happens in the input_element_balancer.js.

Also it might be nice to split the interface elements into groups. Right now it's a bit messy.

[antw]

My guess is that most of the magic happens in the input_element_balancer.js.

Indeed. However this is reliant on Backbone and ETModel's InputElementView and InputElement so the class itself might not be of much use. The normal balancing behaviour can be found in the doBalance function and is pretty simple: sum the values of all the sliders, and if it doesn't equal 100 (the "equilibrium") try to adjust the value of each other slider until it does. There's a little more to it than that in InputElementBalancer (it starts by trying to move the least-recently used slider, takes care of rounding errors and "snaps" values to the step value for each input el) but that's the general principle.

There's an old Quinn branch – "plugins" – where I started to move the balancing feature out of ETModel and into Quinn, but it is incomplete. Maybe it will be of some use?

[ChaelKruip]

Maybe it will be of some use?

@antw What did you use for the sliders for secondary heat infra in SA?

[antw]

SA was already using a different slider library than the one I wrote for ETModel ("Quinn"). I therefore used a pre-existing plugin for that library.

[grdw]

There's an old Quinn branch – "plugins" – where I started to move the balancing feature out of ETModel and into Quinn, but it is incomplete. Maybe it will be of some use?

Yes, this one does the trick! 👍

[grdw]

I have one bug though. I use tabs:

To structure all the slider groups a little bit (ignore the tab names for now).

But whenever I switch tabs the blue line of the sliders isn't 'filled':

Eventhough, style-wise it looks as though it should be. Do you (@antw) by any chance, recognize this issue?

[ChaelKruip]

There's a little more to it than that in InputElementBalancer (it starts by trying to move the least-recently used slider)

@grdw please take into account that setting sliders without this feature can be really confusing/frustrating to the user.

Also, the possibility to click and edit the value by typing can come in very handy!

[antw]

But whenever I switch tabs the blue line of the sliders isn't 'filled':

My guess is that the sliders are being initialized before the container (the tab?) has been inserted into the DOM? If that's the case, Quinn might think that the width of the element is 0px.

Does the blue line get filled in if you move the slider handle to a different position? If that's the case, and you have a reference to the Quinn instances, you could try triggering a redraw:

const slider = new $.Quinn($('.slider'), options);

// Later, when tab is made visible:
slider.trigger('redraw');

If that doesn't help, I think you have a couple of options:

1. It might be enough to set the correct width when the tab is inserted into the DOM (or shown for the first time?). This is a bit hacky and relies on the implementation of Renderer to not change in the future (which it probably won't, but...):

   // When tab is shown
   slider.renderer.width = slider.renderer.wrapper.width();
   slider.trigger('redraw');

2. You might have to wait until the tab is opened before initializing the sliders for that tab. This could be for the best, since it avoids initializing sliders and creating DOM elements that aren't actually needed.

3. If that's not an option, and you must initialize the Quinn instances even without the tab being made visible, you could supply a "null renderer" – so that nothing is rendered – and then give it a real renderer when the tab is first shown:

   const nullRenderer = function() { return {}; };
   const slider = new $.Quinn($('.slider'), { renderer: nullRenderer });
   
   // Later, when tab is made visible:
   if (slider.renderer.render === undefined) {
     slider.renderer = new $.Quinn.Renderer(slider);
     slider.renderer.render();
   }

   I haven't tried this, but in theory... 😇

[antw]

please take into account that setting sliders without this feature can be really confusing/frustrating to the user.

The plugin defaults to least-recently-used behaviour by default.

[grdw]

Does the blue line get filled in if you move the slider handle to a different position? If that's the case, and you have a reference to the Quinn instances, you could try triggering a redraw:

Thanks, this might be the fix I'm looking for stating that that's the behavior I'm experiencing