Pelicun 3.1.b2 - bug

[rezvan]

Hello Adam,
Thank you so much for the very helpful version of Pelicun.
I just found a problem related to the stripe number.
In the example that you provided in the Jupiter notebook, I was able to run the analysis for all stipe numbers except '1'.
If you change the stripe number to '1' the following error appears while calculating the damage:

Thank you,
Pooya Rezvan

18:34:15 Calculating damages...
         Applying task from prescribed damage process...
Traceback (most recent call last):

  File "C:\...\anaconda3\lib\site-packages\pandas\core\indexes\base.py", line 3621, in get_loc
    return self._engine.get_loc(casted_key)

  File "pandas\_libs\index.pyx", line 136, in pandas._libs.index.IndexEngine.get_loc

  File "pandas\_libs\index.pyx", line 163, in pandas._libs.index.IndexEngine.get_loc

  File "pandas\_libs\hashtable_class_helper.pxi", line 5198, in pandas._libs.hashtable.PyObjectHashTable.get_item

  File "pandas\_libs\hashtable_class_helper.pxi", line 5206, in pandas._libs.hashtable.PyObjectHashTable.get_item

KeyError: '1'


The above exception was the direct cause of the following exception:

Traceback (most recent call last):

  File "C:\Users\pooya\Desktop\Temp\Python Code\temp2\untitled45.py", line 451, in <module>
    PAL.damage.calculate(sample_size, dmg_process=dmg_process)

  File "C:\Users\pooya\anaconda3\lib\site-packages\pelicun\model.py", line 1991, in calculate
    qnt_sample = self._perform_dmg_task(task, qnt_sample)

  File "C:\Users\pooya\anaconda3\lib\site-packages\pelicun\model.py", line 1775, in _perform_dmg_task
    source_ds_vals = source_cmp_df.groupby(

  File "C:\Users\pooya\anaconda3\lib\site-packages\pandas\core\frame.py", line 3505, in __getitem__
    indexer = self.columns.get_loc(key)

  File "C:\Users\pooya\anaconda3\lib\site-packages\pandas\core\indexes\base.py", line 3623, in get_loc
    raise KeyError(key) from err

KeyError: '1'

[adamzs]

Hi Pooya,

Apologies for the late response, the notification system of the forum did not work properly for a few days and I only saw your message today.

Thank you for reporting this problem, it was a bug indeed. There was not a single collapsed or irreparable realization at the lowest intensity and there was a part in the script that was not prepared for this.

I've fixed the code and will release a 3.1.b3 version later today.

Note that we also updated the FEMA P58 component IDs in this version. What used to be "B1011.001" is now "B.10.11.001". This applies to ALL IDs. The added dots make it easier to parse and group the components. We are preparing a fragility function database and these dots are especially helpful there to facilitate navigation.

I will release this evening an updated version of the Jupyter notebook from the LET in February that has the dots in place for the components. You should be able to test the new version of pelicun at all intensity levels in that notebook.

Let me know if you have further questions and thanks again for taking the time to report this bug.

Adam

[rezvan]

Hi Adam,

Thank you so much for your detailed response.
I will download the updated version of Pelicun for sure and will inform you if I encounter any problems.

Only there is one more thing regarding the Jupyter notebook example (from FEMA P-58 Volume2). In the following lines of the code (to estimate the replacement time), I guess the total area of the building should be used and not the story area. 21600 ft2 is the story area which should be multiplied by 4 to get the total area.

additional_consequences.loc[('replacement', 'Time')] = [0, '1 EA', 'worker_day', 8400] 
# replacement time: 400 days x 0.001 worker/ft2 x 21600 ft2

So many thanks,

Pooya

[adamzs]

Hi Pooya,

The replacement time calculation in the example notebook is just one way to approximate. It is based on the assumption that one floor is built at a time. Now that I think about it, this is almost surely unconservative.

Your suggestion of using all floors with the maximum number of workers is the other end of the spectrum: this assumes that all floors are being worked on for the entire time of the construction. Note that this leads to four times the replacement time in worker-days for the example building.

A third option that might be more reasonable is to use the replacement cost as the basis of the calculation. Assuming that the building is constructed in Los Angeles, we can use FEMA P58's estimate of daily labor cost per worker: $680 (in 2011 USD). We also need to estimate the proportion of the replacement cost that corresponds to labor; 50% is a conservative estimate in my opinion. Now we can take the full replacement cost ($21.6 million), calculate the amount for labor ($10.8 million) and divide by the cost of one worker-day to get the number of worker-days: 15,882.

Depending on how much information you have about the context the building is built in, you might develop more sophisticated methods for replacement time calculation. Note also that both the replacement cost and replacement time of a building has substantial uncertainty in it. This should be considered in the analysis and it finally can be considered in pelicun 3 if the replacement consequences are defined as uncertain quantities.

I will extend the example notebook with this information. Let me know if you have further questions.