Add seed_everything into CLI side

[harimkang]

Summary

@jaegukhyun reported an issue that the seed was not being frozen, so I looked into it.
The seed is frozen after the OTXModel is created, so in some cases the seed was not being frozen.
OTXModel random feature: classification layer initialization

add fix seed function into the CLI.

How to test

seed=0, deterministic=True, model: atss_mobilenetv2
Trial 1: val/map_50: 0.750 val/map_75: 0.502
Trial 2: val/map_50: 0.750 val/map_75: 0.502
Trial 3: val/map_50: 0.750 val/map_75: 0.502

Checklist

• I have added unit tests to cover my changes.​
• I have added integration tests to cover my changes.​
• I have added e2e tests for validation.
• I have added the description of my changes into CHANGELOG in my target branch (e.g., CHANGELOG in develop).​
• I have updated the documentation in my target branch accordingly (e.g., documentation in develop).
• I have linked related issues.

License

• I submit my code changes under the same Apache License that covers the project.
  Feel free to contact the maintainers if that's a concern.
• I have updated the license header for each file (see an example below).

# Copyright (C) 2023 Intel Corporation
# SPDX-License-Identifier: Apache-2.0

[vinnamkim]

This will disable seed settings on the Python API side. Please find a way to maintain it rather than removing it.

[harimkang]

This will disable seed settings on the Python API side. Please find a way to maintain it rather than removing it.

Yes, I think that's a good point.
How do you think we should deliver on the API side?
I think there are three ways.

1. drive people to use lightning.seed_everything (-> For users who only use OTX, this may be awkward.)
2. provide the function in 1 as a function of otx like (-> It simply wraps the function that calls seed_everything once more in otx.)
3. take it as an engine's creation argument (in this case, if the user is already build a module, the seed might not be fixed in some cases).

I don't really have a preference and would love to hear your thoughts.

[vinnamkim]

This will disable seed settings on the Python API side. Please find a way to maintain it rather than removing it.

Yes, I think that's a good point. How do you think we should deliver on the API side? I think there are three ways.

1. drive people to use lightning.seed_everything (-> For users who only use OTX, this may be awkward.)
2. provide the function in 1 as a function of otx like (-> It simply wraps the function that calls seed_everything once more in otx.)
3. take it as an engine's creation argument (in this case, if the user is already build a module, the seed might not be fixed in some cases).

I don't really have a preference and would love to hear your thoughts.

I don't see any reason why the original code cannot setup the seed correctly. Is it because the datamodule already spawned the data pipeline workers before the engine creation?

[harimkang]

This will disable seed settings on the Python API side. Please find a way to maintain it rather than removing it.

Yes, I think that's a good point. How do you think we should deliver on the API side? I think there are three ways.

1. drive people to use lightning.seed_everything (-> For users who only use OTX, this may be awkward.)
2. provide the function in 1 as a function of otx like (-> It simply wraps the function that calls seed_everything once more in otx.)
3. take it as an engine's creation argument (in this case, if the user is already build a module, the seed might not be fixed in some cases).

I don't really have a preference and would love to hear your thoughts.

I don't see any reason why the original code cannot setup the seed correctly. Is it because the datamodule already spawned the data pipeline workers before the engine creation?

Yes, that's right.