search

GeoscienceAustralia / eqrm

Automatically exported from code.google.com/p/eqrm
Other
5 stars 4 forks source link

Bridge risk as a separate run_type #41

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Bridge risk is currently implemented alongside building risk. If run_type is 
Risk then both bridges and buildings can be specified in the same risk site 
file, yet many parameters do not overlap and the damage model is different.

The proposal is as follows:
- Create a new run_type called "Bridges"
- Refactor logic in analysis and damage_model to separate bridges and buildings
- The risk site file only specifies building parameters and a new file 
specifies bridge parameters
- Ensure that bridge damage is covered in unit tests and implementation tests.

Original issue reported on code.google.com by b...@girorosso.com on 9 May 2012 at 3:49

GoogleCodeExporter commented 9 years ago 
Thanks for putting the ticket in. 
With regards to point 3 in the proposals, currently there are separate building 
and bridge files and the info from these two files are combined within EQRM.  
The info will not need to be combined when the bridge impact is done 
separately.

Original comment by duncan.g...@gmail.com on 9 May 2012 at 4:02

GoogleCodeExporter commented 9 years ago 
I can see that the join method in the Sites object is used to concatenate 
Bridges to an existing Sites object. From the comment:

        Returns a new Sites object containing both 'self' and 'other' data.
        The notional result is:

             lat  lon      attributes
             vvv  vvv  vvvvvvvvvvvvvvvvvvvvvvvvv

             +-+  +-+  +-+-+-------------------+
           > |.|  |.|  |.|.|.........|         |
         s > |.|  |.|  |.|.|.........|         |
         e > |.|  |.|  |.|.|..self...|   NaN   |
         l > |.|  |.|  |.|.|.........|         |
         f > |.|  |.|  |.|.|.........|         |
             +-+  +-+  +-+-+---------+---------+
         o > |.|  |.|  |.|.|         |.........|
         t > |.|  |.|  |.|.|         |.........|
         h > |.|  |.|  |.|.|   NaN   |..other..|
         e > |.|  |.|  |.|.|         |.........|
         r > |.|  |.|  |.|.|         |.........|
             +-+  +-+  +-+-+-------------------+

                       ^^^^^
                    common attributes

Building sites are an object of type Structure, a subclass of Sites. Bridges is 
a subclass of Structure. Perhaps the class structure should be:

Sites:
- Common attributes
-> Structure
   - Building only attributes
-> Bridge
   - Bridge only attributes

Original comment by b...@girorosso.com on 9 May 2012 at 4:18

GoogleCodeExporter commented 9 years ago 
Revision 1101 is a first cut of the bridge refactor.

A few questions:
1. There is existing code that ensures that the event set size is 1 if bridge 
data is used. Is this to remain?

    # check that when we have bridge data, there is only one event
    if have_bridge_data and num_psudo_events > 1:
        msg = 'Input data includes bridges, but number of events > 1?'
        raise RuntimeError(msg)

2. Should bridge sites be able to be used in hazard and fatality run types?

3. The function in output_manager save_structures assumes a building type 
object (Structures). This produces a file <site_tag>_structures.txt. Is this 
required for bridge sites? A new function could write a file 
<site_tag>_bridges.txt with the same sort of format.

4. If save_total_financial_loss is True then two files are written:
<site_tag>_total_building_loss.txt, and
<site_tag>_bval.txt
Is this required for bridge sites? <site_tag>_bval.txt requires a method 
cost_breakdown. This will need to be adapted for bridges if so.

Original comment by b...@girorosso.com on 10 May 2012 at 6:07

GoogleCodeExporter commented 9 years ago 
Answers to the questions as discussed with Duncan:
1. We will keep the event set size at 1 for run_type='bridge'. This will affect 
the output files, so until a new method for producing these is developed, we 
will keep this as is.

2. This is irrelevant. Hazard and Fatality simulations use different site files 
anyway. If the user wants to use bridges for these, they can do in the relevant 
site file.

3. <site_tag>_structures.txt will be used for run_type='risk' only.

4. save_total_financial_loss will be used for run_type='risk' only.

The last two points highlights some confusion as to which parameters are used 
for which simulation type. A 'run_type' validation parameter in 
parse_in_parameters will be introduced.

Original comment by b...@girorosso.com on 11 May 2012 at 4:03

GoogleCodeExporter commented 9 years ago 
Here are the mappings I have come up with. All parameters not on this list are 
assumed to be 'all'.

parameter: 'atten_models',
run_type: all

parameter: 'atten_model_weights',
run_type: all

parameter: 'atten_collapse_Sa_of_atten_models',
run_type: all

parameter: 'atten_variability_method',
run_type: all

parameter: 'atten_periods'
run_type: all

parameter: 'atten_threshold_distance',
run_type: all

parameter: 'atten_spawn_bins',
run_type: all

parameter: 'atten_override_RSA_shape',
run_type: ['risk']

parameter: 'atten_cutoff_max_spectral_displacement',
run_type: ['risk']

parameter: 'atten_pga_scaling_cutoff',
run_type: all

parameter: 'atten_smooth_spectral_acceleration',
run_type: ['risk','bridge']

parameter: 'atten_log_sigma_eq_weight', # is this used?
run_type: n/a # Move to deprecated parameters

parameter: 'use_amplification'
run_type: all

parameter: 'amp_variability_method',
run_type: all

parameter: 'amp_min_factor',
run_type: all

parameter: 'amp_max_factor',
run_type: all

parameter: 'buildings_usage_classification',
run_type: ['risk']

parameter: 'buildings_set_damping_Be_to_5_percent',
run_type: ['risk']

parameter: 'bridges_functional_percentages',
run_type: ['bridge']

parameter: 'csm_use_variability',
run_type: ['risk']

parameter: 'csm_variability_method',
run_type: ['risk']

parameter: 'csm_standard_deviation',
run_type: ['risk']

parameter: 'csm_damping_regimes',
run_type: ['risk']

parameter: 'csm_damping_modify_Tav',
run_type: ['risk']

parameter: 'csm_damping_use_smoothing',
run_type: ['risk']

parameter: 'csm_hysteretic_damping',
run_type: ['risk']

parameter: 'csm_SDcr_tolerance_percentage',
run_type: ['risk']

parameter: 'csm_damping_max_iterations',
run_type: ['risk']

parameter: 'loss_min_pga',
run_type: ['risk']

parameter: 'loss_regional_cost_index_multiplier',
run_type: ['risk']

parameter: 'loss_aus_contents',
run_type: ['risk']

parameter: 'save_hazard_map',
run_type: ['hazard']

parameter: 'save_total_financial_loss',
run_type: ['risk']

parameter: 'save_building_loss',
run_type: ['risk']

parameter: 'save_contents_loss',
run_type: ['risk']

parameter: 'save_motion',
run_type: all

parameter: 'save_prob_structural_damage',
run_type: ['risk','bridge']

parameter: 'save_fatalities',
run_type: ['fatality']

Original comment by b...@girorosso.com on 11 May 2012 at 4:12

GoogleCodeExporter commented 9 years ago 
Documentation/parameter_classification.txt specifies the implemented 
classifications.

This has been implemented in revision 1110, along with updates to the 
documentation, unit tests and implementation tests.

Original comment by b...@girorosso.com on 22 May 2012 at 1:25

GoogleCodeExporter commented 9 years ago 
Revision 1113 merges the branch back to the trunk.

Original comment by b...@girorosso.com on 22 May 2012 at 4:12