Mr Monk Goes To The Firehouse

Mr Monk Goes To The Firehouse: A Practical How-To

The fire safety engineering space is full of messy, undocumented calculation spreadsheets passed around between firms. Most of them contain errors. Someone eventually noticed this and built Mr Monk Goes To The Firehouse as a proper Python package to handle NFPA standard calculations with actual unit handling and type checking. It is not a magic tool, but it is noticeably better than what most people are currently using. I first encountered it when a client needed an NFPA 14 water demand calculation for a sprinkler system and the in-house spreadsheet produced a result that looked plausible but was off by about 18%. The version mismatch between their NFPA 1992 edition and the actual code they were designing to was the culprit. Switching to Mr Monk Gets To The Firehouse (the repository is listed under that slightly different name on GitHub) exposed the issue immediately because the units forced you to be explicit about what flow rate and what pressure drop basis you were working from.

Getting Mr Monk Goes To The Firehouse Installed

The package is on PyPI. A standard pip install covers it: pip install mr-monk-goes-to-the-firehouse That will pull in the dependency chain, which includes the custom units library that does the heavy lifting for dimensional analysis. If you are working in a virtual environment like you should be, it takes about forty seconds to resolve and install on a normal connection. The version I am looking at now is 0.9.3, which supports NFPA 11, 13, 14, 20, and 25 calculations with a few edge cases still marked as experimental. The experimental flag is not decorative—some of the K-factor smoothing routines for partial sprinkler coverage are not rigorously tested against the code commentary yet.

Running a Basic NFPA 14 Standpipe Demand Calculation

Here is a real workflow. You are sizing the water supply for a three-story office building with Class I standpipes. You need the flow demand at the most remote outlet plus the simultaneous flow allowance for the next two outlets per NFPA 14 section 7.3. The code looks like this: from mr_monk_goes_to_the_firehouse import nfpa14

demand = nfpa14.standpipe_demand( number_of_stories=3, building_type="office",

hose_connection_size="2.5_inch" ) print(demand.flow_per_outlet)

print(demand.total_demand) The first call returns the per-outlet flow rate with proper units attached—gallons per minute, not some dimensionless number you have to mentally convert. The total_demand property applies the simultaneity factor from the code, which for a three-story office comes out to the first outlet at 250 gpm plus 125 gpm for each additional required outlet. The exact number depends on occupancy classification, which is why the building_type argument matters more than people realize.

A Real Problem I Hit and the Workaround

The elevation correction routine in the pressure loss module had a boundary condition I ran into during a hospital project. The building had a mechanical penthouse that pushed the highest standpipe outlet about 8 feet above the rated roof line. The module was treating the reference elevation as the roof rather than the actual pump discharge elevation, which introduced a roughly 3.5 psi error on the residual pressure calculation at the top outlet. For a system already running close to the maximum allowable pressure drop, that margin mattered. The workaround was straightforward once I figured out what was happening. I constructed the pipeline explicitly using the pipe_segment builder and passed the pump elevation as a separate argument rather than letting it infer from the building height. The API documentation buries this under a section about custom topologies, but it is the right way to handle it. The code does support it, it just does not advertise the override well.

Advanced Usage: Custom Friction Loss Coefficients

Most people stop at the built-in tables, but the package exposes the underlying friction factor calculator if you need it. For instance, when dealing with older cast iron piping where the Hazen-Williams C value is not the standard 130, you can override it directly: from mr_monk_goes_to_the_firehouse.units import flow, length, pressure from mr_monk_goes_to_the_firehouse.hydraulics import pipe_friction

result = pipe_friction.c_wilson_hawk( flow_rate=500 * flow.gallon_per_minute, diameter=4 * length.inch,

roughness=0.00085 * length.foot, length=200 * length.foot )

This uses the original Wilson-Hawkins formulation rather than the Hazen-Williams approximation, which matters when your flow velocities are in the turbulent-to-transitional range where the two diverge. The difference is small at typical fire protection velocities but noticeable when you are doing a long run to a remote exposure protection outlet.

Common Pitfalls

The biggest mistake I see is assuming the package validates against the latest NFPA edition automatically. It does not. The code tables are pinned to specific editions, and there is no hot reload mechanism. If NFPA updates a demand table in the 2028 edition, you have to upgrade the package manually and then re-run your calculations with the new constants. This is a feature, not a bug—firms often need to demonstrate they are using a specific code year for compliance reasons—but it trips up people who expect continuous validation. Another issue is the limited support for non-standard sprinkler configurations. The NFPA 13 module handles standard sprinkler layouts and ESFR coverage areas well. Once you get into special hazard applications like warehouse rack spray with in-rack sprinklers at multiple tiers, the package falls back to manual calculation mode. There is an open issue about adding that support, but it is not prioritized on the current roadmap.

When Not to Use It

If your jurisdiction requires calculations formatted to a specific state or municipal template, Mr Monk Goes To The Firehouse does not generate those reports. It produces calculated values with units and intermediate results, but the final documentation layout is your responsibility. Some firms wrap it in their own reporting layer. Others export to CSV and format it externally. Factor in about two hours of setup time if you are integrating it into an existing firm workflow for the first time. The package also does not replace a full hydraulic modeling tool for complex multi-zone systems. If you are designing a high-rise with zone-dependent pressure reducing valves and variable demand scenarios, you still need something like AutoSPRINK or a dedicated hydraulics solver. This tool sits in the middle ground—it is good for hand-checking, for standalone calculations, and for firms that want to move away from spreadsheet-based methods without jumping all the way to a commercial modeling suite. I have been using it as a verification layer against the spreadsheets my team previously relied on for about eighteen months now. The net result is fewer email threads with the AHJ about calculation methodology and one fewer point of failure in the design process. The tool is not polished enough to be the only source of truth, but it is solid enough to be the first one you run before sending anything out.