Closed voetberg closed 8 months ago
Could you sketch out what we'd be asking the user to do, and how much time and effort that would take on their part?
I think this is the only variable I'm considering. E.g., if Registering is potentially very onerous for people, then it could be the swaying factor. If it's easy enough, then I'd agree to go with that.
Sure:
Option 1 -
We're asking people to write a function that can be pickled (e.g. is serializable), and save that and pass the path to the executable to the client code within the config or cli args. Besides the trick with it being serializable, very straightforward and we can check that people have gotten it right first thing by just loading it in. Their part looks like this:
def sim(thetas):
....
dill (/pickle/marshal/whatever).dump(sim, out_path)
and then adding a field to the config or an arg to the cli command that points to out_path
.
Option 2 -
We write an abstract class (BaseSimulator or something similar) with the specific methods we need (basically just __call__
) and ask them to run a method to register it with some internal part of code. (We can supply a command). Their part looks like this:
from DeepDiagnostics.simulator import Simulator, register_simulator
class MySim(Simulator):
def __init__(self):
.....
def __call__(self, thetas):
.....
register_simulator("MySim", MySim)
And then adding the name of the simulator ("MySim") to the config.
Option 2 seems very close to people writing their own class for a neural network in pytorch. Is that correct?
Yep, very similar
I propose that we go with option 2 and we can get feedback internally from our crew in mid-April? if people balk at it, maybe we come up with a different strategy?
We need to allow users to bring their own simulator without requiring them to run the client outside of cli/config style.
I see two main approaches:
I'm biased towards option 2, which is probably obvious.