-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Merging/overriding configs with same format in monai bundle run #5899
Comments
Hi @surajpaib , Thanks for the feature request, we already have some recursive overriding for the args: Thanks. |
@Nic-Ma Yes exactly. Among one use case, we might want to have a base config defining a run for a particular dataset and have a separate config for a new dataset. This separate config could have several changes such as a larger batch size, different patch size, more workers etc. It would be inconvenient to define all of these as |
Hi @surajpaib , If I understand correctly, for your use case, you can pass both the "initial config" and the "override config" to the "config_file" arg, it will automatically override it, refer to the example command in this README about how we run multi-gpu training: https://github.com/Project-MONAI/model-zoo/tree/dev/models/spleen_ct_segmentation. Thanks. |
Hi @Nic-Ma, Yes, having both the configs in Consider the following basic config,
Overriding it now would be done something like this,
I think this makes it more difficult for the user to read through the configs and make changes, especially when the configs get large.
Very easy to go through and edit. Do you think it makes sense to add this capability to allow for these use-cases? Thanks in advance! |
Hi @surajpaib , Thanks for the detailed description of the fearure request. "network": {
"_target_": "UNet",
"spatial_dims": 3,
"in_channels": 1,
"out_channels": 2,
"channels": [16, 32, 64, 128, 256],
"strides": [2, 2, 2, 2],
"num_res_units": 2,
"norm": "batch"
} There can be 2 kinds of cases to override it: "network#in_channels": 3 (2) Override the whole model definition with a new set of parameters, like: "network": {
"_target_": "UNet",
"spatial_dims": 2,
"in_channels": 3,
"out_channels": 1,
"channels": [16, 32, 64, 128, 256]
} Then all the "network" config item will be overridden, no need to care about the previous parameters anymore. Thanks in advance. |
Hi @Nic-Ma , For cases (1) and (2), the format would be very similar indeed.
However, only parameters that are defined should be overridden, both for cases (1) and (2). Having (1) and (2) consistent for the user with the logic that what is defined is overridden makes it easier to understand, in my opinion. Functionally, they both operate very similarly, so I wonder if there is a need to define a different syntax for them? |
Hi @surajpaib , I still feel it's necessary to have "#" path to help define the "start point" of overriding in the nested structure, let me give you another example: {
"train": {
"transforms": [
{
"_target_": "LoadImaged",
"keys": [
"image",
"label"
]
},
{
"_target_": "EnsureChannelFirstd",
"keys": [
"image",
"label"
]
},
{
"_target_": "Orientationd",
"keys": [
"image",
"label"
],
"axcodes": "RAS"
},
{
"_target_": "Spacingd",
"keys": [
"image",
"label"
],
"pixdim": [
1.5,
1.5,
2.0
],
"mode": [
"bilinear",
"nearest"
]
},
{
"_target_": "ScaleIntensityRanged",
"keys": "image",
"a_min": -57,
"a_max": 164,
"b_min": 0,
"b_max": 1,
"clip": true
},
{
"_target_": "EnsureTyped",
"keys": [
"image",
"label"
]
},
{
"_target_": "RandCropByPosNegLabeld",
"keys": [
"image",
"label"
],
"label_key": "label",
"spatial_size": [
96,
96,
96
],
"pos": 1,
"neg": 1,
"num_samples": 4,
"image_key": "image",
"image_threshold": 0
}
]
}
} If I only want to override the Thanks in advance. |
Hi @Nic-Ma, What you pointed out makes perfect sense. There is no need to remove the current behavior, which is very useful for precisely the case you outlined above. But adding support to have it in a standard config format identical to the base format can also be very useful too. I think the Is there a possibility of supporting both? Thanks! |
Would I summarise the issue as that overriding values in a second config file does work as needed if using the # operator and some nesting where needed, but that for large or deep replacements this can be unwieldy? The solution here is to allow a sparse structure to be defined which is merged with the original, replacing or adding values in places. My issue with that is this sparse structure looks a lot like any other that represents a full definition rather than an aspect of one. |
Signed-off-by: Wenqi Li <[email protected]>
this feature could be easily added, so I'm including it f2ba40c |
Fixes #6387 Fixes #5899 ### Description - add api for update_kwargs - add support of merging multiple configs files and dictionaries - remove warning message of directory in `runtests.sh` ### Types of changes <!--- Put an `x` in all the boxes that apply, and remove the not applicable items --> - [x] Non-breaking change (fix or new feature that would not break existing functionality). - [ ] Breaking change (fix or new feature that would cause existing functionality to change). - [ ] New tests added to cover the changes. - [ ] Integration tests passed locally by running `./runtests.sh -f -u --net --coverage`. - [ ] Quick tests passed locally by running `./runtests.sh --quick --unittests --disttests`. - [ ] In-line docstrings updated. - [ ] Documentation updated, tested `make html` command in the `docs/` folder. --------- Signed-off-by: Wenqi Li <[email protected]>
This is great! Thanks @wyli |
for the record it's implemented at the given
the merged config will be |
Is your feature request related to a problem? Please describe.
Currently, overriding config can be done through an
args_file
argument pointing to a json/yaml provided to therun
script. However, it only merges configs at the base level, and to override nested structures, the#
format must be used.Example,
This gives the output,
However, if the config provided to
args_file
is in the same format (shown below) as theconfig_file
, it does not do the merge,Describe the solution you'd like
It would be beneficial to have the ability to merge these two configs when they are in the same format to allow for use cases where a default config is set to have good parameter definitions, and the user only needs to define/override specific fields.
Describe alternatives you've considered
I tried specifying two of these configs as a list in this form as well,
But it doesn't seem to handle overriding keys, although it merges non-conflicting keys.
My temporary fix
To achieve the functionality I needed, I've changed the following,
MONAI/monai/bundle/config_parser.py
Line 223 in 86c7ecd
to
Additional context
Ideally, it would be nice to have the ability to merge configs in the
config_file
list. Is there a way to do this, and am potentially missing something?The text was updated successfully, but these errors were encountered: