Opened 13 years ago

Closed 11 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 13 years ago by Ned Field

There will be non-double propagation parameters (e.g., a boolean stating whether a site is on the hanging wall)

comment:2 Changed 13 years ago by Peter Powers

in [7517] and [7518]

comment:3 Changed 13 years ago by Peter Powers

Milestone: OpenSHA 1.2OpenSHA 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 13 years ago by Ned Field

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 13 years ago by Peter Powers

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 11 years ago by Kevin Milner

Resolution: fixed
Status: newclosed

Marking this as fixed as distance calcs are now done by rupture surfaces themselves

Note: See TracTickets for help on using tickets.