search

uma-pi1 / kge

LibKGE - A knowledge graph embedding library for reproducible research
MIT License
776 stars 124 forks source link

Support user default configuration #92

Closed samuelbroscheit closed 1 year ago

samuelbroscheit commented 4 years ago

How about we introduce a default config that - when present - is loaded after config-default.yaml, that has some default configurations that are specific for a machine, e.g. job.device, search.devicepool, paths, ...

When I work on my laptop, I don't have a GPU, my local-config would have "job.device cpu", while on my workstation it would contain "job.device cuda".

Could be located in kge/local/machine-config.yaml

rgemulla commented 4 years ago

Couldn't that be handled in users themselves? E.g., one may create a script/alias which adds these values automatically to the call to kge.

I think we should try to keep the framework as lean as possible.

samuelbroscheit commented 4 years ago

When the answer is "create a script/alias which adds these values automatically to the call to kge" then for me the answer is a no-brainer. The natural way that we encourage with the framework is to work with configs. We don't want to encourage users to change config-default.yaml and its a common use-case to have some scenario/user dependent default configurations.

A even better solution would be to support multiple configs which are loaded in the order given to kge. Then the first config can act as a default config. This would also allow, for example, to elegantly switch back and forth during prototyping between different default settings for max_epochs and batch size.

rgemulla commented 4 years ago

Sounds to me like this is more tooling around the framework.

One may add a command-line switch which contains an additional config(s) to load in between config-default and the specified main config. That's probably useful. But that switch would have to be specified every time.

Automatic loading of user-defined configs (without being specified) is not a good design for the purposes of LibKGE, however. It's also not necessary, one may just use an alias.

rufex2001 commented 4 years ago

In general, I also feel such things should be kept out the framework. Having used it hundreds of times on many different machines, this feels like something I, as a user, should pay attention to. Having said that, I am not against the idea of being able to provide an additional config file for some machine settings. We already allow command line overwrites, so this could be seen as a way to make that scalable.

Still, I can't help but think this can also be done in the one config file one has to provide anyways, so it feels like an additional unnecessary layer, albeit useful in some scenarios.