Mednext

[rcremese]

Fixes # .

Description

This pull request is intended to solve some of the issues pointed by @jzielke in the MONAI pull request 8004. A lot of the updates come from the MONAI dev branch I'm using which is ahead of your mednext branch, but let me summarize the changes I made :

• nets/mednext.py
  -- renamed MedNeXt arguments to follow @jzielke recomendations
  -- linked residual units of the encoder and decoder with one do_res flag
  -- add model variants (S, B, M, L) as described in the original paper
  -- solved code formating issues and corrected the module imports as stated in https://github.com/Project-MONAI/MONAI/blob/dev/CONTRIBUTING.md#checking-the-coding-style
• blocks/mednext_block.py
  -- removed the author defined LayerNorm and replaced it with torch.nn.LayerNorm as only the "channel_first" case is used in block and network definition .
  -- renamed OutBlock to MedNeXtOutBlock to avoid naming confusion as the block is accessible in the API
  -- fixing module class export
• test/test_mednext.py
  -- removed all the do_res_up_down test cases as do_res_up_down as been fused with do_res arguments
• __init__.py
  -- made available the different versions of MedNext to the API as done by DenseNet

I should add some tests for the mednext_block.py script and evaluate the performance of the model on a benchmark used by the author (BTCV or AMOS22). I also tested all the basic unit test and they all pass so you don't have to do it ./runtests.sh --quick --unittests --disttests.

Types of changes

• 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.

[surajpaib]

Hi @rcremese,

I think you'll need to rebase your work off of my branch so I can see the diff. changes.

You'll need to do something like this,

git checkout -b surajpaib-mednext mednext
git pull [email protected]:surajpaib/MONAI.git mednext
git checkout mednext
git rebase surajpaib-mednext

This will generate some merge conflicts that you'll need to fix and this will give a diff. from my branch so we can compare changes between my code and yours.

I would do it myself but I don't have push access to your branch.

Let me know if you have any troubles with it

[surajpaib]

Alternatively, if you add me as a collaborator to your fork, I could do this myself.

[rcremese]

Oups, I guest I did something wrong. I sent you an invitation to be a contributor in my fork. I will also try to do some of the git trickery for my own and send you a new pull request.

[rcremese]

Ok ! I did what you said and hope it will resolve the previous conflicts. Tell me if it doesn't because my git history seems grounded with commits that aren't yours.

[surajpaib]

Hi @rcremese, sorry for force-pushing on your branch but I've now updated the PR so it reflects only your changes to my code. Will do a review shortly!

[surajpaib]

@rcremese I would prefer to do a factory method pattern similar to how it exists for resnets: https://github.com/Project-MONAI/MONAI/blob/59a7211070538586369afd4a01eca0a7fe2e742e/monai/networks/nets/resnet.py#L36

for consistency

[rcremese]

Well, I took exemple on densnet and SEnet which are both integrated into the core library.

Moreover, there are only 4 architecture variants in the original paper so it shouldn't polute the script that much.

[surajpaib]

I see the inconsistency now.

Factory methods are better in this case I would say - it keeps them simpler as we are not using any functionality provided by subclassing the MedNext parent. Moreover, if we want to add custom logic like loading some pre-trained weights, these lend better too.

[surajpaib]

Using factory methods should greatly simplify these code blocks as well!

[surajpaib]

@rcremese I'll go ahead and merge this PR - we can discuss more on my upstream