Define and implement a framework for component quantity unit handling #13

Activity

1. zsarnoczay

   added

   questionFurther information is requestedFurther information is requested

   on Mar 12, 2026
2. zsarnoczay

   added the

   Feature

   issue type on Mar 12, 2026
3. zsarnoczay commented on Mar 24, 2026

   

   zsarnoczay

   on Mar 24, 2026

   CollaboratorAuthor

   More actions

   This has been addressed in PR #20 .

   What was done

   Root cause: The convert_pelicun function in input_builder.py stripped Pelicun's unit metadata and passed raw physical quantities (SF, LF, EA) directly as qnt_damaged, num_comps, and comp_population. The ATC-138 engine expects these as P-58 component unit counts (physical quantity ÷ unit_qty), so the area calculations in the functionality assessment were inflated by unit_qty (often 30–1000×).

   Fix — unit conversion:

   1. Added a _UNIT_TO_SI conversion table and a _pelicun_to_p58_factor helper that computes the combined conversion factor for each component using its Pelicun unit (from CMP_QNT.csv) and its P-58 block size (unit_qty from component_attributes.csv).
   2. The conversion handles imperial↔metric automatically (e.g., m² → sf) and correctly skips components with specialized units (EA → amp/ton/cfm) where the Pelicun value already represents a P-58 unit count.
   3. The factor is applied to qnt_damaged, qnt_damaged_dir_*, num_comps, and comp_population — all quantities that are multiplied by unit_qty downstream.

   Additional fix — replacement time: Pelicun's repair_time-parallel (worker-days) was also being used directly as calendar days for replacement time. Added a conversion that divides by a realistic crew size, consistent with the REDi-based formula used by the repair scheduler.

   Repair times in worker-days and repair costs are left unconverted as they are decision variables not scaled by unit_qty downstream.
4. hgp297

   closed this as completedin #20on Mar 27, 2026