Numerosity of appliance could be provided as a probability distribution

[Bachibouzouk]

In cases where future demand, in non-electrified zones, has to be modeled it would be useful to provide a probability distribution instead of a fix number of Appliances. Maybe this could also be achieved from the probability distribution by creating different copies of the same Usertypes to which various num_users are set and assigned (for example N1 users from "household which own one light bulb", then N2 users from "household which owns 2 light bulbs", N1 + N2 + ... = N = total household users such that probabilty of having 1 light bulb = N1/N, two ligh tbulbs = N2/N.

[Bachibouzouk]

@FLomb Is there a specific reason why the class Appliance is defined within the User class?

[FLomb]

Hi, I agree; having the possibility to define the number of appliances as a probability distribution is interesting if simulating future demand. But I'm not sure it would make sense otherwise, so it should be optional. However, copying-pasting "User types" doesn't sound super attractive as a solution because it would lead to an ever-growing input file size. Could we think of something neater?

As far as the Appliance class within the User class, when I created the code it seemed to me like the best way to have appliances uniquely associated with user types. That is, to avoid unwanted overlaps between similar appliance types owned by different users. Perhaps I would model it differently now, but it seems quite efficient as is, so I don't see an issue with that. Do you think this makes more complicated addressing the issue above?

[Bachibouzouk]

Could we think of something neater?

I though of something neater, but this would be easier/neater to implement if the Appliance class was not defined within the User class. (The solution I proposed here was just laying out the a way to do it without changing anything in the core code, but I agree it is not the nicest way). In https://github.com/rl-institut/RAMP/pull/7 I implemented a change of modelling by moving the class Appliance out of the User class. Conceptually it seemed to me that RAMP code considers that a User instance has a list of Appliance instances. With that I went further and considered an input file to be an instance of UseCase (newly defined class). This class has a list of User instance.

In a subsequent PR (https://github.com/rl-institut/RAMP/pull/7) @dhungelgd and I moved most of the code from stochastic_process.py into methods of the classes User and Appliance. We could reproduce the behaviour of the code before the changes. We are now writing unittests to test individual part of the code. This process helped us to understand the steps of the algorithm and hopefully make the code more readable to newcomers (I also made comments/docstrings referencing variables and equations from your paper @FLomb).

I not sure in which issue this information I just shared belongs, I'd rather write it here and link to it later than refrain from explaining what we plan to do with RAMP at Reiner Lemoine Institut (RLI) ^^

We would implement new features from the refactored code, now the question is: should we do it independently from RAMP (on our RLI version or should we invest a bit of time (which we at RLI have) to make this a contribution to RAMP (thus more constraints on our side because we need to make sure we do not break anything depending on older versions of RAMP)

[FLomb]

Ok, this sounds super interesting. It would be great to see such developments in the original RAMP repository too, once you guys have finished with your own testing. Even though it would take a while, as you say, to make sure that everything is consistent and that the upgrade is frictionless for users of the current version of the code.

If you guys at RLI are interested in making this contribution part of the original RAMP repository, I'm definitely open to reviewing it and collaborating to bring a PR home.

I'll try to tag other ex-colleagues at Polimi using the tool to see if they'd be open to joining the process too: @Stevogallo

[Stevogallo]

Hi @FLomb and @Bachibouzouk, thanks for pointing this out to me! I am actually at IEW22 with Setu (IIASA) who just explained me the entire project behind this modification you intend to do. I am actually working on something very very similar (except the RAMP modification part) and we for sure can work on this together!

[Slbalderrama]

Hello, @FLomb I was reading this trend and I am also very interested in the possibility on the creation of households with a probability distribution. I was discussing this, with a few colleagues. It will be also interesing on the creation of rural communities, to have more heterogenous appliances ownership to mimic the real composition of a rural village. @ClaudiaLSS and I could also contribute on this.

[Bachibouzouk]

Hi @FLomb and @Bachibouzouk, thanks for pointing this out to me! I am actually at IEW22 with Setu (IIASA) who just explained me the entire project behind this modification you intend to do. I am actually working on something very very similar (except the RAMP modification part) and we for sure can work on this together!

Hi @Stevogallo, we would gladly collaborate on the RLI side :). You mention you work on something similar with another code as RAMP? Or you mean you adapted RAMP without changing something else than the feature?

[Bachibouzouk]

@ClaudiaLSS and I could also contribute on this.

This is great, should we all meet once? I feel it would be nice to be able to talk to each other. I guess everyone who spoke in this thread is within the same timezone. How about next Wednesday 2022-06-01 at 1400 ?

[FLomb]

Not everyone is in the same time zone actually, but perhaps Wednesday at 14.00 CEST might indeed work also for colleagues from a different continent. @Slbalderrama would it work for you and @ClaudiaLSS?

[dhungelgd]

Hi there, I am assisting @Bachibouzouk in the work here at RLI. So, I would also love to be a part of the talk. The time , wednesday at 2 is fine for me as well.

[Stevogallo]

Wed 01-06-22 at 14.00 CEST works for me. you can reach me at nicolo.stevanato@polimi.it if you want to send a calendar once we have all the confirmations.

[Slbalderrama]

Hello, Me and @ClaudiaLSS are in Bolivia, which is -6 hours. I have a meeting at 14 CEST, could we do it at 15?

[FLomb]

I'm available at 15 CEST too. If everyone else is available, I'll send a Zoom invitation to all.

[Stevogallo]

I am not available, wednesday the only moment I have is at 14.00 CEST. Otherwise we can go for the following week (2 and 3 are bank holiday in Italy)

[Slbalderrama]

@FLomb, maybe a doodle would be faster. my email for the moment is sergiob44_47@hotmail.com and claudia: sanchez.solis.clau@gmail.com

[FLomb]

Ok, I've just sent a doodle to all of those here whose email I have or could find. @Bachibouzouk, I have asked your colleague @dhungelgd to share the link to the doodle with you. If anyone is still without a link to the doodle, let me know.

[Bachibouzouk]

June 9th 5pm-6pm seems to be the only time the 5 respondants can meet

[FLomb]

Indeed, so let's confirm such a date and time. I'll send over a calendar invite with a link for the call shortly.

[Bachibouzouk]

https://stackoverflow.com/questions/61545598/generate-random-values-from-boxplot