Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide a way to access fedbiomed.common.models.Model of a TrainingPlan #1049

Closed
Tracked by #896
mvesin opened this issue Mar 19, 2024 · 1 comment
Closed
Tracked by #896
Assignees
Labels
done issue is completed, it meets the DoD and was merged to the next release integration branch good first issue nice to pick for a new contributor

Comments

@mvesin
Copy link
Member

mvesin commented Mar 19, 2024

Several portions of code need to access the training plan's Model class, but this currently requires accessing the training plan's private variable, which is not clean;

self.training_plan()._model

This exists in TrainingPlanWorkflow.breakpoint, Experiment.run_once, ...

As a developer, I want to provide a cleaner way to access the Model class.

  1. simple implementation (done in this issue)

Add a function to TrainingPlan with a name complicated and clearly different from TrainingPlan.model() to avoid unwanted access by user, eg TrainingPlan.get_model_wrapper_class()

  1. more complete implementation (mentioned for future evolution, not implemented here)

Re-implement Model class as a subclass (decorator) of nn.Module, SGDClassifier, etc. to avoid duplication of objects and access methods

TorchModel should be a "transparent wrapper" (I think the pattern is often called a decorator). It should retain all of the functionalities of nn.Module, plus some added interface. This would allow researchers to use it transparently as they would use the torch nn.Module, but internally in Fed-BioMed we could also call the added functionality (e.g. get_weights) when needed.

@mvesin mvesin added good first issue nice to pick for a new contributor sprint backlog the development team adds an entry to the sprint backlog to do issue not started yet (but intention to start soon) labels Mar 19, 2024
@mvesin mvesin self-assigned this Mar 21, 2024
@mvesin mvesin added doing issue implementation in progress in review issue implementation is finished, a merge request open and is ready for review (or under review) and removed to do issue not started yet (but intention to start soon) doing issue implementation in progress labels Mar 21, 2024
@mvesin
Copy link
Member Author

mvesin commented Mar 21, 2024

hi @sharkovsky I found that we also have such access from DPController class to optimizer._model

Should we also add a get_model_wrapper_classer to BaseOptimizer ?

@mvesin mvesin added done issue is completed, it meets the DoD and was merged to the next release integration branch and removed in review issue implementation is finished, a merge request open and is ready for review (or under review) labels Mar 22, 2024
@mvesin mvesin closed this as completed Mar 22, 2024
@mvesin mvesin removed the sprint backlog the development team adds an entry to the sprint backlog label Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
done issue is completed, it meets the DoD and was merged to the next release integration branch good first issue nice to pick for a new contributor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant