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.

[sebastianrowan]

I used the existing UML diagram to document interfaces that I assume will require updates. These changes are based on the following assumptions.

1. Reconstruction/lifecycle analysis will be implemented in go-consequences. Specifically, I assume we will implement a StreamAbstractLifecycle function within the compute module.
2. We will be dealing with a large number of depth grids as inputs.

If these assumptions are correct, I can go ahead and begin working on the implementation.

Some psuedo-code for the StreamAbstractLifecycle function:

func StreamAbstractLifecycle(hps []hazardproviders.HazardProvider, sp consequences.StreamProvider, w consequences.ResultsWriter, w2 consequences.ResultsWriter) {
    bbox := hps[0].HazardBoundary() // this could also be a user-defined param added to the func call.

    sp.ByBbox(bbox, func(f consequences.Receptor) {
        var summary_results // not sure what type this would be yet.
        for h in hps {
            d := h.Hazard() // this should include an arrival time but I'm not currently sure where that would be specified
            r := f.Compute(d)
            // parse the result
            // update f structure/content values based on reconstruction time and time to next hazard (or do this before Compute based on previous hazard
            // write iteration result to file.

            // add iteration result to some running total of a summary calculation.
        }
        // write summary/totals to a summary results writer
        w2.Write(summary_results)
    }
}
```

[HenryGeorgist]

i dont think stream processor will be changed, though in your proposal the injected function (which comes from compute stream lifecycle) changes, but the stream processor interface doesnt change.

i think im with you on the unsure about the resutls writer changing, i probably would be more inclined to think it does, but im still honestly really on the fence about that.

the receptor in your proposal doesnt really seem like it changes, i actually think you are really just changing the controlling/calling method and adding logic at a higher level (which is a fine proposal).

What if we created an interface "MultiHazardConsequencesReceptor" that has a method ComputeMultiHazard(hazards []Hazard) []ConsequencesResult and created a "MultiHazardProvider" that has "ProvideHazards(location geography.Location) []Hazard

Hazard is already multi parameter which includes arrival time, so that piece is already sorted.

i think we should talk through your proposal and my riff on your proposal in a quick phone call before implementation.