DFlee feature porting

[djgroen]

• [x] Add support for flood-driven spawning settings in SimulationSettings.
• [x] Add support for flood level rule settings in SimulationSettings.
• [x] Add support for reading in flood_level.csv.
• [x] Conversion of flood level data structure in InputGeography to Location attributes (update per time step).
• [x] Implementation of flood-driven spawning in spawning.py

And then:

• [x] Enforcement of flooding rules in moving.py, after previous steps are completed.
• [ ] Update of documentation to describe flooding model feature.

[djgroen]

The flood_level data structure is now in place, and properly being read in and stored on the locations.

@alirezajahani60 I do not have dynamic flood level properties for link attributes yet. Is this something you want to have present in the first version of DFlee, or would you prefer to have an early test version with only location flood levels for now?

Adding dynamic flood level properties for links could take a few days of development effort, i.e. ~2 weeks delay in actually code delivery time.

[djgroen]

Btw. take special note of https://github.com/djgroen/flee/blob/master/tests/dflee.py

This is what I initially wanted you to write, but I put it together myself now. It will be handy for you, as you can see how the DFlee functionality is called and used.

The idea is of course that DFlee will not require a separate runscript. Simple changes in simsetting.yml should suffice for it.

[alirezajahani60]

@djgroen Thanks Derek. I think for the beginning we can have at location level and add dynamic flood level for links later.

I still need help to understand the relationship between the runscript and test_dflee.py! If I understand correctly, by changing the simsetting.yml, I can simply execute the runscript and the test_dflee.py, which is in flee directory would read the input files and the flee.py does the rest of simulation?

[djgroen]

@alirezajahani60 Partially correct! Let me elaborate :)

"If I understand correctly, by changing the simsetting.yml, I can simply execute the runscript"

• Yes, that is correct. That is how you will be able to use it :).

_"and the testdflee.py, which is in flee directory would read the input files and the flee.py does the rest of simulation?""

• Not quite. All the needed functionality will be embedded in the core code. test_dflee.py contains unit tests for DFlee, of which I will make more and more as the implementation progresses. See here for an explanation on unit tests if that is helpful: https://www.techtarget.com/searchsoftwarequality/definition/unit-testing#:~:text=Unit%20testing%20is%20a%20software,tests%20during%20the%20development%20process.

[djgroen]

Documentation is written but not pushed to the repo yet. I will leave this ticket open during the testing phase.