Opened 12 years ago
Closed 10 years ago
#147 closed enhancement (fixed)
Simplify PropagationEffectParameter interface/abstract hierarchy
Reported by: | Peter Powers | Owned by: | Peter Powers |
---|---|---|---|
Priority: | minor | Milestone: | OpenSHA 1.3 |
Component: | sha | Version: | |
Keywords: | Cc: |
Description
The concrete implementations of PropagationEffectParameter? are all double valued. Was there an assumption early on that there might be any type of value associated with a propagation effect?. In the future this may be the case, but for now the abstract class and interface hierarchy is messy with numerous duplicated methods in classes such as WarningDoublePropagationEffectParameter?.
Adjust PropagationEffectParameter? to inherit from WarningDoubleParameter? then most of the work is done for all the Dist* parameters. The PropagationEffectParameterAPI is also unnecessary at this time.
Change History (6)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
- Initial restructuring; created AbstractDoublePropEffectParam? and AbstractBooleanPropEffectParam?
- Eliminated unused methods in PropogationEffectParameterAPI
comment:3 Changed 12 years ago by
Milestone: | OpenSHA 1.2 → OpenSHA 1.3 |
---|
The above changes were a good start. On a related note (#36) I would like to have the distances calculated by any distance param and it's complement in PropEffect? reference the same (static?) method to guarantee that their both always doing the same thing.
Other tickets related to PropEffect?: #36 #131
comment:4 Changed 12 years ago by
RE "I would like to have the distances calculated by any distance param and it's complement in PropEffect?? reference the same (static?) method to guarantee that their both always doing the same thing"
This would lose the efficiency provided by PropEffect?, which was the purpose of creating it in the first place. I don't think that slight redundancy is a big deal.
comment:5 Changed 12 years ago by
Yes, as stated I see what you mean. PropEffect? locally computes horzDist and rupDist only once whereas it would be repeated if separated out for each distance metric. I'd only advocate separating out the redundant parts if it will improve clarity and testability.
comment:6 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Marking this as fixed as distance calcs are now done by rupture surfaces themselves
There will be non-double propagation parameters (e.g., a boolean stating whether a site is on the hanging wall)