Project Log – Day 36: Preppin’ for more


So I recently mentioned I might want to distribute my workloads. I wasn’t quite sure to go for that.

I have decided to move forward with the idea, and will be deploying some code with plumbeR on some (new) separate CPUs and threads. Not because it’s a clever idea (in fact, it’s **mostly** a waste of time from a theoretical perspective for my dissertation), but rather because it’s a challenge I personally want to attack, for my own satisfaction. (Actually, to be fair, I guess the whole thing is just that, a challenge that I personally find interesting.)

On the other hand, it’s valuable from the evaluation of my skill level wrt “HPC”, so it’s **not completely** useless either.

So next steps

If all goes well, I can re-deploy next week a “new” Linux box, on a mini PC with 8 cores and 16 threads (maybe I’ll aim to use 14 of them or so). (Buying a new Mac is definitely out of the question right now :D:D.)

Meanwhile I have reviewed some old code I had to expose functions over APIs (as said, using plumbeR – see references, self-reference to this very blog, from 2020). One issue with that is: How to pass all the required (many) parameters to the exposed JSON function? It’s not a lot of data, but it’s a few variables. It needs to be JSON to be compatible with my current understanding of how to code and call plumbeR functions, but one thing that needs to be passed is… A graph! A graph shouldn’t be hard to be transformed to a list (say a list of nodes and edges, maybe labels, positions – not needed, etc.), and vice-versa. A list (or at least a data frame) to JSON is not an issue with the package jsonlite.

But then, this is not the challenge I want to work on, and so I looked it up. Someone has shared their code for just this: igraph to JSON and back, here their GitHub. I can probably use that as inspiration (say as a base for my needs) and add whatever I need (say, for instance, my values for Beta and Mu of each node? Maybe not, in my head that’s not how it would go). Anyhow this helps.

Meanwhile

I found a few papers that appear relevant for my project over the past weeks, as they “do something very similar” or are quite related anyway – a subset:

  • https://dl.acm.org/doi/abs/10.1145/3205455.3205508
  • https://link.springer.com/chapter/10.1007/978-3-319-95165-2_5
  • https://link.springer.com/chapter/10.1007/978-3-030-32622-7_7
  • https://ieeexplore.ieee.org/abstract/document/4937852
  • https://www.sciencedirect.com/science/article/pii/S0169260720315406

I need to put all that in the “.bib” file and make sure that works for my dissertation PDF generator just fine (for now, it… doesn’t :S).

That said, it appears they all choose to act on one or another variable, but not both. Also, they not all consider limited budget (not all these specific ones, I mean), and also they not all use GA, much less binary. Quite a few out there have preferred the SIR simulation. Which to be honest is in my to-do (although that will most probably be left for future work).

The **specific mix** I propose in my work is nowhere to be found in the literature. That’s quite good, I would say, although that does NOT make my own approach ANY better than those other approaches (maybe it’s the contrary, but well…).

Another approach to calculations

Also, my tutor has suggested a while back that I should compare my work (SIS over graph) with an alternative that simplifies calculations and approximates full simulations, based on Markov Chains (a bit inspired by “Mean Field” approaches, from what I can tell). I have some R code to run that “MMCA” approach from a few months back, while I was taking the course on Complex Networks…

I will have to rescue it and adapt it for my “variable Beta/mu per node” thing, and then wrap it correctly so that I can use it with my simplistic binary GA implementation.

TBD.

References

My good ol’ tests of plumbeR

Some R code to transform igraph to JSON and back.