search

multiply-org / multiply-core

The core functionality of the MULTIPLY platform
2 stars 5 forks source link

Emulator Engine #4

Open bulli92 opened 7 years ago

bulli92 commented 7 years ago

Has the emulator engine to be part of the platform itself? The practical workflow will be that you have an RT model and calibrate an GP emulator based on that. The calibrated emulator is then used for the inference engine.

Thus I would consider the emulators as well as the RT models themselves to be actually some software outside of the actual platform. Only the calibrated emulators will be directly used and should be therefore part of the platform.

@jgomezdans to comment

jgomezdans commented 7 years ago

The emulator engine should be part of the platform, at the very least as a strong dependency. The reason behind this is that if we change the emulator code (likely) we want to make sure it's still compatible with the overall architecture. The other thing is that the training of the emulator and its use in prediction are actually not that different, so there's no point in splitting things apart.

bulli92 commented 7 years ago

Thanks Jose for the clarifications. Seems there is a misunderstanding. I was not thinking of separating it entirely, but for me the emulator engine is not something that runs each time you make a retrieval. For me it is therefore more a kind of a second piece of code (e.g. executable python command line tool) that I run on demand with the RT models as an input.

Thus for me the emulator engine is kind of static and changes only from time to time. A normal user would not care about it at all. An expert user will do so.

Thus I could think of the dummy version actually only CALL already preprocessed GP emulators, rather than actually calling the engine itself.

On 6/28/17 12:31 PM, José Gómez-Dans wrote:

The emulator engine should be part of the platform, at the very least as a strong dependency. The reason behind this is that if we change the emulator code (likely) we want to make sure it's still compatible with the overall architecture. The other thing is that the training of the emulator and its use in prediction are actually not that different, so there's no point in splitting things apart.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/multiply-org/multiply-core/issues/4#issuecomment-311621568, or mute the thread https://github.com/notifications/unsubscribe-auth/ACt0C0CAyeJZ13SB4mR0rlCBjjKYwezQks5sIit_gaJpZM4OHmFZ.

TonioF commented 7 years ago

I agree with Alex on this one: I guess in most cases we want to re-use existing emulators anyway. The computation of these emulators is different and independent from the other processing of the platform.

I don't really see a need NOT to include it, so we might leave this open. For starters we can leave it out. In any case we'd need to define a user interface for this, so users can choose to create an emulator without running the platform. This doesn't have to be grapical (for now).