Modularization and defining specific config files

[jasperschroeder]

Is your feature request related to a problem? Please describe.
There is some duplication of code and configuration files in the current codebase. This makes it hard to maintain and to further extend codebase in the future.

Describe the solution you'd like
In the best case, we can split configurations and code into common and task-specific files.

[matamadio]

I can produce the config files for each hazard type, I just need some guidance on how to frame it.

E.g. I guess each config should list which variables are loaded and set some default parameters.

Floods_config:

• Default flood model: FATHOMv3
• Hazard type: 5 flood types (processing is equivalent) ['FLUVIAL_UNDEFENDED'; 'FLUVIAL_DEFENDED', 'PLUVIAL_DEFENDED, 'COASTAL_UNDEFENDED'; 'COASTAL_DEFENDED']
• Historical (2020)+ projections (period: [2030, 2050, 2080], scenario:[SSP1, SSP2, SSP3, SSP5])
• Return periods: [5, 10, 20, 50, 100, 200, 500, 1000]
• All exposure types allowed
• All approaches allowed

Cyclones_config:

• Default flood model: STORM
• Hazard type: strong wind
• Historical (1979-2014)+ projections (2015-2050)
• Return periods: [10, 20, 50, 100, 200, 500, 1000]
• Allowed approaches:
  • Function x Built-up
  • Classes x Pop, Agri

Heat_config:

• Default flood model: VITO
• Hazard type: heat stress
• Historical (1980-2009)
• Return periods: [5, 20, 100]
• Allowed approaches:
• Allowed approaches:
  • Classes x Pop, Agri

[matamadio]

Starting to stem out the cyclones version, I noticed that on the current modularisation I need to duplicate:

• GUI_F3 > GUI_TC (this is expected but ultimately we could have just one GUI launcher in GUI.ypynb and skip this step additional notebook)
• gui_f3_utils > gui_tc_utils (expected, as this contains the hazard-specific script)
• notebook_utils (includes interface text which is hazard specific)
• damage_functions (this could remain one file if we can rename defs like
  def damage_factor_builtup as FL_damage_factor_builtup and TC_def damage_factor_builtup

For optimisization, I would try to have the minimum of hazard-specific files, possibly just the _utils.py. Would that be possible - does it make sense?

[matamadio]

Taking notes for the differences between FL and TC interface options:

• Some text and descriptions
• Impact function approach only available for built-up. To autoswitch or grey out options. Classes still apply to all
• Preview global TC hazard extent in the map
• Slightly different list of RP and ref periods

[matamadio]

Implemented by PR #57 #56 #54 and related