Damage Functions Storage and Selection Mechanism

[trietmnj]

Going from raw damage function data to usage during simulation, current implementation utilizes two sets of structs:

- DamageFunctionFamily (DFF) / DamageFunctionFamilyStochastic contains a map of hazards.Parameters to damage function paireddata sets

- OccupancyTypeDeterministic / OccupancyTypeStochastic contains the structure and contents damage function families

Another representation is f(DamageFunctionFamily | OccupancyType) where f is the damage function (x,y) paireddata. Each OccupancyType is represented as a function with a built-in hazards.Parameters selection mechanism and hard-coded raw data within the source code. Adding in additional paireddata sets with another damage driver means adding to an already 2000+ lines data store in 50+ functions. Let's restructure this store to move the raw data to the persistent storage layer and collapse the hazards.Parameters selection to a single location.

[HenryGeorgist]

related to #34

[HenryGeorgist]

I think long term storage should be separated from importable formats. In terms of long term storage, we will have a default dataset stored on the cloud somewhere as a resource file. A simple XML file could work very well, or JSON.

For user input, upload from a csv or an excel file would work great, we just need to specify the import file structure. I do not think our storage structure should match our user input structure

[trietmnj]

My vote is for JSON, it's much easier to debug just from a simple glance.

[trietmnj]

Should we decouple the structure and content families? Right now, if the structure family is stochastic, the content family has to be as well, and vice versa. Should we add in the flexibility for one of them to be stochastic and one deterministic?

I have configured a pair of damage functions before where the study where the structure damage function came from is different than where the content damage function came from.

[HenryGeorgist]

ultimately there is a sample method on the damage function family you can see an example of the code here:

go-consequences/structures/occupancytypes.go

Line 166 in cedb277

func (o OccupancyTypeStochastic) SampleOccupancyType(seed int64) OccupancyTypeDeterministic {

the following snippet helps explain the sampling process:

func samplePairedDataValueSampler(r *rand.Rand, df interface{}) paireddata.ValueSampler {
	retval, ok := df.(paireddata.ValueSampler)
	if ok {
		return retval
	}
	//must be uncertain
	retval2, ok2 := df.(paireddata.UncertaintyValueSamplerSampler)
	if ok2 {
		pd := retval2.SampleValueSampler(r.Float64())
		pd2, ok3 := pd.(paireddata.PairedData)
		if ok3 {
			pd2.ForceMonotonicInRange(0.0, 100.0)
			return pd2
		}
		return pd
	}
	return retval
}

All damage functions run through this method. If they are deterministic, they get passed through, if they are not deterministic, they get sampled, and the sample is passed as deterministic, which allows for an OccupancyTypeStochastic to store either deterministic or uncertain relationships for the damage functions.

[HenryGeorgist]

After a recent refactor, the code has evolved to allow for an OccupancyTypeProvider, and we have implemented a JsonOcctypeProvider to intercede between a persistent storage layer and the code.