Updating codebase to newest openFL version (for FeTS Challenge): broken imports

[Linardos]

Hello,

I'm trying to update the FeTS Challenge codebase which relied on a much older version of openFL (3 years old). As I'm updating things, some of the imports are hard to map to the current code. One example is this:

ModuleNotFoundError: No module named 'openfl.component.aggregation_functions'

I'm not able to find this particular function "aggregation_functions" in an older version

https://github.com/securefederatedai/openfl/blob/v1.5.1/openfl/component/__init__.py

but nor in the old one either so not sure maybe I'm missing something?

https://github.com/securefederatedai/openfl/blob/v1.0/openfl/component/__init__.py

[sarthakpati]

I believe aggregation_functions have moved under the interface submodule [ref].

[kta-intel]

@Linardos @sarthakpati
Follow up: I managed to get to a state where FeTS_Challenge.py could run successfully (without the per_label metrics). Here's a PR with the changes along with a brief explanation explanation. These are added directly onto @Linardos's latest fork. Please check it out and let me know if any questions/issues.

Note: One issue I couldn't get passed was during the inference step. runner_gandalf.py expects a train.csv file which gets hardcoded during loader_gandalf.py. Only workaround was to create a patch that allowed the train csv path to be None if you were running inference. It's a bit hack-y, but hopefully it unblocks you. Then we can update the challenge more robustly for 2025

[Linardos]

Kevin, you absolute champion, you did it, it works.
I'll try classification with it soon.

[sarthakpati]

That's brilliant, @kta-intel! Thank you so much.

[sarthakpati]

I would suggest that we incorporate CI tests that always test the code (and any PRs) against the latest versions of both openfl and gandlf.

[kta-intel]

Glad to hear that it worked! I appreciate all your help and patience throughout this. Hopefully this should be enough to get us through the 2024 challenge and we can work to together to update for next year

I would suggest that we incorporate CI tests that always test the code (and any PRs) against the latest versions of both openfl and gandlf.

Yes, totally agreed!

[Linardos]

I'm working on making classification work for our updated GaNDLF/OpenFL FeTS codebase (Starting a separate thread in the same discussion to have things more organized)

I discovered that apparently the csv files in the plan yaml are never used by the algorithm (https://github.com/Linardos/Challenge/blob/main/Task_1/openfl-workspace/fets_challenge_workspace/plan/plan.yaml#L31-L32 When I commented out lines 31, 32 in plan yaml nothing changed in how the code run. Also it seemed to still be loading segmentation masks as targets, which indicates the "seg_" csv files are hardcoded somewhere and these config parameters were artifacts all along.

@kta-intel at some point you figured out these two were generated here in a previous version: https://github.com/Linardos/Challenge/blob/ba5b35bbfe6b0be2033df6eb42df54257f451b93/Task_1/fets_challenge/experiment.py#L313-L314.
but did you find where they're loaded into the federated algorithm?

@psfoley let us know if you have some insight on this

---

EDIT: I figured it out. Where there was one csv generator, I now split to two so it may generate partitions for classification https://github.com/Linardos/Challenge/blob/main/Task_1/fets_challenge/gandlf_csv_adapter.py#L198

I added a print statement for sanity that looks good:

=== Sample of Partition 32 - Train Data ===
SubjectID,Channel,ValueToPredict
FeTS2022_01031,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01031/FeTS2022_01031_t1.nii.gz,0
FeTS2022_01031,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01031/FeTS2022_01031_t2.nii.gz,1
FeTS2022_01031,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01031/FeTS2022_01031_flair.nii.gz,2
FeTS2022_01031,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01031/FeTS2022_01031_t1ce.nii.gz,3
FeTS2022_01030,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01030/FeTS2022_01030_t1.nii.gz,0
FeTS2022_01030,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01030/FeTS2022_01030_t2.nii.gz,1
FeTS2022_01030,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01030/FeTS2022_01030_flair.nii.gz,2
FeTS2022_01030,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01030/FeTS2022_01030_t1ce.nii.gz,3
FeTS2022_00118,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_00118/FeTS2022_00118_t1.nii.gz,0
FeTS2022_00118,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_00118/FeTS2022_00118_t2.nii.gz,1

=== Sample of Partition 32 - Validation Data ===
SubjectID,Channel,ValueToPredict
FeTS2022_01033,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01033/FeTS2022_01033_t1.nii.gz,0
FeTS2022_01033,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01033/FeTS2022_01033_t2.nii.gz,1
FeTS2022_01033,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01033/FeTS2022_01033_flair.nii.gz,2
FeTS2022_01033,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_01033/FeTS2022_01033_t1ce.nii.gz,3
FeTS2022_00126,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_00126/FeTS2022_00126_t1.nii.gz,0
FeTS2022_00126,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_00126/FeTS2022_00126_t2.nii.gz,1
FeTS2022_00126,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_00126/FeTS2022_00126_flair.nii.gz,2
FeTS2022_00126,/home/locolinux2/datasets/MICCAI_FeTS2022_Resized/FeTS2022_00126/FeTS2022_00126_t1ce.nii.gz,3

[kta-intel]

Thanks for the follow up! Glad to hear you were able to resolve it

[sarthakpati]

Thanks a ton, @Linardos!