diagram out structural changes to code to support reconstruction

[HenryGeorgist]

Reconstruction is a feature in go-consequences we seek to include. This ticket is for evaluating the strategy and structural changes expected in the code base to plan out the feature.

1. is this a relevant change to go-consequences or should this be in consequences-runner?
2. evaluate what parameters need to be tracked for reconstruction, identify all interfaces that need to be created or extended
   a. is reconstruction period a damage category or occupancy or structure level attribute? what does it contain?
   b. what other reconstruction parameters need to be tracked? number of times damaged? if it is in the flood zone (eo11988 compliance)
   c. how do we want to handle events? do we extend the consequences receptor interface to allow for an array of hazards? how do we want to manage it?
   d. do we need hazard provider changes?
3. given the parameters develop psuedo code for how reconstruction would be accomplished.

[HenryGeorgist]

@sebastianrowan i cant tag you as the assignee

[trietmnj]

Reconstruction is a feature in go-consequences we seek to include. This ticket is for evaluating the strategy and structural changes expected in the code base to plan out the feature.

1. is this a relevant change to go-consequences or should this be in consequences-runner?

First thought (with only having a superficial understanding of both repos) would be go-consequences. This is an modification/extension to the theoretical scientific framework rather than things that are mechanical intended to adapt to whatever data required for a project. Like the hazardproviders and resultswriters

2. evaluate what parameters need to be tracked for reconstruction, identify all interfaces that need to be created or extended
   a. is reconstruction period a damage category or occupancy or structure level attribute?

One of the workflows to generate the structure inventory data provides the flexibility to modify all the attributes on each structure. So I'm leaning toward structure level attributes. This would also provide the flexibility to condition the parameter on the occupancy type if the user wants to model it that way, but it would not work in the opposite direction.

what does it contain?

not too sure what this means

b. what other reconstruction parameters need to be tracked? number of times damaged? if it is in the flood zone (eo11988 compliance)

@rustypermenter what are current fields being tracked in G2? I suspect the right list should be something very similar.

c. how do we want to handle events? do we extend the consequences receptor interface to allow for an array of hazards? how do we want to manage it?

I suspect this would need to be thought of in the context of the lifecycle framework. Would only information related to the hazards suffice? How do you want to track the state of the inventory from the previous event?

d. do we need hazard provider changes?

I haven't gotten my hands on the script that generates the lifecycle dynamic with timestamps yet, but probably. You would need to incorporate that timing information, right?

More on this once I have that script.

3. given the parameters develop psuedo code for how reconstruction would be accomplished.

Maybe more on this one later once I get what fields would be needed to be tracked from @rustypermenter

[trietmnj]

@rustypermenter other issues related to reconstruction that needs to be think about.

1. how many times to reconstruction - default 5 in g2
2. flood zone eo11988 - more than 50% -> recontrstruct above bfe - req params: damage threshold + elevation threshold
3. no reconstruction polygon - similar to hec-fia

[rustypermenter]

G2CRM tracks the number of significant rebuilds, current value, depreciation and time value of money calculations, structure type, and population numbers and age bracket. Tied up in the current value is the rebuilding with a linear rebuild for all assets based on the user specified triangular distribution and the time from the storm event. The time for rebuilding does not depend on the severity of the event, and is strictly calculated on the value from the triangular distribution.

[rustypermenter]

The typical evaluation in G2CRM would be as follows.

1. Check to see if event is damaging for element type-otherwise no need to evaluate damages.
2. Calculate flood elevation above first floor.
3. Retrieve triangular distribution values from damage functions for contents and structure damages.
4. Report all damages.
5. Determine if the structure requires raising due to NFIP or other policy requirements. Schedule raising if necessary.
6. Determine rebuilding time based on triangular distribution.
7. Initiate rebuild. If subsequent event occurs before end of rebuilding value of the asset is prorated linearly based on the rebuild time.

[trietmnj]

This is an example of the information available to track when a storm hits.

https://github.com/trietmnj/stormsim/blob/main/data/intermediate/conversion-lifecycle-generation/EventDate_LC.csv

The sampling was implemented so that the vast majority of events would not violate the minimum arrival period. There are edge cases where this might be violated when sampling failed for all 1000 tries, though this is exceedingly rare. It typically occurs when the annual number of storms is very high, i.e., >7.

Across 5,000 lifecycles, each covering 50 years, the violation happens in 3 distinct years, i.e., the failure rate is 3/(5000*50). If it fails to generate a sample that meet the minimum arrival period, the last sample is what gets written out.

If this edge case is a problem, let me know. There are definitely options to adjust.

Edit: Another caveat is that there is yet information related to extra-tropical storms included here. Only tropical.

[sebastianrowan]

@rustypermenter for raising a structure, is the cost to do this tracked in the analysis? If so, are there parameters that determine the cost to raise a structure based on occupancy type, size, etc?

Is raising a structure the only mitigation option? What about dry/wet flood proofing? Are there data to estimate the cost to implement these solutions for a structure and how they would affect the damage curves?

[HenryGeorgist]

raising a structure to elevate above the bfe is policy from EO 11988. other mitigation options exist, but there is specific language being targeted in this case.

the cost side is not a go-consequences concern it would be a concern of the calling application

[rustypermenter]

@rustypermenter for raising a structure, is the cost to do this tracked in the analysis? If so, are there parameters that determine the cost to raise a structure based on occupancy type, size, etc?

Is raising a structure the only mitigation option? What about dry/wet flood proofing? Are there data to estimate the cost to implement these solutions for a structure and how they would affect the damage curves?

@sebastianrowan For G2CRM, the cost to raise by vertical foot, target raising elevation are specified by asset. Post storm triangular distributions for structure value, contents value, and rebuild times are also specified. The cost per vertical foot is used due to the differences in initial structure elevation induced by the FFE triangular distribution. It doesn't necessarily make sense that that is a linear relationship, it may be better as a lump sum. (I'm not sure that raising a foot is much cheaper than two feet.) We can do dry/wet floodproofing as an alternative by changing the asset type or completely replacing assets, resulting in new damage curves in both cases. Again, all of this functionality is in G2CRM.