My Variables Only Have 6 Letters

J-waves after ROSC and Intra-arrest Therapeutic Hypothermia

2012-02-07T17:23:00.000-05:00

The following is the post-resuscitation 12-Lead electrocardiogram of an 82 year old female who received intra-arrest therapeutic hypothermia, via chilled saline and ice packs, as part of a new protocol for cardiac arrest management. The patient also received three defibrillations and was administered epinephrine, naloxone, and amiodarone during the resuscitation.

12-Lead ECG obtained approximately 5 minutes after ROSC

The post arrest 12-Lead ECG shows a sinus rhythm with frequent premature atrial and ventricular ectopic complexes. The LifePak 12, which uses the GE Marquette 12SL algorithm, displayed the ominous *** ACUTE MI SUSPECTED *** message and suggested a lateral injury pattern.

Closer inspection of the lateral precordial leads reveals the ST-elevations present are actually giant J-waves, or Osborn waves.

J-waves--or Osborn waves--appreciated in the lateral precordial leads

Recognizing this finding is present, a closer look at the entire 12-Lead ECG shows that subtle J-waves are present in almost every lead group.

Subsequent 12-Lead ECG obtained 17 minutes after ROSC

A repeat 12-Lead ECG acquired 12 minutes later shows a sinus tachycardia with a single PAC, without the giant J-waves from the initial ECG, diffuse ST/T-wave changes consistent with ischemia are also present. However, small J-point elevation persists in the lateral precordials. The computerized interpretation no longer believes a STEMI-pattern is present and incorrectly identifies the rhythm as atrial fibrillation.

Comparison of the precordial leads between the first and subsequent 12-Lead ECG.

A side by side look at the precordial leads provides an interesting look at the near resolution of the giant J-waves post-ROSC.

One explanation for the normalization of the traditional electrocardiographic findings of hypothermia may be related to the management of the patient's ventilation both intra-arrest and post-arrest. As the patient's pH normalized with mechanical ventilation and a perfusing rhythm, so did the repolarization abnormalities (visualized as J-waves).

References

Antzelevitch C, Yan GX. J Wave Syndromes. Heart Rhythm. 2010; 7(4):549-558. [FullText]
Fenstad ER, et al. Therapeutic hypothermia in out of hospital sudden cardiac arrest: Significance of J-waves. J Am Coll Cardio. 2011; 57(14):Suppl 5, E1002. [PDF FullText]
Edelman ER, Joynt K. J Waves of Osborn Revisited. J Am Coll Cardio. 2010; 55(20):2287. [PubMed]
Dr. Smith's ECG Blog: Osborn Waves and Hypothermia.

Philips Healthcare's Sierra ECG format XLI Compression Scheme

2011-12-26T20:52:00.000-05:00

One of the services I work for has recently acquired a Philips HeartStart MRx cardiac monitor. It came complete with Bluetooth transmission of 12-Lead and event data. At roughly the same time our service installed a computer, an MDT, into the cab of our unit to interface with our county's CAD software.

Naturally I linked our monitor and our MDT via Bluetooth, and transmitted a 12-Lead from a rhythm generator. When the file landed on the MDT, I looked for an application to view the 12-Leads and rhythm strips, however, none appeared to be able to use the file as-is.

For the non-technical, the ECGs are shipped compressed--somewhat like a ZIP file--which contains all of your monitored vital signs, printed rhythm strips, and your 12-Leads. The format of the 12-Leads is an Open Standard; Philips Healthcare provides most of the details needed to use the files. The 12-Lead data is also compressed to save space. Unfortunately, there is no documentation which tells you how to decompress the 12-Lead data.

The technically-faint-of-heart should skip these next bits.

For the technical, the ECGs are contained in a Gzip'd TAR archive. The 12-Leads are stored inside in an XML format known as the Sierra ECG format (currently at version 1.03 or 1.04, as far as I can tell). Inside this XML format is Base64 encoded, XLI compressed data comprising the acquired leads during a 12-Lead (up to 16 leads appear to be able to be stored).

I searched for a description of the XLI compression format, however, I was only able to find a reference implementation for Microsoft Windows which simply decoded the files. No code or description was provided and the implementation itself is not portable.

At this point I decided my only option was to reverse engineer the XLI Compression format, and began with simple guesses. I tried decompressing the data using Deflate, Zip, and RLE without any progress. I was able to determine that the first 8 bytes of the compressed data included a compressed length, some uncompressed data, and that each of the 12 to 16 leads were stored in a chunk with one of these headers:

offset   2        4        6        8  ...
+--------+--------+--------+--------+--------+--------+--------+
| Size            |  Unk.  | Delta? | Compressed data...       |
+--------+--------+--------+--------+                          |
| ...                                             [Size bytes] |
+--------+--------+--------+--------+--------+--------+--------+
| Next lead chunk ...                                          |

Once the simple guesses were ruled out, I began exploring the behavior of the reference implementation provided for the Sierra ECG format. While exploring with OllyDbg, certain code tells made me believe the decompression algorithm read 10-bits at a time:

SHR   EAX, 16h   ; reduce EAX to the 10-bit code word
SHL   ECX, Ah    ; prepare to read 10 more bits from the input

The compressed data also did not appear to contain a dictionary referenced by the code. At this point I considered I was looking at a form of Lempel-Ziv-Welch, or LZW, compression. LZW is a popular, lossless compression scheme which creates its compression dictionary on the fly. It is used by the GIF and TIFF image formats, and was the subject of controversy when it was first introduced into the GIF format due to patent licensing requirements.

In my quest to quickly reach a conclusion I found an excellent LZW implementation from Mark Nelson in C and found it successfully decompressed the data. In fact, the structure of the C code was so familiar, I realized the reference implementation from Philips used the exact same code!

If you've reached this step while following along at home, you'll notice the decompressed data seems front-loaded with 0's. This is a case of intelligently streaming the data to the compression algorithm to take advantage of data duplication.

The uncompressed data represents 16-bit delta codes, of which the majority include 0x00 or 0xFF in their most significant byte (MSB). This is because they are either small and positive or small and negative, and as ECG data is rhythmic the delta codes are likely to retain the same sign for numerous samples.

To take advantage of this fact during compression, the delta codes are first deinterleaved into two halves. The first half includes each MSB and the second half includes each LSB. The pseudo-code for interleaving the decompressed data looks like the following:

# input contains the decompressed data
# output will contain the interleaved 16-bit delta codes
fun unpack( input[], output[], nSamples )
    for i <- 1..nSamples
        output[i] <- (input[i] << 8) | input[nSamples + i]
    endfor
endfun

At this point the delta compression scheme will need to be decoded to produce the actual signal data for each of the leads. The delta compression scheme is a simple recurrence relation (a second order difference relation) using the prior two delta codes:

# output contains the 16-bit delta codes
# first is the 16-bit delta code from the chunk header
fun deltaDecompression( output[], nSamples, first )
    x <- output[1]
    y <- output[2]
    prev <- first
    for i <- 3..nSamples
        z <- (2 * y) - x - prev
        prev <- output[i] - 64   # is -64 to 64 the range?
        output[i] <- z
        x <- y
        y <- z
    endfor
endfun

Now that you have the actual, per signal data all you need to do is recreate leads III, aVR, aVL, and aVF. This is done using the data from leads I and II as on most ECG machines. I've omitted the actual formulas for brevity.

Using my reference implementation of the decompression algorithm I was able to feed the original acquired 12-Lead to the Philips ECG to SVG converter, with the following results:

If you'd like to start playing with my code I welcome you to join my Google Code Project: Sierra ECG Tools. I am also working on a C implementation, and likely an Android implementation. Stay tuned, and apologies for the technical post.

The author has no financial ties to Philips Healthcare and received no compensation for this work.

EKG Myth - Ventricular tachycardia must have concordance

2011-12-06T16:20:00.001-05:00

This is part of a series of posts detailing common electrocardiogram myths.

Myth: Ventricular Tachycardia must have precordial concordance

When differentiating a regular, wide-complex tachycardia some will look for precordial concordance to rule-in, or more importantly to rule-out ventricular tachycardia.

The absence of precordial concordance is not a reliable method of ruling out ventricular tachycardia:

Although the specificity of concordance for VT is high (>90%), the sensitivity is low (~20%)¹.

It is generally thought that positive concordance indicates a posteriobasal left ventricular origin and negative concordance indicates an anterioapical left ventricular origin. However, in the case of positive concordance, SVT with a left-posterior accessory pathway is a known cause.

Until recently, negative concordance has been thought to be "virtually diagnostic" of ventricular tachycardia². Multiple case reports have shown that certain configurations of accessory pathways can also cause negative concordance^3,4,5.

The key takeaway is while this criteria is a useful tool to rule-in ventricular tachycardia (i.e. high specificity), it is not a useful tool to rule-out ventricular tachycardia (i.e. low sensitivity).

Ventricular tachycardia without precordial concordance⁶.

WPW and Atrial flutter with positive concordance⁷.

While positive or negative concordance may strongly suggest ventricular tachycardia, providers should not rule-out ventricular tachycardia in its absence.

Pellegrini CN, Scheinman MM. Clinical management of ventricular tachycardia. Curr Probl Cardiol. 2010; 35(9):453-504. [PubMed]
Goldberger ZD, Rho RW, Page RL. Approach to the Diagnosis and Initial Management of the Stable Adult Patient With a Wide Complex Tachycardia. Am J Cardiol. 2008; 101:1456-1466. [Full Text]
Pappas LK, et al. Wide QRS complex supraventricular tachycardia with negative precordial concordance. Am Heart Hosp J. 2009; 7(1):67-8. [PubMed]
Kappos KG, et al. Wide QRS Complex tachycardia with a negative concordance pattern in the precordial leads: Are the ECG criteria always reliable? Pacing Clin Electrophys. 2006; 29:63-6. [PubMed]
Volders PGA, et al. Wide QRS complex tachycardia with negative precordial concordance: Always a ventricular origin? J Cardio Electro. 2003; 14:109-111. [PubMed]
Garmel GM. Wide Complex Tachycardias: Understanding this Complex Condition Part 1 - Epidemiology and Electrophysiology. W J Emerg Med. 2008; 9(1):28-39. [Full Text]
Ibid. 1, Figure 3.

EKG Myth - "It's Too Fast for Ventricular Tachycardia"

2011-11-17T06:56:00.001-05:00

This is part of a series of posts detailing common electrocardiogram myths.

Myth: Rate can help you rule out Ventricular Tachycardia

When differentiating a regular, wide-complex tachycardia some will look at the rate to rule out ventricular tachycardia. Studies have not found rate to be a predictive finding¹.

...regarding ventricular rate, significant overlap unfortunately exists between VT and SVT such that rate is not a helpful criterion to differentiate origins².

Ventricular tachycardia technically can range in rates from 100 bpm through 300 bpm. However, a practical definition of VT would place the lower bound around 120 bpm and the upper bound around 260 bpm³.

Common terminology includes rates slower than 120 as "Slow Ventricular Tachycardia", which most often is not true VT⁴. Rates upwards of 260 to 300 bpm are commonly termed "Ventricular Flutter"⁵.

As a rule: a regular, wide-complex tachycardia should be treated as ventricular tachycardia in the field, until proven otherwise.

Griffith MJ, et al. Multivariate analysis to simplify the differential diagnosis of broad complex tachycardia. Br Heart J (1991); 66:166-74. [PubMed]
Hudson KB, et al. Electrocardiographic Manifestations: Ventricular Tachycardia. J Emerg Med (2003); 25:303-314. [PubMed]
Surawicz B, Knilans TK. Chou's Electrocardiography in Clinical Practice: Adult and Pediatric, 6th ed. Philadelphia, PA. Saunders, 2008.
Mattu A. ECG PEARLS: Beware the Slow Mimics of Ventricular Tachycardia. Emergency Physicians Monthly, 24 August 2010. Retrieved Online 8 November 2011. [Free Full Text]
Gurevitz O, et al. Long-term prognosis of inducible ventricular flutter: not an innocent finding. Am Heart J (2004); 147(4):649-54. [PubMed]

Zebra Spotting

2011-06-22T19:31:00.000-04:00

I'm sure we all received the following good advice at some point in our EMS education or careers:

"When you hear hoofbeats, think horses not zebras."

I propose we add the corollary:

"...but if you don't stay to watch, you won't know what you missed."

Remember, always err on the side of the patient.

An attempt at Video Education: Axis Determination

2011-05-23T09:36:00.001-04:00

I'm a huge fan of the Kahn Academy and regularly watch his videos when I have a question about something in mathematics. Usually it only takes five or so minutes into the video for me to recall how to accomplish the task, and I can move along. I've always wanted to see if I could do the same thing for ECG interpretation.

So here is my inaugural attempt; rapid axis determination using leads I and aVF (assuming you're ok with a ±5° difference):

Conclusion to 54 year old female CC: BLS intercept

2011-04-06T11:29:00.001-04:00

As many readers noted, there is a lot of baseline wander. This is not the most helpful of 12-Leads. On scene the crew attempted multiple 12-Leads, however, the patient would not sit still and that was the best one.

I think a close look at the Initial 12-Lead has enough information to make a field diagnosis.

Read the rest at EMS 12-Lead Blog: 54 year old female CC: BLS intercept - Conclusion!

New Case Study at EMS 12-Lead Blog

2011-04-05T12:51:00.000-04:00

My first case study as an associate editor is up at the EMS 12-Lead Blog, so check it out: 54 year old female cc: BLS Intercept:

"It is just after 3am when you are called to intercept a BLS unit on scene with a 54 year old female with a low heart rate.

Upon your arrival, you find two EMT-Basics attending to a small woman lying in bed, who appears acutely ill..."

Also, I've done a brief review of atrioventricular blocks to help with identification of the rhythm in this case study!

Enjoy.

Unrecognized Limb Lead Misplacement?

2011-03-10T18:54:00.001-05:00

Dr. Smith's ECG Blog has a new case up, "Reperfusion through collaterals associated with nitroglycerin, lateral MI with reciprocal T-wave inversion in lead III," with a pretty stark change in the initial 12-Leads. However, I have a hunch the stark change was really a change in the limb lead positions!

ECG 1 and ECG 2: Limb Leads Only

Look at leads I and II, notice how they "swap" positions between the two 12-Leads. Now look at aVL and aVF, notice how the "swap" positions too. Now take a look at lead III. It goes from inverted P's and T's with a Qr complex, to upright P's and T's with a Rs complex.

I propose that this change is due to a simple reversal of two leads. If we take a look at our friend Einthoven's Triangle (we covered this in a previous post on the S5 Lead) we can see that this makes sense!

LA/LL Swap: Einthoven's Triangle is "Flipped"

We can see that Lead I is actually looking at Lead II and Lead II is actually looking at Lead I; confirmed with ECG's 1 and 2. Lead III becomes an inverted Lead III; confirmed again in the original ECG's. This looks like a case of an unrecognized left arm and left leg lead reversal.

What I find most interesting is if you compare every ECG except the first, it appears to be a case with subtle posteriolateral changes that may have been missed had there not been the lead reversal!

Highlighting Atrial Activity on an ECG: The S5 Lead

2011-02-28T19:06:00.001-05:00

Kelly Grayson, of A Day in the Life of an Ambulance Driver fame, posted an article on EMS1.com over a year ago entitled The Leads Less Traveled. In this he touched on modified chest leads (MCL1 through MCL6), right precordial leads (V4R), and the S5 Lead.

Update: after posting this I have since learned it is also known as the Lewis Lead, after Sir Thomas Lewis¹, and have included a link to an article detailing how it was derived.

I had never heard of the S5 Lead before and promptly forgot about it until yesterday, when I finished acquiring 12-Leads for my limb lead reversal project. I went ahead and captured a rhythm strip from myself using the S5 lead placement.

S5 Leads: monitoring Leads I and II.

Before we cover the S5 Leads, let's recap normal lead placement and our friend, Einthoven's Triangle. This produces convenient ECGs with positive waveforms along the usual mean vector of the heart. Lead I points to 0°, Lead II points to 60°, and Lead III points to 120°.

Our friend, Einthoven's Triangle.

Additionally, the electrodes themselves are placed out on the limbs which generally results in waveforms proportional to the myocardium involved. Atrial activity is shown as well, but considering the proportion of myocardium involved in atrial depolarization, this configuration is not always useful in finding P-waves.

Normal Placement: Leads I and II from the same patient.

Now let's introduce the S5 Lead. You can produce this using many variations of the electrodes, however, for simplicity's sake we will stick with Kelly's description:

Place the Right Arm electrode on the patient's manubrium.
Place the Left Arm electrode on the 5th intercostal space, right sternal border.
Place the Left Leg electrode on the right lower costal margin.
Monitor Lead I.

Maximal atrial activity monitoring Lead I, S5 Lead configuration.

Notice the change in the direction of each lead. Lead I now points to the usual mean vector of atrial depolarization. Lead II and lead III are nearly perpendicular to the usual mean vector of ventricular depolarization. What does this mean for the electrocardiographer? If you remember that a vector which travels towards a lead is positive and perpendicular to a lead is isoelectric the answer is easy: atrial activity is highlighted, ventricular activity is diminished.

S5: Lead I

S5: Lead II

The new direction Lead I points in is not quite perpendicular to the mean vector and it is also closer to the ventricular depolarization, hence we still have clear ventricular activity. However, the direction and location of Lead I is right in front of the atrial depolarization wavefront, giving clear P-waves. Lead II shows a large P-wave and small, nearly isoelectric ventricular activity.

If I can remember, I will try and acquire S5 Leads in the field. Has anyone else used the S5 Lead? Are there any other interesting lead configurations we should use?

Bakker, ALM, et al. The Lewis Lead: Making Recognition of P Waves Easy During Wide QRS Complex Tachycardia. Circ (2009); 119:e592-e593. [Free Full Text]

Limb Lead Reversal: Preliminary Findings

2011-02-14T14:46:00.000-05:00

Back in January, Tom over at the EMS 12-Lead blog had an interesting case entitled "Bait and Switch" in which the diagnosis of a STEMI was potentially masked due to incorrect limb lead placement. Interestingly, the limb lead placement was not one of classic LA/RA reversal, but rather a "rotation" of the limb leads. In this instance, the cardiac monitor did not detect the incorrect limb lead positioning. Over the last few weeks I have set out to collect 12-Lead ECGs acquired from each of the 24 possible limb lead positions and to catalog the characteristics of each.

All of the ECGs I have acquired are on LifePak 12 monitors using the GE Marquette 12SL algorithm. Currently, only classic limb lead reversal has produced the, "*** Suspect arm lead reversal, interpretation assumes no reversal," message. However, I still have 12 combinations of lead placements to complete.

Here are 3 ECG's acquired from a healthy male subject without any known cardiac abnormality or history (i.e. me).

Normal ECG **Unconfirmed**; Normal Sinus Rhythm

Abnormal ECG **Unconfirmed**; *** Suspect arm lead reversal, interpretation assumes no reversal; Normal sinus rhythm; Right axis deviation; Nonspecific ST abnormality.

Abnormal ECG **Unconfirmed**; Unusual P-axis, possible ectopic atrial rhythm; Left axis deviation; ST & T wave abnormality, consider inferior ischemia

Harvard's ECG Wave Maven

2010-12-21T10:52:00.001-05:00

I am constantly searching for resources which let me hone my electrocardiography skills and would like to share a gem I discovered a few months ago. Harvard's School of Medicine and the Beth Israel Deaconess Medical Center has an excellent resource: ECG Wave Maven: Self-Assessment Program for Students and Clinicians. You can browse their cases as a quiz or for reference, and each case includes high resolution ECGs for your inspection.

I've found their difficulty ratings to be pretty accurate, and I've found that Level 3 or less (of 5 difficulty levels) are all ECG findings that Paramedics should be able to recognize.

Nathanson L A, McClennen S, Safran C, Goldberger AL. ECG Wave-Maven: Self-Assessment Program for Students and Clinicians. http://ecg.bidmc.harvard.edu.

I encourage all of you to go spend a few ~~hours~~days at the site brushing up on your ECG interpretation skills, your patients deserve it!

A quick look at Pulmonary Embolisms

2010-12-20T17:08:00.000-05:00

Acute pulmonary embolism (PE) is believed to affect anywhere from 1 in 250 to 1 in 1000 persons in the US each year. Potentially 1 in 10 patients with an acute pulmonary embolism may go into cardiac arrest within the first 60 minutes[1].

The working diagnosis of a PE in the field is likely to be based solely on clinical findings. Therefore, prehospital providers should be familiar with the most common physical findings:

Tachycardia
Tachypnea
Dyspnea
Persistently low SaO2
Recent history of syncope
Hypotension
Cyanosis or pallor
Diaphoresis
Hemoptysis
Low grade fever
Diminished lung sounds

Additionally, prehospital providers should be familiar with the common ECG findings in acute pulmonary embolisms (in order of prevalence):

Sinus tachycardia (73%)
Prominent S1 (73%)
"Clock-wise" rotation (56%)
Negative T in 2+ precordials (50%)
Incomplete or complete RBBB (20-68%)
P-pulmonale (28-33%)
Axis shift, generally RAD (23-30%)
No significant findings (20-24%)
S1Q3T3 (12-25%)
Supraventricular arrhythmias (12%)

Note that 1 in 5 patients are likely to have no significant ECG findings. What this should stress is the field diagnosis of a PE will lean heavily on your clinical assessment and findings. Chou[2] notes that in one study only 5 patients of 64 were diagnosed with a PE based on ECG findings.

A combination of any of these physical and electrocardiographic findings strongly favor PE and prehospital providers should act accordingly. Unrecognized pulmonary embolisms may be rapidly fatal.

References

Galvagno SM. Emergency Pathophysiology: Clinical Applications for Prehospital Care. Teton New Media (2003). [ISBN 1591610079]
Surawics B, Knilans TK, Chou TC. Chou's Electrocardiography in Clinical Practice: Adult and Pediatric. Saunders/Elsevier (2008), 6th ed. [ISBN 1416037748]

Pediatric Intranasal Fentanyl

2010-12-03T13:49:00.000-05:00

Scenario
It's a summer afternoon and you're dispatched to a 9 year old male patient involved in an ATV accident. The nearest ALS engine company has been dispatched as well. Upon your arrival you find an ATV on its side, another ATV upright, and a crowd gathered on the porch of a nearby house. A paramedic from the engine is assessing a distraught young boy, sitting in his mother's lap, holding an obviously deformed right forearm. The officer on the engine informs you that the boy and his father were riding alongside the road, traveling at 20-30 miles per hour, when the boy lost control and was thrown from the ATV (his father insists he was wearing his helmet).

You introduce yourself to the child, assuring him you're here to help, and ask him what happened. The boy states that when he fell he put his arms out and he heard a loud pop when his right hand hit the ground. He denies passing out or any other injuries but says his arm, "really hurts". He reluctantly allows you to assess his radial pulse in the affected arm, which is rapid but easily palpable. There appears to be distal involvement of both the radius and ulna, however he does not tolerate any further assessment of the arm and screams if there is any movement. The remainder of your physical exam reveals only minor abrasions to exposed skin. The engine company reports tachypnea, tachycardia, and a normal blood pressure.

Discussion
It appears the child has suffered a Colles' Fracture of the right distal forearm. Appropriate treatment would include splinting, ice packs, and pharmacologic pain control. However, given the current state of the patient, it may not be possible to splint the extremity due to anxiety and pain. Traditional prehospital pain management would require intravenous access or intramuscular administration. Both of these routes are likely to cause increased anxiety in this patient, which is best avoided.

Pain management in the pre-hospital setting is fraught with problems. Most studies have found poor provider perception of pain, underutilization of analgesics, and a hesitance to treat pediatric pain (Thomas; Greenwald). Often times, studies find that even if patients are provided analgesia, they do not feel their pain was managed adequately at all (Thomas). For pediatric patients, this problem is compounded as pre-hospital providers are often wary to provide pain management or may be unable to obtain invasive IV access to provide pain management (Greenwald). Moreover, pre-hospital providers are often placed in situations where access to patients is limited to provide pain-management, often times resulting in painful patient movements.

The addition of a noninvasive means of pain management would be an invaluable aid to pre-hospital providers and would remove a potential barrier to care. In pediatric populations, the importance of noninvasive pain management procedures is easy to grasp, as this patient population is often unable to comprehend the benefits of initially painful procedures. Improvements in "time to analgesia" will likely lead to and have a direct, positive impact on patient care and satisfaction.

Efficacy and Safety of Intranasal Fentanyl
The efficacy and safety of intranasal fentanyl (INF) has been the focus of multiple studies, both in-hospital and pre-hospital. Finn et al conducted an in-hospital randomized double-blind placebo controlled trial and found INF to have the same efficacy as oral morphine during procedural wound care in adult burn patients (n=26, 35.5 ± 12.4 years). The concentration of INF used in this study was 50 µg/mL, initial dosages of 1.48 ± 0.57 µg/kg, and no difference in the number of adverse events. Finn et al concluded that while patients receiving INF were more satisfied with their level of pain relief (p = 0.009) that overall only half of the patients in the trial reported they were "satisfied" or "very satisfied".

In a randomized, controlled, open-label study of pre-hospital INF versus IV morphine, Rickard et al found no significant difference in efficacy or safety (n=258, 42.3 ± 13.7 years). This study differs from Finn et al in that there were a multitude of chief complaints treated due to an "all-comers" design. Moreover, the doses used of INF was significantly higher at 180 µg divided evenly between the nares with up to two repeat dosages of 60 µg. Patients in the INF group received pain medication earlier than in the IV morphine group, likely owing to the simpler route of administration. Adverse effects were noted to occur more frequently in the INF group (relative risk 2.09, 95% CI 0.92-4.78, p = 0.07), however, the Rickard et al was not powered to adequately detect any statistical difference. One incidence of a significant adverse effect required a termination of the INF protocol, but it was unclear from the study if this was related to the treatment or the patient's condition. Rickard et al concluded that given the safety and efficacy of INF, it is a valuable option in patients where intravenous access is "undesirable or impossible".

Borland et al 2005 and Borland et al 2007 were inpatient randomized double-blind crossover studies evaluating the efficacy and safety of INF versus oral or IV morphine, respectively, in pediatric patients. Borland et al 2005 studied INF in pediatric burn patients requiring daily dressing changes and found no significant difference in outcomes (n=24, median 4.5 IQR 1.8-9.0 years). The INF dosage was calculated against the bioavailability of the IN route (listed as 70%) with 1.4 µg/kg fentanyl equating to an IV dosage of 1 µg/kg. There were no incidents of significant adverse events, although this was likely due to the study size. However, sedation scores recorded found that INF patients recovered earlier than their oral morphine counterparts. Overall, Borland et al 2005 found INF to be safe and efficacious, but more importantly well tolerated by pediatric patients.

Borland et al 2007 found INF to be comparable to intravenous morphine in pediatric patients presenting to the emergency department with acute long-bone fractures (n=67, 10.9 ± 2.4 years). The median total dose was 1.7 µg/kg fentanyl with repeat doses given PRN. The impetus of the study was to find alternative methods of analgesia to intravenous narcotics in the pediatric population. The study authors note that given the comparable efficacy, INF is invaluable as a means to decrease "time to analgesia" in the pediatric population with potential for pre-hospital adoption.

Mudd conducted a systematic review of the available literature for INF in the pediatric population and graded 12 studies with evidence qualities of four Level I/A, one II/A, two II/B, one III/A, and four at III/B. There was a wide variation in dosing of INF amongst the studies, with a common range of 1-2 µg/kg fentanyl. Differences in concentrations existed as well, owing to the fact that in the US fentanyl is commonly available at 50 µg/mL and is used IV/IM/IO/IN yet overseas it is often given IN with a more concentrated 100-150 µg/mL solution. No differences in significance in pain reduction were found between concentrations, only in the volume of medication delivered. While no studies found a significant difference in adverse effects, many studies had small sample sizes and no long-term studies have been completed on the action of fentanyl on the nasal mucosa. However, the evidence in the reviewed studies demonstrated three clear points: (1) that INF is as efficacious as IV/IM/PO morphine or IV fentanyl, (2) it has no difference in adverse effects, and (3) it decreases the time to analgesia administration and pain relief.

Intranasal Fentanyl Protocol
Based on the research available and the existing 2009 NC EMS protocols, an appropriate pain management protocol for the administration of intranasal fentanyl is given below:

Adult patients with indications for narcotic analgesia for whom intravenous access is not feasible, not available, or at the discretion of the lead Paramedic, an initial dose of 50-75 µg fentanyl may be delivered intranasally. The total volume to be administered should be divided equally between the two nares (not to exceed 1mL per nare).
- If intravenous access is not available, repeat with 25 µg fentanyl delivered intranasally every 20 minutes to a maximum total dose of 200 µg.
Pediatric patients with indications for narcotic analgesia an initial dose of 1-2 µg/kg fentanyl up to a total dose of 50 µg may be delivered intranasally. The total volume to be administered should be divided equally between the two nares (not to exceed 0.5mL per nare).
- In order to decrease the anxiety of pediatric patients requiring analgesia and invasive procedures (such as intravenous access), it may be prudent to begin with intranasal fentanyl.

References

M. Borland, I. Jacobs and I. Rogers, Options in prehospital analgesia, Emerg Med (Freemantle) 14 (2002), pp. 77–84.
M. Borland, I. Jacobs and G. Geelhoed, Intranasal fentanyl reduces acute pain in children in the emergency department: a safety and efficacy study, Emerg Med (Freemantle) 14 (2002), pp. 275–280.
J. Finn, J. Wright, J. Fong, E. Mackenzie, F. Wood, G. Leslie and A. Gelavis, A randomized crossover trial of patient controlled intranasal fentanyl and oral morphine for procedural wound care in adult patients with burns, Burns 30 (3) (2004), pp. 262–268.
M. Borland, R. Bergesio and E.M. Pascoe et al., Intranasal fentanyl is an equivalent analgesic to oral morphine in paediatric burns patients for dressing changes: a randomised double blind crossover study, Burns 31 (2005), pp. 831–837.
M. Borland, I. Jacob and B. King et al., A randomized controlled trial comparing intranasal fentanyl to intravenous morphine for managing acute pain in the emergency department, Ann Emerg Med 49 (2007), pp. 335–340.
C. Rickard, P. O’Meara, M. McGrail, et al., A randomized controlled trial of intranasal fentanyl vs intravenous morphine for analgesia in the prehospital setting, Amer J Emerg Med 25 (2007), pp. 911-917.
S. Thomas, S. Shewakramani, Prehospital Trauma Analgesia, J Emerg Med 35 (2007), pp. 47-57.
M. Greenwald, Analgesia for the Pediatric Trauma Patient: Primum Non Nocere? Clin Pedi Emerg Med 11 (2010), pp. 28-40.
S. Mudd, Intranasal Fentanyl for Pain Management in Pediatrics: A Review of the Literature, J Pedi Health Care (2010), Article in Press. doi:10.1016/j.pedhc.2010.04.011.

One Year: Thank You

2010-10-22T18:33:00.000-04:00

One year has passed since I received my EMT-Paramedic, and I'd like to say thank you.

Firstly, to my friends and family. You have endured my absence well, or at least have hid your anger well. I'm sure this last year has been tough, but probably not as tough as paramedic school. I really could not do this job without your support, especially as a volunteer. I cannot say it enough, thank you.

To my colleagues and peers, you have surely challenged me to accomplish things I never knew I was capable of doing. You have mentored me, scolded me, and sat patiently while I fumbled with IVs. There is an entire network of you online which have been invaluable as a sounding board and a reference. I can only hope I will continue to take what you have given me and make myself a better Paramedic going forward. The fact that I feel like my feet are underneath me at all is a testament to you all, thank you.

Lastly, to my patients of whom I've met quite a few: you have taught me more than I could ever hope to tell you. Some of you were thrust into my arms, others I knelt and said goodbye. You have challenged me to better myself and I appreciate every experience. My life as a green Paramedic has been an odd mix of on-the-job training for emergencies I was never told about and connecting the dots for those I was told every day about. I thank you for your understanding. I hope that I can tell a story of that time I sat next to you on a flight, and heard about your trip to see your niece get married. That is why I am here, you are why I am here. I feel blessed to meet each and every one of you, thank you.

2010 AHA CPR/ECC Guidelines

2010-10-18T15:30:00.001-04:00

If you haven't already heard, today the AHA released the 2010 edition of their CPR/ECC Guidelines which include updates for laypersons, BLS, ACLS, PALS, and neonatal resuscitation. If you've been following resuscitation research at all for the last few years, there are not many surprises.

Compressions trump ventilations in adult patients (C-A-B not A-B-C).
Minimize interruptions in the "flow" of a resuscitation, that is, continuous compressions are to be minimally interrupted.
ETCO2 is to be preferred over manual pulse checks: if you don't have a rise in ETCO2 to physiologic or near-physiologic levels, you probably do not have a perfusing rhythm.
AEDs are indicated for all ages, including infants and neonates, provided there are pads available which fit without overlap (>3cm gap).
Pharmacologic therapy has the same weight as TCP in certain bradyarrhythmias.
Procainamide is now first-line or at least recommended on par with Amiodarone, Lidocaine is almost off the list.
Atropine is no longer recommended during routine PEA/Asystole resuscitations.
Studies into neonatal resuscitation have shown that deep suctioning is not required in vigorously born neonates with meconium staining.
Routine use of naloxone in cardiac arrest secondary to opioid overdose is not recommended.

There were many other differences, including the addition of circular flowcharts documenting the new guidelines (linear flowcharts are still provided). I encourage everyone to read them.

Edit: here is a document (PDF) comparing the AHA 2005 CPR/ECC guidelines to the 2010 guidelines.

How many Automated External Defibrillators are at your place of work?

2010-09-13T16:59:00.001-04:00

Our Industrial Fire Brigade just added 10 more AEDs to our site. By my rough calculations this means we have 1 AED for every 150 employees and 1 AED for every 80,000 sqft of floor space (we have almost 2 million sqft). To put this in perspective, the recommendations generally are for 1 AED per 100,000-150,000 sqft or building floor. We now have an AED and emergency responders within 2 minutes of every employee on site!

The Philips HeartStart FRx is a great first responder AED as this author has learned through personal experience.

How does your place of work stack up? Do you need help with corporate/management buy-in? Perhaps our site's successes can help you out. Let me know!

12-Lead ECG: What Is It?

2010-09-07T14:59:00.002-04:00

While cleaning up my office to put in a reading chair, I found the following 12-Lead ECGs from my clinical time. I apologize for the poor quality of the first one, but it is a copy of a copy (of probably a copy). I have limited information on the patients for each of them somewhere in my clinical binder, but I haven't found those yet.

ECG 1

ECG 2

What do these two 12-Leads show?

Do you agree with the computerized statements?

Update on ECG 1 (16 Sept 2010)

The patient's lab values include a K+ of 2.1 mEq/L. What are some of the expected ECG changes in hypokalemia? Does this ECG show a classical or atypical presentation of hypokalemia?

Pediatric Transcutaneous Pacing

2010-08-23T17:28:00.004-04:00

Being out of school only recently, I'm often asked "book" questions which are likely to be fresh in my mind. One of these that had me stumped was simply, "what is the appropriate current settings for pediatric transcutaneous pacing?"

I had no answer.

Honestly I had no idea, but assumed it would be weight based, and along the lines of the PALS guidelines for defibrillation. However, when I researched this topic in my PALS book I found there were no answers for pediatric pacing [1]. In fact, there was little mention of TCP whatsoever! Going over to ACLS I found no answers for current settings in adults, just when it was indicated [2].

However, in Paramedic school we had been taught the appropriate current ranges for TCP in adults, which ranged from 20-200 mA. Zoll et al found that most adults responded to TCP in the range of 40-70 mA, however, some required currents up to the device maximum of 140 mA [3]. After a few hours of searching for guidelines specific to pediatrics (including the Philips, Physio-Control, and Zoll websites), I came across a study on TCP in pediatrics which focused on the current required for different electrode sizes. Much to my amazement, the current settings required for external transcutaneous pacing of pediatrics are the same as for an adult!

A total of 56 pacing trials were conducted, 53 of which were successful in obtaining capture. A mean output of 63 +/- 14 mA (range, 42-98) at threshold using the large electrodes was comparable to published adult requirements. Béland MJ et al [4]

How could this be, wouldn't a smaller heart need less energy?

It seemed paradoxical at first, but reviewing the anatomy and physiology of a myocyte with an emphasis on the physics aspect puts it into perspective [5]. Each myocyte in the heart is a part of what amounts to an big electromechanical pump. Given a sufficient input stimulus a myocyte contracts and forwards a stimulus to its neighbors, which follow suit, leading to the eventual coordination of systole and diastole.

The goal of any artificial cardiac pacemaker, whether internal or external, is to act as the primary input stimulus by applying a current to an area of the heart which exceeds the stimulation threshold, i.e. the current required to cause a response from the myocardium.

Therefore, transcutaneous cardiac pacemakers attempt to exceed the stimulation threshold of a single area. It would be hard to achieve coordinated ventricular activity if the current was too high, instead you would have defibrillation. It stands to reason that if the only threshold required to overcome is the stimulation threshold of a single area of the myocardium, the weight of the heart--generalized as the weight of the patient--would be irrelevant.

In contrast, the goal of defibrillation is to bring all electrical activity in the heart to a halt. Defibrillation is not successful unless the all of the reentrant activations of ventricular fibrillation are stopped. Therefore the therapeutic energy levels are going to be proportional to the amount of myocardium you are acting on. Hence, pediatric defibrillation energy dosages are weight based.

So what seemed counterintuitive at first, is actually fairly logical. Pediatric transcutaneous cardiac pacing has the same energy requirements as adults because myocardium has the same stimulation threshold regardless of age. This deduction is supported in the literature as well:

No correlation has been defined between transcutaneous pacing threshholds and age, body weight, body surface area, chest diameter, cardiac drug therapy, or etiology of underlying heart disease. [6]

So there we have it, transcutaneous cardiac pacing current setting ranges are universal amongst our patient population. Below is a guideline I've created as a supplement to the material contained within PALS:

Pediatric Transcutaneous Cardiac Pacing
Symptomatic bradycardia in the pediatric population is most often related to hypoxia secondary to respiratory etiologies. In rare situations it may exist in spite of adequate ventilation and oxygenation. Given the presence of a high degree heart blocks, or symptomatic bradycardia refractory to aggressive BLS and ALS treatments, transcutaneous cardiac pacing should be initiated without delay.

Indications
High degree heart blocks
Symptomatic bradycardia refractory to ventilation, oxygenation, chest compressions, and pharmacological treatments

Contraindications
The only contraindication of TCP is an inability to place the pads on the patient without overlap or sufficient distance between them.

Side Effects
The side effects of TCP are most frequently muscle activation and associated pain. These are dose dependent effects which are a combination of the current delivered, size of the pads, location of the pads, and width (time) of the delivered pulse [7].

To minimize these side effects use the largest available pads, placing them in an Apical-Posterior fashion. While larger pads require higher current outputs, there is a decrease in the current delivered per surface area reducing the side effects associated with TCP.

Often, management of these side effects is achieved through concurrent pharmacological treatment with analgesics and/or sedatives.

Dose
Pediatric transcutaneous cardiac pacing (TCP) is defined by two dosing parameters: output current and rate. This guideline assumes the pacemaker is in fixed mode.

Output Current
As with adult patients, the output current for pediatric transcutaneous cardiac pacing should begin at 20 mA (or the lowest setting available) and increase in 5-10 mA increments until electromechanical capture is obtained. Additionally, the current may be increased an additional 5-10 mA above the determined threshold to ensure continued capture. If the device maximum output current is reached and no electromechanical capture exists, discontinue TCP and troubleshoot. Attempt an alternative pad placement (anterio-apical or anterior-posterior) and ensure the negative pad is on the anterior aspect of the chest. If capture is still not obtained, resume CPR and obtain expert consultation.

Output Rate
In contrast to adult patients, the output rate for pediatric transcutaneous cardiac pacing is age based. The final output rate should be titrated to an adequate systolic blood pressure to resolve perfusion problems, e.g. an improvement in mental status. Care should be taken to avoid tachycardic rates or hypertension. Consult a length-based resuscitation tape (e.g. Broselow™ tape) for appropriate starting output rates and systolic blood pressure. An example table is given below, adapted from the North Carolina 2009 EMS Standards [8]:

Age Rate (bpm) Systolic BP (mmHg)
0-3 mo 120-150 85 (+/-25)
3-6 mo 120-130 90 (+/-30)
7-10 mo 120 96 (+/-25)
11-18 mo 110-120 100 (+/-30)
19-35 mo 110-120 100 (+/-20)
3-4 yr 100-110 100 (+/-20)
5-6 yr 100 100 (+/-15)
7-9 yr 90-100 105 (+/-15)
10-12 yr 80-90 115 (+/-20)
>12 yr 70-80 120 (+/-20)

Age	Rate (bpm)	Systolic BP (mmHg)
0-3 mo	120-150	85 (+/-25)
3-6 mo	120-130	90 (+/-30)
7-10 mo	120	96 (+/-25)
11-18 mo	110-120	100 (+/-30)
19-35 mo	110-120	100 (+/-20)
3-4 yr	100-110	100 (+/-20)
5-6 yr	100	100 (+/-15)
7-9 yr	90-100	105 (+/-15)
10-12 yr	80-90	115 (+/-20)
>12 yr	70-80	120 (+/-20)

References

Hands-Only CPR

2010-07-28T18:34:00.000-04:00

Now@NEJM just posted an article detailing the results of two new studies on Hands-Only or Compressions-Only CPR or Cardiocerebral Resuscitation (CCR). These studies[1,2] look very promising, in fact they showed no appreciable difference in overall survival-to-discharge for traditional CPR versus CCR. Moreover, when one of the studies, by Rea et al[1], compared using CCR to CPR survival-to-discharge of cardiac arrest victims of a primary cardiac etiology there was an increase from 12.3% to 15.5%, although it was not statistically significant. However, when comparing CCR to CPR to non-cardiac etiologies, there was a higher percentage of survivability in the CPR group (7.2% vs. 5.0%), although this as well was not statistically significant.

So what does this mean?

The researchers in Rea et al[1] note that while there was no statistically significant difference between the two, there was a clinically significant trend towards higher survival-to-discharge numbers using compressions alone. Additionally, 80.5% (n=981) of callers given compressions-only instructions began compressions versus 72.7% (n=960) given traditional CPR instructions. Overall 76.7% (n=1941) of callers began either CCR or CPR, which means 1 in 4 callers declined to perform some form of resuscitation.

Taking a closer look at the efficacy of the caller instructions, there is a nearly 8% increase in initiation of compressions under compressions-only instructions. Applying that increase to the CPR-instructions group would have meant nearly 75 more patients would have received compressions! Potentially another 9 people could have gone home from the hospital. Rea et al went as far as saying this was a clinically significant difference, but we all know how big of a difference it makes having just one more person walk home.

So what should we do?

I think progressive systems with tight integration between first responders, EMS, and dispatch need to get the Hands-Only word out to the public. Start using Hands-Only dispatch instructions along with an aggressive public information campaign. I feel in just a 60-90 second TV advertisement, Hands-Only CPR could be demonstrated to the public effectively. You could even throw in your favorite prime time TV cast to really capture those eyeballs.

I've not been in EMS very long, but my heart sinks every time I walk into a house and there has been no attempt at CPR. Our response times are often in the 8-9 minute range which means most of our attempts are futile. I understand the psychological barriers are high, but we need something to improve the rates of bystander CPR. If these studies have shown one thing, it is that Hands-Only CPR has a good chance of doing just that.

References
1. Rea TD, et al. CPR with Chest Compression Alone or With Rescue Breathing. N Engl J Med 2010; 363: 423-433. [at nejm.org]
Conclusions: Dispatcher instruction consisting of chest compression alone did not increase the survival rate overall, although there was a trend toward better outcomes in key clinical subgroups. The results support a strategy for CPR performed by laypersons that emphasizes chest compression and minimizes the role of rescue breathing.

2. Svensson L, et al. Compression-Only CPR or Standard CPR in Out-of-Hospital Cardiac Arrest. N Engl J Med 2010; 363: 434-442. [at nejm.org]
Conclusions: This prospective, randomized study showed no significant difference with respect to survival at 30 days between instructions given by an emergency medical dispatcher, before the arrival of EMS personnel, for compression-only CPR and instructions for standard CPR in patients with suspected, witnessed, out-of-hospital cardiac arrest.

Morphine Equivalents Visualized

2010-07-20T15:34:00.000-04:00

My day job involves the creation of visualization software to help engineers evaluate complex systems. In my last post detailing Morphine Equivalents there was math, and numbers, and eyes glazing. So, as an aide to the previous post I submit to you a graph of the three narcotic dosing schedules. I pulled the half-lives from Wikipedia and assumed a bioavailability of 100% for the IV route.

The half-lives used are:

Morphine: 2-3 hours
Fentanyl: 2-4 hours
Dilaudid: 2-3 hours

Morphine Equivalents

2010-07-06T13:29:00.002-04:00

A pretty hot topic lately has been prehospital pain control and how for the most part it is viewed as a failure. Granted, the perception of how well prehospital providers handle pain control is not what I'm looking to talk about, Rogue Medic and the bloggers at Paramedicine 101 have touched on this topic quite a number of times.

What I'd like to do is add a little math to the discussion. Over at Street Watch: Notes of a Paramedic there is an excellent post about a new study on Fentanyl versus Morphine combined with a more liberal pain control protocol. The protocol mentioned "Morphine Equivalents," something of which I was only tangentially aware.

"Morphine Equivalents" are basically a unit of measure used to compare the efficacy of opiods. After a trivial amount of Googling I came across an easy to follow guide from the University of Alberta's Multidisciplinary Pain Centre which listed conversion factors between various opiods. Using these conversion factors, we could compare how equivalent various pain control protocols are.

In North Carolina our 2009 EMS protocols allow 3 opiods for the treatment of pain: dilaudid, morphine, and fentanyl. Per the conversion guide, these drugs compare as follows:

1 mg of Fentanyl is equivalent to 100 mg of Morphine
1 mg of Dilaudid is equivalent to 5 mg of Morphine

So let's examine the 2009 NC Protocols for Pain Control:

Morphine: 4 mg IM/IV/IO bolus, may repeat with 2 mg every 3-5 minutes to a max 10 mg or clinical improvement
Fentanyl: 50-75 mcg IM/IV/IO bolus, may repeat with 25 mcg every 20-30 minutes to a max 200 mcg or clinical improvement
Dilaudid: 1-2 mg IM/IV/IO bolus, may repeat with 1 mg every 20-30 minutes to a max 5 mg or clinical improvement

Now let's do the conversion to Morphine Equivalents (MSeqv hereafter):

Fentanyl: 5-7.5 MSeqv bolus, may repeat with 2.5 MSeqv every 20-30 minutes to a max 20 MSeqv
Dilaudid: 5-10 MSeqv bolus, may repeat with 5 MSeqv every 20-30 minutes to a max 25 MSeqv

Both the Fentanyl and Dilaudid protocols allow for a higher loading dose in Morphine Equivalents. They both offer a much higher maximum dosage as well. However, if we look at the rebolus schedule they compare poorly to Morphine. Fentanyl's maintenance schedule is 5x weaker, and Dilaudid's is 2.5x weaker than the equivalent Morphine schedule.

Moreover, when you compare the amount of Morphine Equivalents per minute allowed by the protocol, assuming you had the maximum time required to deliver each medication, you find both Fentanyl and Dilaudid compare poorly to Morphine:

Morphine: 0.8 MSeqv/minute (max reached in 12 minutes)
Fentanyl: 0.2 MSeqv/minute (max reached in 120 minutes)
Dilaudid: 0.3 MSeqv/minute (max reached in 80 minutes)

Take this with a huge grain of salt, because this mathematical comparison does not take into account bioavailability, half-life, side effects, rate of administration, and probably a whole host of other important factors. However, what this comparison does show is that while pain control protocols have improved and prehospital providers have options, they aren't all necessarily equal!

Updated 20 July 2010: For a visual representation of their "strength of schedule" see Morphine Equivalents Visualized.

Something for my tag line

2010-06-09T19:55:00.000-04:00

"...and sometimes you get to shake someone's hand."

It's a great feeling.

Question about my Job Description

2010-05-28T09:09:00.002-04:00

"Paramedics are not there to determine what is or isn't a life and death situation."

I must have missed something in paramedic school.

Improving BLS to ALS Patient Handoff in Cardiac Arrest

2010-02-22T17:57:00.005-05:00

One of the benefits of my software engineering job is access to a large corpus of journals through ScienceDirect. About once a month I pick a topic and pull the latest research. This month I did a journal search for "paramedic" AND 2010 which returned many interesting articles. One that particularly piqued my interest was Berdowski J, et al: Delaying a shock after takeover from the automated external defibrillator by paramedics is associated with decreased survival [1]. The authors found that if the paramedics switched from using the AED to their monitor and a shock was delayed, for whatever reason, there was a decrease in patient survivability to admission.

Currently I work for two services in two different counties, one is a BLS industrial fire brigade and the other is an ALS combined Fire/EMS department. Both services have AEDs for their BLS providers with pads that are interchangeable with the monitors predominantly carried by the ALS units in their respective counties (Philips in one, Physio in the other). The standardization on pads obviously makes BLS to ALS patient handoff simpler during cardiac arrest. However, I had not considered at what point in resuscitation would be the most appropriate to make the pad switch.

As the research showed, in nearly two thirds of the cases where a switch from the AED to the ALS monitor was made, the delivery of an appropriate shock was delayed. Barring equipment or operator malfunction, an AED and a paramedic are both going to defibrillate the same rhythms. Paramedics can still place the patient on their monitor with a 3-Lead even if they have not changed the pads over. The study authors conclude that the appropriate time to switch the pads would be after the AED delivers a shock or advises that no shock should be delivered.

Schematic timeframe of the ALS takeover period (Berdowski J, et al)

The mechanics of a patient handoff from a BLS unit to an ALS unit during cardiac arrest are not something touched on in paramedic school or ACLS [2]. The handling of compressions versus defibrillation is rightfully stressed, but this appears to have missed another factor critical to patient survival. In retrospect this factor is obvious and thankfully easily correctable perhaps simply through recognition. ACLS classes geared towards pre-hospital providers can add this into scenarios used for testing and EMS protocols can include:

Minimize interruptions in compressions or appropriate defibrillation delivery by first responders when initiating ALS treatments in cardiac arrest.

This minor change is low hanging fruit compared to the benefit to our patients!

References

Berdowski J, et al: Delaying a shock after takeover from the automated external defibrillator by paramedics is associated with decreased survival. Resuscitation 2010; 81: 287-292.
American Heart Association: 2005 American Heart Association Guidelines for Cardiopulmonary Resuscitation and Emergency Cardiovascular Care Part 5: Electrical Therapies - Automated External Defibrillators, Defibrillation, Cardioversion, and Pacing. Circulation 2005; 112: IV-35 – IV-46.

Common and Uncommon Usages of Glucagon in the Field (Part 2)

2010-02-15T15:33:00.010-05:00

In the pre-hospital setting, Glucagon primarily plays a role in the management of hypoglycemic patients. Emergency Medical Technicians carry Glucagon as an alternative or adjunctive therapy to dextrose administration for these patients. However, this is not the only usage of Glucagon in the field. Many ALS protocols include Glucagon in the treatment of symptomatic bradycardia for patients who have overdosed on β-blockers or are refractory to standard ACLS treatments. As we will find, there are a number of alternative usages of Glucagon which could be considered in the field under online medical direction.

This is a continuation of a two part series: Part 1 contains the pharmacodynamics and common clinical applications of Glucagon.

Uncommon Clinical Applications of Glucagon

Steakhouse syndrome
Refractory anaphylaxis
Severe asthma (little support)
Refractory CHF (little support)

Steakhouse Syndrome

Steakhouse syndrome, otherwise known as an esophageal food bolus obstruction, is a medical emergency occurring when a foreign body becomes stuck in the esophagus either due to spasms, strictures, or rings. Standard treatment includes endoscopy, digestive enzymes (such as papain), or Glucagon. An interesting property of Glucagon is that it can overcome smooth muscle spasms of the lower esophagus and lower esophageal sphincter pressures. Glucagon has been used in various radiological studies since the 1970s and its hypotonic effects on the esophagus are well documented.

Usage in the ED began formalization in the 1990s with studies on determining an effective treatment protocol. The most common protocol begins with fluoroscopy studies to determine the extent of the obstruction. Next, the patient is laid supine and 1 mg of Glucagon is given over 1 minute via IV push (to lessen the chance of nausea and vomiting). Finally, the patient is sat upright and encouraged to drink 200 cc of water and an effervescent solution. The combination of Glucagon’s spasmolytic effects, the hydrostatic pressure of the column of water, and the esophageal dilation secondary to the effervescence is very successful at passing obstructions.

In the field, patients will present with an inability to swallow, excessive salivation, drooling, and will probably be distressed. If prompt medical attention is not sought, aspiration, esophageal rupture or perforation may occur. A trial of 1 mg Glucagon slow IVP under medical direction may be an effective means of terminating any spasms and passing the obstruction. Glucagon could also be considered in the case of a recent clearing of a foreign body airway or esophageal obstruction with excessive coughing or spasms. Unfortunately the use of Glucagon in the field to treat true esophageal food bolus obstructions is limited by an inability to conduct radiological studies, so unless transport times are long or the EMS system rural, safe and expeditious transport should not be delayed.

Refractory Anaphylaxis

Prompt recognition and management of anaphylactic shock is constantly stressed in EMS education as it is both rapidly fatal and reversible. Treatment protocols include epinephrine, antihistamines, corticosteroids, inhaled β2-agonists, and aggressive fluid resuscitation. However, in certain patient populations the use of epinephrine may not be desired or outright contraindicated. Additionally, some patients may just not respond to β-adrenergic stimulation. Due to its orthogonal cardiovascular mechanism of action, Glucagon is an appropriate choice as supplemental treatment in these patients.

In the field, dosages for Glucagon in refractory anaphylaxis should begin at 1 mg IV every 5 minutes as needed. If the patient has a known β-blockade or is refractory to epinephrine, doses as high as 3-5 mg may be required. If hypotension continues in spite of aggressive fluid resuscitation, a maintenance infusion of 1-5 mg/hr should be started, titrated to effect. As discussed in β-blocker overdoses, most ALS units do not carry enough Glucagon for prolonged treatment and additional units should be requested for an intercept. As before, safe and expeditious transport to an ED should not be delayed for treatment with Glucagon.

Severe Asthma

Treatment of asthma in the field is relatively straightforward, involving nebulized β2-agonists and parasympatholytics, IM sympathomimetics, and IV corticosteroids. However, if a patient has a β-blockade or is in status asthmaticus, the condition may be so severe that standard treatments are not effective on their own. Studies were conducted in the late 1980s and early 1990s on the use of IV and nebulized Glucagon for the adjunctive treatment of bronchospasm. They showed that the smooth muscle relaxation of Glucagon, which is independent of β-adrenergic pathways, provides some clinical benefit when compared against using β2-agonists alone. Current clinical guidelines for the management of asthma note that "last ditch" treatments such as magnesium sulfate or Glucagon have little support in the literature and may even be harmful. However, Glucagon has been shown to be safe even if the additive benefit is negligible.

In the field, patients presenting with severe asthma or status asthmaticus should be treated aggressively using current protocols. Albuterol, ipratropium, epinephrine, and corticosteroids should all be administered prior to the consideration of "last ditch" treatments such as Glucagon. Dosages for Glucagon in severe asthma vary based on the route of administration; 1-2 mg slow IV push or 2 mg nebulized have been shown to be effective in small studies in addition to aggressive β2-agonist treatment. Do not delay safe and expeditious transport or definitive airway management in a decompensating asthmatic.

Refractory CHF

In a patient with acute Congestive Heart Failure, if they are refractory to inotropes Glucagon can be considered as a potential treatment. Studies conducted in the 1960s and 1970s showed promise for Glucagon as a supportive agent in CHF, but only for NYHA Class I and Class II heart failure. Recent studies, however, do not show strong for a support for Glucagon in CHF, reserving its usage for refractory shock states. Dosages in the field of Glucagon for refractory CHF should be 0.01-0.05 mg/kg IV bolus with a maintenance infusion of 1-3mg/hr. The paucity of literature in support of Glucagon for CHF relegates this treatment to a last ditch effort with close medical direction.

Conclusion

Glucagon is one of the most common items in an ALS drug box and as the literature shows surprisingly versatile. Beyond its hyperglycemic effects, Glucagon is a positive inotropic and chronotropic agent. This oft overlooked mechanism of action arms pre-hospital providers with new treatments without adding additional medications. While medical control will be required for nearly all of the alternate indications, both rural and urban providers can make more informed treatment choices for their patients especially when the standard treatments fail.

Potential Utility of Glucagon in the Field

Hypoglycemia: Adults: 1 mg SQ, IM, IV; 2 mg IN. Peds: 0.5 mg SQ, IM, IV; 1 mg IN. Neonates: 50 mcg/kg SQ, IV. (should accompany glucose resuscitation)
Symptomatic bradycardia secondary to β-blocker overdose: 10 mg IV bolus, 1-5 mg/hr maintenance infusion. (should supplement standard treatment)
Symptomatic bradycardia secondary to Ca-channel blocker overdose: 2-10 mg IV bolus; consider maintenance infusion. (should supplement standard treatment)
Steakhouse syndrome: 1 mg SQ, IM, IV, may repeat.
Refractory anaphylaxis: 1 mg IV q 5 min; consider 3-5 mg IV; consider maintenance infusion. (should supplement standard treatment)
Severe asthma: 1-2 mg IV; 1-2 mg nebulized. (paucity of literature to support this use)
Refractory CHF: 0.01-0.05 mg/kg IV bolus, 1-3 mg/hr maintenance infusion. (paucity of literature to support this use)

References

Pollock CV: Utility of Glucagon in the Emergency Department. J Emerg Med 1993; 11: 195-205.
Rosenfalck AM, et al: Nasal glucagon in the treatment of hypoglycaemia in type 1 (insulin-dependent) diabetic patients. Diabetes Research and Clinical Practice 1992; 17: 43-50.
Love JN, Howell JM: Glucagon Therapy in the Treatment of Symptomatic Bradycardia. Ann Emerg Med January 1997; 29:181-183.
American Heart Association. Part 7.3: Management of Symptomatic Bradycardia and Tachycardia. Circulation 2005; 112; IV-67-IV-77.
Stadler J, et al: The "steakhouse syndrome". Primary and definitive diagnosis and therapy. Surg Endosc 1989; 3(4):195-8.
Glauser J, et al: Intravenous Glucagon in the Management of Esophageal Food Obstruction. JACEP June 1979; 8: 228-231.
Handal KA, Riordan WM, Siese J: The lower esophagus and glucagon. Ann Emerg Med November 1980; 9: 577-579.
Galvagno, Samuel M. (2003). Emergency Pathophysiology: Clinical Applications for Prehospital Care (pp. 195-200). Jackson, Wyoming: Teton NewMedia.
Lieberman MD, et al: The diagnosis and management of anaphylaxis: An updated practice parameter. J Allergy Clin Immunol 115 (2005); 3: S483-S523.
Gavalas M, Sadana A, Metcalf S: Guidelines for the management of anaphylaxis in the emergency department. J Accid Emerg Med 1998; 15: 96-98.
Compton J: Use of glucagon in intractable allergic reactions and as an alternative to epinephrine: An interesting case review. J Emerg Nurs 1997; 23: 45-7.
Wilson JE, Nelson RN: Glucagon as a Therapeutic Agent in the Treatment of Asthma. J Emerg Med 1990; 8: 127-130.
Melanson SW, Bofante G, Heller MB: Nebulized Glucagon in the Treatment of Bronchospasm in Asthmatic Patients. Am J Emerg Med 1998; 16: 272-275.
Marik PE, Varon J, Fromm R: The Management of Acute Severe Asthma. J Emerg Med 2002; 23: 257-268.

Common and Uncommon Usages of Glucagon in the Field (Part 1)

2010-02-08T15:21:00.017-05:00

In the pre-hospital setting, Glucagon primarily plays a role in the management of hypoglycemic patients. Emergency Medical Technicians carry Glucagon as an alternative or adjunctive therapy to dextrose administration in these patients. However, this is not the only usage of Glucagon in the field. Many ALS protocols include Glucagon for the treatment of symptomatic bradycardia in patients who have overdosed on β-blockers or are refractory to standard ACLS treatments. As we will find, there are a number of alternative usages of Glucagon which could be considered in the field under online medical direction.

Common Clinical Applications of Glucagon

Hypoglycemia
Symptomatic bradycardia secondary to β-blocker overdose
Symptomatic bradycardia secondary to Ca-channel blocker overdose

Uncommon Clinical Applications of Glucagon

Steakhouse syndrome
Refractory anaphylaxis
Severe asthma (little support)
Refractory CHF (little support)

Pharmacology

Glucagon is a hormone produced by alpha cells in the islets of Langerhans of the pancreas. The primary effect of Glucagon is to promote the release of stored glucose in the liver and stimulate the release of insulin from the pancreas to promote uptake of glucose into the cells. Additional effects of Glucagon include a cascade of activations resulting in an increase of cyclic-AMP (cAMP). cAMP is an important intracellular messenger, responsible for carrying the signals of epinephrine and glucagon across the cell membrane. cAMP also regulates the flux of Ca2+ through ion channels independent of β-adrenergic receptors. This quality of Glucagon is what is thought to explain the various changes to the cardiovascular system seen after its administration.

In the field, Glucagon is commonly packaged as a powder which is reconstituted with either sterile water or D5W (5% dextrose in water) to give a final concentration of 1 mg in 1 cc. Glucagon can be administered intravenously (IV), intraosseously (IO), intramuscularly (IM), subcutaneously (SQ), or intranasally (IN). Glucagon is assigned to the pregnancy category B, therefore usage during pregnancy should be considered when the benefits outweigh the potential risks. The most common side effects are nausea and vomiting, thought to be associated with the rate of IV administration. When giving high doses of Glucagon, the usage of antiemetics such as ondansetron or promethazine should be considered. Additionally some diluents packaged with Glucagon contain phenol, which in high doses can be toxic. Therefore, reconstitution should be done in sterile water, D5W, or normal saline.

Hypoglycemia

As this article is intended for pre-hospital providers, it is assumed that the usage of Glucagon in hypoglycemia is well understood, therefore this indication will not be explored in depth. However, pre-hospital providers may be surprised to learn that the administration of 2 mg Glucagon intranasally (IN) was shown to be as safe and efficacious as an IM administration of 1 mg. Recently the administration of drugs through the IN route has gained in popularity, the most visible of those being naloxone (Narcan). In 2009, naloxone administration via the IN route was added to the scope of practice for all levels of EMTs in North Carolina, where this author practices.

Given the few side effects and complications associated with the administration of Glucagon, it would be a powerful addition to BLS providers for hypoglycemic patients in which oral glucose is not indicated. Yet the widespread adoption of intranasal Glucagon has not been seen in EMS, even though studies on intranasal Glucagon were conducted as far back as the 1980s. One potential explanation could be the relatively high cost of Glucagon. A casual and unscientific search of Internet distributors shows the average price of 1 mg Glucagon ranges from $70-150 USD. In comparison, naloxone ranges from $18-25 USD for the common pre-hospital packaging. Given the economic troubles in 2009 and 2010, it seems unlikely that the intranasal route will gain traction amongst already cash strapped BLS providers.

Symptomatic Bradycardia

Beyond hyperglycemic effects, Glucagon exerts both positive chronotropic and inotropic effects on the heart through non-adrenergic receptors. Because the cardiovascular actions are orthogonal to β-adrenergic receptors, it should be considered in any symptomatic bradycardia refractory to sympathomimetics or as an adjunct to sympathomimetic therapy. High-dose IV Glucagon has been shown to be effective when there is a known β-blocker or Ca-channel blocker overdose.

The first consideration for EMTs when using Glucagon for a patient with suspected β-blocker or Ca-channel blocker overdose is the extreme dosage to be administered. A loading dose of 2-10 mg is cited by the literature, followed by 1-5 mg/hr maintenance infusions titrated to effect if hypotension and bradycardia persist. The service at which the author works only carries two 1 mg Glucagon kits per ambulance, which is relatively common amongst ALS providers. Therefore, a second unit or ALS QRV should be requested for an intercept to supply additional Glucagon kits. This logistical concern obviates any on-scene treatment with Glucagon for symptomatic bradycardia, and should not delay safe and expeditious transport.

In part 2, we'll explore some less traditional usages of Glucagon in the field.

References

Pollock CV: Utility of Glucagon in the Emergency Department. J Emerg Med 1993; 11: 195-205.
Rosenfalck AM, et al: Nasal glucagon in the treatment of hypoglycaemia in type 1 (insulin-dependent) diabetic patients. Diabetes Research and Clinical Practice 1992; 17: 43-50.
Love JN, Howell JM: Glucagon Therapy in the Treatment of Symptomatic Bradycardia. Ann Emerg Med January 1997; 29:181-183.
American Heart Association. Part 7.3: Management of Symptomatic Bradycardia and Tachycardia. Circulation 2005; 112; IV-67-IV-77.

Bigeminy

2010-01-30T11:22:00.006-05:00

My last two shifts have included patient's with bigeminal premature ventricular contractions (PVC). Bigeminy is a condition where every other beat does not come from the primary pacemaker. In both cases my patients had sinus rhythm with bigeminal PVCs. One of the patient's had multifocal PVCs. The other had unifocal PVCs during the bigeminy, but had multifocal couplet PVCs later (I unfortunately did not get a strip with that). As you can imagine, those are some sick hearts.

My concern would be if the rate of perfusing beats is not high enough to support hemodynamics. Surprisingly, even though neither patient's PVCs were perfusing they were both stable with these rhythms, even though the perfusing rate was quite bradycardic. One of these was the patient's normal rhythm, and thankfully I was made aware of this before I treated a problem that did not exist!

60yo F C/C Abdominal Pain

55yo M C/B SOB w/ exertion

TFS and Baseless Merging

2010-01-19T13:54:00.002-05:00

Whoever thought it was a good idea to not allow sane branching and merging and introduced in its stead "baseless merges," should probably never work on a source control project again.

I'm now relegated to losing all sorts of history in order to stage complex feature branches by just using .patch files. Thanks for wasting my afternoon. Yet another reason to use TRAC/SVN instead of TFS.

Passed NREMT-P!

2009-12-16T14:25:00.002-05:00

I'm finally done with every certification I need. Seriously the alphabet soup I've taken seemed to never end! Thanks again to everyone who has helped, I wouldn't be here without all of the support.

Code Review Find

2009-12-11T13:24:00.002-05:00

double PIE = 3.141592654;

No, that code did not pass the review.

Passed!

2009-10-26T16:26:00.004-04:00

I passed the North Carolina EMT-Paramedic exam! It has been three years since I started my journey into EMS, one I would recommend to anyone looking for a rewarding and challenging volunteering field. Thanks to all the folks online who've helped me along the way with Cardiology, I wouldn't have scored 100% on rhythms without you guys.

Update: my certification went active today. So I'm officially a North Carolina EMT-Paramedic.

Long Time no Post

2009-09-28T11:12:00.004-04:00

Tuesday marks the end of my initial education as a Paramedic. In preparation I have been studying with books, exam preparations, notes, other students, etc. I will say however, that there is one common thread between the practice exams: bogus questions.

These are questions which make no attempt to assess critical thinking or evaluate knowledge in a certain area, they attempt solely to trick the student. After enough of these trick questions, the student becomes ingrained in finding the catch. Answering the questions becomes a game and not a test of ones knowledge. For instance (not an actual question, just an example):

A patient complaining of cephalgia would most likely:

Have a headache

Have an ear ache

Have clubbed fingers

Be a dick

If you answered, "have a headache," congratulations, you know useless medical trivia and probably have little clinical skills. If you answered, "be a dick," you possess a high degree of critical thinking skills. What patient in the world is going to complain about "cephalgia", unless they're a raging...well, you know what.

If the question asked, "which of the following symptoms would be cause for concern in a patient with an acute onset of hypertension," and "Headache (cephalgia)" was the answer, the question would not only test clinical knowledge, but teach the student a (useless) medical term for a headache. If the answer was given only as cephalgia, then the question would test for nothing.

Update: I passed my paramedic final and will take the North Carolina EMT-Paramedic exam October 23rd. I hope to complete the National Registry testing in November.

Replacing Invalid Characters v. Performance

2009-07-13T12:38:00.004-04:00

It appears a large amount of StackOverflow posts focus on eeking out an impossible amount of performance for rather mundane tasks. Sometimes, when you read the question, you can't help but wonder why they even want to improve the performance of the given algorithm. The odds are most performance enhancements would come at the expense of readability. However, that does not mean it isn't worth taking a look at--especially if you're bored and don't want to do something else.

I had some fun with the following question: Most efficient way to remove special characters from string. Just from looking at the specification given, my guess is this is going to get called maybe 100 times at the most. O(f(n)) where n is 100 is boring. Even more interesting is that the given solution from the poster is already quite good (barring a logic error). Here is the OP's solution without any logical errors:

public static string RemoveSpecialCharacters(string str)
{
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < str.Length; ++i)
    {
        if ((str[i] >= '0' && str[i] <= '9')
            || (str[i] >= 'A' && str[i] <= 'Z')
            || (str[i] >= 'a' && str[i] <= 'z')
            || (str[i] == '.' || str[i] == '_'))
            sb.Append(str[i]);
    }
    return sb.ToString();
}

As a frequent code reviewer, I think this method looks great. In fact, running this method against a corpus of 10000 randomly generated lines with 4096 characters executes in 0.0479ms/string. This is very fast. The simplest improvement would be to prefill the StringBuilder to str.Length characters. This results in a new runtime of 0.0442ms/string. Now we're cooking with gas!

A few posters suggested regular expressions. Well, the naive approach (uncompiled) takes 0.489ms/string which is 10 times slower. Making the regular expression compiled takes 0.363ms/string, still 8 times slower. However, take a look at the new code you must maintain:

static Regex replacer = new Regex(@"[^a-zA-Z0-9_.]+", RegexOptions.Compiled);
public static string RemoveSpecialCharacters(string str)
{
    return replacer.Replace(str, String.Empty);
}

Ok, so a big drop in performance, but perhaps a big gain in readability and maintainability. However, the OP's algorithm is surely very simple to read. So the regular expressions make sense if this method is going to be called a few times on small strings.

Another suggestion was to use foreach rather than a for-loop. This results in another minor speedup to 0.0412ms/string. The last of the improvements suggested was to go with a lookup table. Personally it is my least favorite because it will be less readable and maintainable. C# 3.0 can help us some, using LINQ to improve those.

static bool[] allowedChars = new List<bool>(
    from ii in Enumerable.Range(0, 128)
    let c = (char)ii
    select (c >= '0' && c <= '9')
        || (c >= 'A' && c <= 'Z')
        || (c >= 'a' && c <= 'z')
        || (c == '.')
        || (c == '_')
).ToArray();

public static string RemoveSpecialCharacters(string str)
{
    StringBuilder sb = new StringBuilder(str.Length);
    for (int ii = 0; ii < str.Length; ++ii)
    {
       if (str[ii] < allowedChars.Length && allowedChars[str[ii]])
           sb.Append(str[ii]);
    }
    return sb.ToString();
}

Take a look at how many extra lines of code we have added. This solution may be the fastest so far, at 0.0399ms/string, but it is also bordering on the ugliest. However, we haven't even touched on the simplest improvement that can be made which results in the largest absolute increase in performance. If you replace the StringBuilder with a char[] a 100% speedup can be achieved!

public static string RemoveSpecialCharacters(string str)
{
    int idx = 0;
    char[] chars = new char[str.Length];
    foreach (char c in str)
    {
        if ((c >= '0' && c <= '9')
            || (c >= 'A' && c <= 'Z') 
            || (c >= 'a' && c <= 'z') 
            || (c == '.') || (c == '_'))
        {
            chars[idx++] = c;
        }
    }
    return new string(chars, 0, idx);
}

This method runs in a blazing 0.0299ms/string, is simple to read, is easy to maintain, and is highly performant. We have a winner folks.

Shortness of Breath x 2 days

2009-04-07T16:38:00.005-04:00

Age, circumstance, and anything else I feel like has been changed.

This unit was dispatched to a 76yo M C/C SOB x2 days. Pt found seated in chair, w/ patent airway, no obvious respiratory distress, and no apparent life threatening airway. Pt states concern for pneumonia. Pt denies CP. Rhonchi bilateral lower lobes. HR 62, BP 128/70, RR 18, SaO2 97% r/a. Placed on O2 @ 2lpm via NC. SOB gradual w/o pain, worse with exertion, better with rest, "can't catch breath." Pt has no PMD, denies any prior PMD visits, no meds, NKDA. Pt seated fowlers on stretcher, seatbelts secured, taken via stretcher to ambulance. 3-lead monitor shows sinus brady, frequent PVCs, ST elev II/III. 12L ECG shows 2mm ST elev II/III/aVF w/ reciprocal changes I/aVL, ST depression V2-V5. Pt vital signs unchanged, denies CP. Feels "better" w/ O2. 4x 81mg ASA PO. Code STEMI alert given to receiving hospital, no questions. Care transferred to Cath Lab, written and verbal report given to receiving nurse.

We got to watch the cath lab at work:

RCA: right marginal artery occlusion
LAD: diagonal artery occlusion
CX: complete circumflex occlusion

No stents placed, scheduled for CABG.

A Difference in Education

2009-03-24T15:11:00.004-04:00

You learn interesting things about yourself based on why you miss questions on a test. For instance, on Monday night it became apparent that I have the biochemistry education of a lower order ape. I can speak in big medical terms, but fundamentally my understanding is along the lines of, "air goes in and out, blood goes round and round."

This isn't necessarily a bad thing, my degree is in computer science. So as a programmer, I find that my understanding is based on my rough implementations in code rather than the actual biochemical mechanisms. This is useful in terms of my own understanding, but hardly common ground with other students.

I think I need to take some biochemistry courses so I'm not dragging my knuckles on the floor of the ambulance.

Exceptions and Constructors

2009-03-03T10:51:00.003-05:00

You should never include any work in a constructor which may leave the object in an inconsistant state. Constructors should be atomic and consistant. You should avoid having side effects in a constructor. However, sometimes you cannot avoid doing additional work in a constructor.

For example, you are designing a stream like class which acquires an unmanaged resource in the constructor. Following RAII, you implement the necessary logic to clean up your unmanaged resource in Dispose and Finalize. Given the following pseudo-code, what is a possible error condition we are not current designed to handle:

public MyType()
{
    Check.Invariant(argumentInvariant1);
    // ...
    Check.Invariant(argumentInvariantN);

    // 1. ACQUIRE
    this.AcquireUnmanagedResource();

    // 2. Set up our base properties from the resource
    this.RetrieveConfiguration();
}

~MyType()
{
    this.Dispose(false);
}

public void Dispose()
{
    this.Dispose(true);
    GC.SupressFinalize(this);
}

private void Dispose(bool disposing)
{
    if (!this.isDisposed)
    {
        // RELEASE
        this.ReleaseUnmanagedResource();

        if (disposing)
        {
            this.DisposeManagedResources();
        }
    }
}

What would happen if #2 threw an exception? Well, it is more obvious in this example than in most code in the wild, but our Dispose or Finalize will not be called! Our unmanaged resource will not be released, and we will be leaked.

An appropriate solution would, perhaps, be the following modification to the constructor:

public MyType()
{
    Check.Invariant(argumentInvariant1);
    // ...
    Check.Invariant(argumentInvariantN);

    try
    {
        // 1. ACQUIRE
        this.AcquireUnmanagedResource();

        // 2. Set up our base properties from the resource
        this.RetrieveConfiguration();
    }
    catch(Exception)
    {
        // RELEASE
        this.Dispose(true);

        throw; // propagate the exception
    }
}

Now, if #2 should fail we will release the unmanaged resource and not leak anything. Keep in mind this will require a Dispose method which is resistant to an inconsistant object state. However, the design contract for IDisposable basically requires this anyways.

Basics and Paramedics

2009-02-17T10:13:00.003-05:00

Recently I was asked what the difference was between an EMT-Basic and a Paramedic. It is simple, Basics have the ground beneath their feet, four walls around them, and a roof above their head. More importantly to the Basic, and to their patient, is the door. Behind this door is a Paramedic. A Paramedic who doesn't know if they are on the ground or falling to meet the ground. They really only have the walls they've put up around them. At least at this point, I can't fathom the ceiling for a Paramedic. The responsibilities and expectations are limitless when looking through the door at the Basic.

C# XML Documentation Guide

2009-02-16T09:55:00.003-05:00

Today I found what is perhaps the most comprehensive guide to writing good C# XML Documentation. Many thanks to the Dynicity guys for producing this.

Self-inflicted, unintentional GSW

2009-02-07T15:31:00.006-05:00

You can imagine the thought process associated with being dispatched to your first gun shot wound. The narrative has been altered to change specificity and situation.

This unit was dispatched to a 32yo male w/ self-inflicted unintentional GSW x1 to the hand. Additional information from caller while en route informed pt conscious and alert. Dispatch notified LEO, en route. Arrived on scene to find two bystanders in an open field. Pt found sitting in passenger seat of van with ~5cm hole in the front windshield. No gun visible. LEO arrived ~2 min after EMS, secured .40cal handgun. Pt states he reached for the handgun on the floorboard of the van and it went off accidentally. Pt had a patent airway, no respiratory distress, and displayed his L hand which had no apparent active bleeding. Rapid trauma exam revealed no life threatening injuries. <5cc blood estimated lost. L hand had ~1cm entrance wound on anterior palmar aspect ~3cm from medial border and ~2cm from wrist. ~1cm exit wound on medial border ~3cm from entrance and ~4cm from wrist. Powder burns noted at entrance wound. Skin warm/dry, pupils sluggish, pulse fast/bounding. Pt refused further physical examination. Wound irrigated with sterile water, bandaged, wrapped with gauze. Pt refused further treatment. Pt refused transport. Pt advised of treatment/transport options and injury severity. Pt signed refusal. LEO witnessed refusal.

Paramedic Clinicals

2009-01-18T11:46:00.003-05:00

So Friday was the first of many clinical shifts (500 hours total) I will be doing as a Paramedic student. My patients ranged in age from 11 to 92, with problems ranging from fractures to overdoses to a suspected DVT. I triaged patients, assessed vitals, started IV's, pushed medications, wiped asses, and did everything else I could find to do.

One aspect of our clinical time is a state requirement that we accomplish a given number of procedures. This is both a good and a bad thing. You want your certified Paramedics to be useful when they get their card. You also want your new Paramedics to be more than just some monkey starting your IV. But when you take those requirements and add to it a finite amount of patients and a finite amount of clinical time, an obvious problem is created. Any economist will tell you that the students will apply game theory to patient care, asking the question, "what interventions can I use," rather than, "what interventions, if any, are appropriate".

More players enter the game when you show your preceptor the clinical guidelines which include these requirements. Suddenly, you have a proxy, rummaging through charts looking for flags indicating a required intervention! This isn't necessarily a bad thing, I obviously need to be competent at starting IV's, administering medication, birthing children, et cetera. I just should not be particularly concerned about only having 500 hours to accomplish X number of IV starts, Y medication administrations, Z child births, et cetera ad nauseam.

The state clinical requirements should make the student more concerned with the academic approach, starting with patient assessment and ending with a clear and organized treatment plan. It shouldn't matter if I'm the one providing any required interventions, just that I'm able to provide any appropriate intervention when required.

So you can see why I'd find it funny that my first IV stick as a medic student was a heavily tattooed habitual IV drug user requiring cardiac blood labs. He was nearly devoid of useful veins and definately required blood drawn. A disgustingly green paramedic student tends to fall towards the bottom of the list of people you'd like performing this procedure. But not being one to avoid a challenge, I tried to follow some scar tissue to what felt like a vein, but my angle of attack was too high and I nicked and rolled it.

Swiiing and a miss.

Even with a little extra traction and some fancy needle movement I couldn't establish a patent line. The patient wisely asked that the nurse try the next stick, due to that being the only vein we could find sans a vein running along his thumb. I'm sure the fact that my shirt said EMS Intern on it played no small role in his decision to ask that somebody else make the try.

My mind is still debating if there was more learned attempting his IV or reading his ECG.

California Supreme Court Redefines Good Samaritan

2008-12-22T10:24:00.003-05:00

I was fairly shocked to learn the normally reasonable California Supreme Court botch a case regarding Good Samaritan laws. An individual--who had been drinking and smoking marijuana--rendered aid at a motor vehicle accident pulling the driver from the allegedly smoking car. The driver suffered traumatic injuries to her liver, requiring surgery, and to her spine. Secondary to either the accident or the extrication, the driver suffered paraplegia and brought a negligence suit against the individual who had extricated her from the vehicle.

At trial, the original court agreed the defendant was covered under the Good Samaritan laws, as would be expected, however, on appeal this decision was overturned. The appeals court found that the statute covers only "emergency medical care" (ed: original emphasis) and not the actions taken by the defendant. Eventually the appeals reached the state supreme court, and the court found in favor of the plaintiff agreeing with the appeals court's finding that the care provided by the defendant--removing the plaintiff from her vehicle--was inconsistant with the language and intent of the applicable Good Samaritan statutes.

Huh?

Somehow, somewhere, the California Supreme Court has forgotten that removing your patient from harms way is the first step in patient care. Well okay, it comes after your safety, your partner's safety, and any bystander's safety (scene safe? BSI?). Still, if a patient is in a burning car, the first thing to do is remove the patient from the burning car. You cannot be expected to provide emergency medical care if the scene is not safe for you, your partner, or your patient. It stands to reason then, that the most fundamental form of Basic Life Support is removing your patient from danger.

What the California Supreme Court has done with their overly pedantic finding is to redefine a Good Samaritan and to change the rules of the game. The defendant in this case probably should be sued for negligence given all of the other facts in the case, however, they shouldn't be exempt from Good Samaritan laws merely because of a language technicality. People are already hesitant enough to provide bystander care with how lawsuit happy our society is, and now people in California have even less of a reason to provide care. Hopefully the legislature will iron this issue out in the new year.

Wound Care and Non-Adherent Dressings

2008-12-18T12:30:00.003-05:00

On our ambulance, the two least used forms of dressings are occlusive dressings and non-adherent dressings. It is easy to explain why we don't use occlusive dressings (ed: sucking chest wounds, while popular on ER, are NOT the mainstay of our site EMS), but it is a little bit harder to explain why we don't use non-adherent dressings often.

Typical wound care for an EMT-Basic consists of slapping a stack of 2x2, 3x3, or 4x4 gauze pads on the wound while applying direct pressure. If we have other things to do we'll ask the patient to hold the gauze, or tape it down. I can't ever recall ever using a non-adherent dressing or being asked for one; moreover, our wound care protocols do not give mention to them. Interestingly enough, before yesterday I probably would have been unable to give an indication for a non-adherent dressing without a little bit of thought.

Nothing could teach me the primary indication of a non-adherent dressing better than when I injured my knee yesterday. Just two small gouges, nothing big. I irrigated and debrided the wound, applied a 2x2" gauze, and secured the bandage with 1" cloth tape.

When I went to take a look at the wound that night, I was somewhat suprised to find the gauze had become part of the clot. I was even more supprised at the level of pain I was confronted with while removing the gauze-clot. The woven gauze had to be removed one strand at a time, even after applying warm water. It was at this point I had an epiphany.

My jump bag contains 4x4" non-adherent dressings that, surmising from their name, would not adhere to my wound like the gauze had. Sure enough, after cutting down the dressing to form a smaller 2x2" form, I applied the non-adherent dressing under a 2x2" gauze dressing, and taped the new and improved bandage down. Removal this morning was pain free, and further more I did not have to break any clots that had formed!

It only takes 5 seconds of googling to find that everyone from studies, to nurses, to patients emphatically support non-adherent dressings for wound care. Thanks to a personal lesson in pain, my own protocol for wound care will now include a non-adherent dressing for any wound (which will produce an exudate) upon which a dry sterile dressing will sit.

Studying Paramedicine as a Software Engineer

2008-11-09T14:35:00.009-05:00

Paramedic school has been grueling giving the concomitant (bordering on comorbid) factor of work. However, that will be my last complaint on that because as a general rule, when I want to do something, I go and do it. We've finished anatomy and physiology, pathophysiology, medicolegal concerns, various introductory topics, and most recently pharmocology.

We had to turn in cards on 72 drugs (of the 129 paramedics in NC could give), and I decided to make life easier for myself using a small program. LINQ-to-XML plus WPF (and some regular expressions to parse human readable dosages) allowed me to rapidly transcribe all of the useful information into an XML format. I then put together a quick XSLT file to make an OOXML file that I could print and paste to 3x5 index cards (ed: I left off side effects and had to add those by hand, wraaa!). Did I mention the program quizzes me on trade/generic names and pharmacological class? I'll try and release the quizzing features as a webpage at some point, however, my studies come first.

Right now we're having medical math beaten into us, which isn't particularly hard for those of us with strong mathematics backgrounds (ed: except when you suck at basic math). However, I noticed that many students had a hard time connecting the action of calculating a dosage with the mathematics to do the calculation. I put together a presentation to help bridge that gap, "Visualizing Medical Math" (PPTX). Hopefully this will help folks who are struggling with medical math.

(ed: for those of you without PowerPoint 2007 or access to a viewer, "Visualizing Medical Math" PDF).

Paramedic Student

2008-10-21T08:16:00.003-04:00

Last night I became a paramedic student. From now until October 2009, I'll be in class three nights a week and the occasional Saturday. There are just over 30 students in our class, with a 60-40 split of EMT-Intermediates and EMT-Basics. Three students from my EMT-Basic class returned to study paramedicine, and I'm looking forward to studying with them again.

We have homework right out the gate, which isn't suprising giving the pace of the course. I'll be posting the thousand word paper on EMS history, the future of EMS, and where I fit into it all on this blog. We also have to do cards on 129 drugs available to paramedics in the great state of North Carolina. Each card will have the generic name, trade name, mechanism of action, dosages (all dosage possibilities, adult and pediatric), indications, contraindications, and side effects. Interestingly enough, most services only carry a fraction of these for emergent care, and often only carry specialized subsets for acute care. Regardless, I'm looking forward to the pharmacology review.

So, look forward to seeing more postings on my time as a paramedic student, and maybe postings on my clinicals during the new year. I refrain from posting about people I treat at work only due to the "small town" feel at work. When out in the world, I'll probably be able to write in generality.

Fatal error LNK1171: unable to load c2.dll

2008-07-31T09:48:00.005-04:00

We had an interesting problem arise where linking a Release mode static library written in C with a Fortran application using the Premier Partner edition of Visual Studio that ships with Intel Visual FORTRAN 10 would die at the linking stage. This happened late in the game as the debug mode builds of the C library did not exhibit this error. To make matters worse, if users had any other version of Visual Studio with just the Intel Visual FORTRAN Compiler Integration installed, no such problems arose.

Our first step was to install the Platform SDK: no joy. The second step was to manually copy the DLL's required (there are actually 3 DLL's you need) from a working install to the non-working install: success!

So, what could possibly be the problem here?

No amount of searching could turn up the issue, so a ticket was opened with Intel's Premier Support. Well, we should have done this from the beginning because it appears that the compiler writers themselves know a lot about the compiler toolchain; fancy that. The (relevant) response from Intel:

c2.dll is used by the Microsoft Visual C++ compiler to perform whole-program optimization. Might it be that this "release" C library was compiled with that option? If so, you will require Visual C++ to be installed in order to build using that library.

My advice is that if you know you will be linking a C library on a system with only Visual Studio Premier Partner Edition installed that you be sure that Whole Program Optimization is disabled, as otherwise Fortran programmers will not be able to use it.

Sure enough, disabling Whole Program Optimization on the Release mode builds of the C static library solved all of our issues.

Day 14: Denali National Park

2008-07-16T18:38:00.003-04:00

We're 11 miles down Alaska Highway 3 (Parks Highway) at a school library. The weather is a bit bleh so we're unable to hike at the moment. We've now gone over 6500 miles on the road and are getting ready to make our return back to North Carolina. Here are some assorted photos from the park and our ascent of Mt. Healy (4500ft).

Day 13: Anchorage / Denali National Park

2008-07-15T13:52:00.002-04:00

So now we've been on the road for nearly two weeks, and are at our halfway point. We've been to Tok, Delta Junctions, Fairbanks, Palmer, Valdez, Glennallen, Anchorage, and Seward. We've hiked to some glaciers, camped near some glaciers, and are about to spend a few nights in Denali National Park. I don't really have much more time in front of this computer, so I'll just leave you with a picture from the beginning (Dawson Creek, BC, Canada) and the end of the Alaska Highway (Delta Junction, AK).

Day 8: Driving to Alaska

2008-07-10T13:33:00.002-04:00

So we're at a public library in Fort St. John, BC, Canada, checking our email, chatting it up with friends. We've been on the road for 8 days and have driven 3715 miles (5975 km). We've seen ten states and two Canadian provences.

Travel Log (subtract 1581 original miles for total distance)

Greenburg, IN - Odo 2292 miles - $4.129/gal - 15.153gal
Mt. Prospect, IL - Odo 2566 miles
Janesville, WI - Odo 2652 miles - $4.169/gal - 14.936gal
Oxford, WI - Odo 2746 miles
King Island, MN - Odo 2985 miles - $3.919/gal - 13.225gal
Little Falls, MN - Odo 3064 miles
Fargo, ND - Odo 3237 miles - $3.899/gal - 10.289gal (10% ethanol)
Jamestown, ND - Odo 3328 miles
Dickenson, ND - Odo 3501 miles - $4.149/gal - 12.717gal
Medroa, ND - Odo 3567 miles
Miles City, MT - Odo 3747 miles - $4.099/gal - 12.349gal
Livingston, MT - Odo 4002 miles
Big Timber, MT - Odo 4033 miles - $4.099/gal - 18.438gal (85.5 octane, 5gal spare)
Ackley Lake State Park, MT - Odo 4143 miles
Great Falls, MT - Odo 42131 miles - $4.099/gal - 8.158gal
Calgary, AB, Canada - Odo 4570 miles (7355 km) - CAD1.379/L - 51.793L
Lake Louise, AB, Canada - Odo 4673 miles (7520 km)
Drayton Valley, AB, Canada - Odo 4897 miles (7881 km) - CAD1.349/L - 49.314L
Dawson Creek, BC, Canada - Odo 5239 miles (8431 km) - CAD1.419/L - 56.675L (10% ethanol)
Kiskatinaw, BC, Canada - Odo 5259 miles (8464 km)
Fort St. John, BC, Canada - Odo 5296 miles (8523 km)

Next time I'll post it will probably be in Fairbanks, AK on the 13th.

Destination Alaska

2008-07-03T17:01:00.005-04:00

So yesterday my youngest brother and I started our drive to Alaska. 10,200 miles in total, we've gone just over 500 on our first leg. We're in West Virginia with our other brother and his fiancée, both Marshall students. Tomorrow we are headed to Chicago for the fourth and a beach party. My new car is getting about 25mpg while it is still getting broken in. I'll keep a log going of the miles driven, gas consumed, and prices per gallon whenever I get the chance.

Itinerary

03 July - Huntington, WV
04 July - Chicago, IL
05 July - Oxford, WI and Little Falls, MN
06 July - Medora, ND
07 July - Great Falls, MT
08 July - Banff, AB Canada
When I figure out the rest I'll let you know!

Travel Log

Wilmington, NC - Odo 1581 miles - Gas $3.979 - 8.958gal
Cary, NC - Odo 1715 miles
Wytheville, VA - Odo 1907 miles - $3.899 - 13.658gal
Huntington, WV - Odo 2084 miles

Wilderness EMT

2008-06-22T23:18:00.003-04:00

This last week was quite the week. I drove out to Sylva, NC to take a Wilderness EMT class--also known as the Wilderness Upgrade for Medical Professionals (WUMP)--at Landmark Learning. On the way I had to make a two hour diversion due to a serious wreck on I-40 at exit 355 which knocked off a piece of the overpass, backing up traffic for almost 10 miles! However, this did afford me the opportunity to take my new car through the mud to make a U-turn on the highway.

Anyways, the Wilderness EMT certification is administered through the Wilderness Medicine Institute of the National Outdoor Leadership School (WMI of NOLS). Landmark Learning is one of the partners of WMI that teaches the course. It was 6 days long, including two night classes. We covered every topic you would cover in your urban EMT-B class, just assuming you were out in the back country.

Without a doubt, the Wilderness EMT course was one of the most fun classes I have ever taken. Furthermore, I learned more in the last week than I ever did in 5 months of EMT school and my (now) 6 months of experience. Our two teachers, Justin and Jon, were perfect foils for one another. They were knowledgeable, hilarious, serious, and extremely competent teachers all at the same time. They taught the course as much outside and hands-on as we sat inside listening to lecture. The lecture was so interactive, nobody sat pounding nails or twiddling their thumbs. Justin and Jon fully expected that everybody in the room would participate, as we were all at least EMT-B's (and a PA) and should know the majority of the information. They just took what we knew and molded it into a back country way of thinking. This dynamic style of learning made for a truely amazing week and has made me a better (urban) EMT!

While Justin and Jon were the stars of the show there at Landmark Learning, enough can't be said for the interesting cast of people making up the student body. We had ex-special forces, current military, paramedics, a PA, fire fighters, current EMT's, and brand spankin' new EMT's. The brand spankin' new EMT's were fresh out of Landmark Learning's EMT Intensive program, where they spent 19 days at the campus getting fashioned into National Registry EMT-Basics. It is a testament to the amazing educational experience at Landmark to see a large number of them stay through the WEMT program and hold their own with more experienced medical professionals! Thanks also go to the other students for making six solid days of learning seem like the blink of an eye.

I feel well prepared for my drive to and from Alaska. I have a new car that will go the distance. My brother has his Wilderness First Aid certification (taught by J-Lo of Landmark), and I'm now a WEMT. I think all I need at this point is some experience hiking and camping...crap.

WPF Application Quality Guide v0.2

2008-05-12T11:09:00.004-04:00

Microsoft has released v0.2 of their WPF Application Quality Guide, which contains some great new items in the application testing section. They go over some interesting ways you can test a GUI application, including media sections of an application. I must say I hadn't thought about taking a screenshot of the desired result and then using an image differencing tool on the user's screenshot as a method of acceptance testing. That section definitely got me thinking on how to streamline our own GUI testing practices (read: nonexistent). I have cleaned up versions of their sample code, and if you'd like it just shoot me an email.

RE: NTDebugging Puzzler 0x00000003 (Matrix Edition) Some assembly required

2008-04-21T15:08:00.006-04:00

So the Microsoft Advanced Windows Debugging and Troubleshooting blog put out a puzzler based on reverse engineering assembler into something meaningful, say C/C++. I took a look at the assembly listing and decided it would be a fun break from work to decompile that into something. About 30 minutes later I wound up with some source that compiles down to nearly the same listing as theirs.

Phew, I've still got it! It took me some time monkeying around with the order of the local variables to get the same space added for the locals as in their example. Other than that it was pretty straight forward.

puzzler3.cpp

#include <stdlib.h>
#include <string.h>

/** Sort an input string's characters in descending order
*
*/
// puzzler3!myfun [c:\source\puzzler\puzzler3\puzzler3\puzzler3.cpp @ 20]:
void myfun(char* arg0)
// 20 00cc1480 55 push ebp
// 20 00cc1481 8bec mov ebp,esp
// 20 00cc1483 81ecf0000000 sub esp,0F0h
// 20 00cc1489 53 push ebx
// 20 00cc148a 56 push esi
// 20 00cc148b 57 push edi
{
//union { // [ebp-0F0h]
//   struct {
    size_t arg0_len;       // [ebp-08h]
//    unsigned int pad0;    // [ebp-0Ch]
//    unsigned int pad1;    // [ebp-10h]
    size_t ii;             // [ebp-14h]
//    unsigned int pad2;    // [ebp-18h]
//    unsigned int pad3;    // [ebp-1Ch]
    size_t len_temp;      // [ebp-20h]
//    unsigned int pad4;    // [ebp-24h]
//    unsigned int pad5;    // [ebp-28h]
    char x;                // [ebp-29h]
//   };
//   unsigned char local_variables[240];
//}; // local variables

// //set local variables to unusual values for buffer checking
//memset(local_variables,
//   0xCCCCCCCCU,
//   sizeof(local0)/sizeof(unsigned int)
//);  // 20 00cc148c 8dbd10ffffff lea edi,[ebp-0F0h]
  // 20 00cc1492 b93c000000 mov ecx,3Ch
  // 20 00cc1497 b8cccccccc mov eax,0CCCCCCCCh
  // 20 00cc149c f3ab rep stos dword ptr es:[edi]

len_temp = strlen(arg0); // 26 00cc149e 8b4508 mov eax,dword ptr [ebp+8]
  // 26 00cc14a1 50 push eax
  // 26 00cc14a2 e803fcffff call puzzler3!ILT+165(_strlen) (00cc10aa)
  // 26 00cc14a7 83c404 add esp,4
  // 26 00cc14aa 8945e0 mov dword ptr [ebp-20h],eax
  // 28 00cc14ad 8b45e0 mov eax,dword ptr [ebp-20h]
  // 28 00cc14b0 8945f8 mov dword ptr [ebp-8],eax

for(arg0_len = len_temp; arg0_len > 0; arg0_len--)
  // 28 00cc14b5 8b45f8 mov eax,dword ptr [ebp-8]
  // 28 00cc14b8 83e801 sub eax,1
  // 28 00cc14bb 8945f8 mov dword ptr [ebp-8],eax
  // 28 00cc14b3 eb09 jmp puzzler3!myfun+0x3e (00cc14be)
  // 28 00cc14be 837df800 cmp dword ptr [ebp-8],0
  // 28 00cc14c2 7e60 jle puzzler3!myfun+0xa4 (00cc1524)
{
  // 30 00cc14c4 c745ec00000000 mov dword ptr [ebp-14h],0
  // 30 00cc14cb eb09 jmp puzzler3!myfun+0x56 (00cc14d6)
  for(ii = 0; ii < (arg0_len - 1); ii++)
    // 30 00cc14cd 8b45ec mov eax,dword ptr [ebp-14h]
    // 30 00cc14d0 83c001 add eax,1
    // 30 00cc14d3 8945ec mov dword ptr [ebp-14h],eax

    // 30 00cc14d6 8b45f8 mov eax,dword ptr [ebp-8]
    // 30 00cc14d9 83e801 sub eax,1
    // 30 00cc14dc 3945ec cmp dword ptr [ebp-14h],eax
    // 30 00cc14df 7d41 jge puzzler3!myfun+0xa2 (00cc1522)
  {
    //char temp0 = arg0[ii]; // 32 00cc14e1 8b4508 mov eax,dword ptr [ebp+8]
                    // 32 00cc14e4 0345ec add eax,dword ptr [ebp-14h]
                    // 32 00cc14e7 0fbe08 movsx ecx,byte ptr [eax]
    //char temp1 = arg0[ii + 1]; // 32 00cc14ea 8b5508 mov edx,dword ptr [ebp+8]
                      // 32 00cc14ed 0355ec add edx,dword ptr [ebp-14h]
                      // 32 00cc14f0 0fbe4201 movsx eax,byte ptr [edx+1]


    // 32 00cc14f4 3bc8 cmp ecx,eax
    // 32 00cc14f6 7e28 jle puzzler3!myfun+0xa0 (00cc1520)
    if(arg0[ii + 1] > arg0[ii])
    {
       x = arg0[ii]; // 34 00cc14f8 8b4508 mov eax,dword ptr [ebp+8]
                // 34 00cc14fb 0345ec add eax,dword ptr [ebp-14h]
                // 34 00cc14fe 8a08 mov cl,byte ptr [eax]
                // 34 00cc1500 884dd7 mov byte ptr [ebp-29h],cl
            
       arg0[ii] = arg0[ii+1]; // 35 00cc1503 8b4508 mov eax,dword ptr [ebp+8]
                      // 35 00cc1506 0345ec add eax,dword ptr [ebp-14h]
                      // 35 00cc1509 8b4d08 mov ecx,dword ptr [ebp+8]
                      // 35 00cc150c 034dec add ecx,dword ptr [ebp-14h]
                      // 35 00cc150f 8a5101 mov dl,byte ptr [ecx+1]
                      // 35 00cc1512 8810 mov byte ptr [eax],dl
       arg0[ii+1] = x; // 36 00cc1514 8b4508 mov eax,dword ptr [ebp+8]
                  // 36 00cc1517 0345ec add eax,dword ptr [ebp-14h]
                  // 36 00cc151a 8a4dd7 mov cl,byte ptr [ebp-29h]
                  // 36 00cc151d 884801 mov byte ptr [eax+1],cl
    }
  } // 38 00cc1520 ebab jmp puzzler3!myfun+0x4d (00cc14cd)
} // 40 00cc1522 eb91 jmp puzzler3!myfun+0x35 (00cc14b5)

// return and ensure our stack is still correct
return; // 41 00cc1524 5f pop edi
    // 41 00cc1525 5e pop esi
    // 41 00cc1526 5b pop ebx
    // 41 00cc1527 81c4f0000000 add esp,0F0h
    // 41 00cc152d 3bec cmp ebp,esp
    // 41 00cc152f e820fcffff call puzzler3!ILT+335(__RTC_CheckEsp) (00cc1154)
    // 41 00cc1534 8be5 mov esp,ebp
    // 41 00cc1536 5d pop ebp
    // 41 00cc1537 c3 ret
}

puzzler3_driver.cpp

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

void myfun(char *arg0);

int main(int argc, char* argv[])
{
char *test = NULL;

test = (char *)calloc(strlen(argv[0]) + 1, sizeof(char));
strcpy(test, argv[0]);

printf("%s\n", test);
myfun(test);
printf("%s\n", test);

return 0;
}

You'll need an MSVC compiler, probably circa VS2k5 or later, with /Od /GS /RTC1 /FA /Fa"bin\\" to get a listing that'll look like their listing.

Lessons Learned Transporting Patients

2008-04-18T12:53:00.004-04:00

I've learned quite a few things lately transporting patients. Correction, I've relearned quite a few things transporting patients. It isn't like I did not already know what to do, or what I was expected to do, I'm just new. Green. Wet behind the ears. A pain in the ass for admit nurses.

No matter how much of a Real American Badass(tm) you are, no matter how Rain Man-esque you are with numbers, always have your run sheet in front of you when you call in to the hospital. Nothing makes you look like more of an idiot than rattling off a long set of vitals to the admit nurse and then fumbling a curveball question thrown at you like, "his age?" Your lack of an automatic response to this question lets them know you're now covering the phone to ask the patient.

Also, if you have any doubt what any of the medications your patient is on are for, take the 30 seconds to look them up in your field guide. The physician may only be quizzing you when they ask if the patient is on a specific class of drugs, but wouldn't you rather have the correct answer for them than say you are unsure what one of the medications is for?

The biggest problem I've found is not that I'm lacking any of the training necessary to fulfill my position as an EMT, just that it isn't automatic for me yet. You can imagine the level of frustration with myself considering my talents in other fields.

Shell Context Menu Slow to Open

2008-04-09T10:13:00.005-04:00

Recently I've had a problem on my home machine where when right clicking on various shell items (not every shell item) could take 1-2 minutes to bring up the context menu. Explorer would go 'Not Responding', yet take up 0% CPU. Obviously something was blocking in Explorer, and I figured it to be one of my context menu handlers. Context menu handlers are buried within the registry in an expansive set of keys for literally every type of file system object on your computer. Locating every context menu handler is a tall order, but with a little help from Google, I found that NirSoft has an amazing tool called ShellExView which allows you to view all hooks into the Shell, and disable them en masse.

The first step I took was disabling every Context Menu and Property Sheet handler. Then I restarted my machine, and prepared to slowly re-enable them until I found the offending handler. ShellExView has a cool sort method to sort by company, which I tried first, but found no relief. Eventually I discovered that no matter how many things I disabled, my context menu was still slow as dirt.

Then I cut off my network card. Windows loves to take its time trying to find UNC paths--as you're well aware if you've ever mistyped a network share into Start/Run--so I chanced to gather that some shell verb pointed to something on a network path that was no longer there. Viola! Without a network connection my shell context menu's came up at regular speed.

How on earth do I easily find the culprit? There is some shell verb with a UNC path being referenced, and the Registry is a mighty large place. Once again NirSoft¹ came to the rescue with their Registry search tool RegScanner. Set it to search for "\\" and stand back for the deluge of UNC paths found in your registry. Open and delete² any branches that look like [Something\shell\*\command] and have a UNC path in the key. Mine was a program I used once on a Samba share that somehow made its way into my Open list.

Once I removed the offending key, it was back to business as usual.

1. nota bene: I did not intend for this to be a NirSoft shill post, but they really do have the two most useful tools for diagnosing Shell hook problems.

2. nota bene: if you aren't willing to live with toasting your Windows install, you may be inclined to export any keys you delete. I, however, am not so inclined.

Zooming Objects Inside a WPF ItemsControl

2008-04-07T13:04:00.004-04:00

Previously I've shown how to zoom objects in WPF using either an attached property or directly binding a LayoutTransform. If you'd like to zoom objects inside of an ItemsControl, you can use a slight variation on the direct binding strategy.

First you should style the ItemsPanel template for your ItemsControl, in this case a ListBox.

<ItemsPanelTemplate x:Key="ZoomedItemsPanel">
    <StackPanel IsItemsHost="True">
       <StackPanel.LayoutTransform>
          <ScaleTransform
             ScaleX="{Binding Path=Value, ElementName=ZoomSlider}"
             ScaleY="{Binding Path=Value, ElementName=ZoomSlider}" />
       </StackPanel.LayoutTransform>
    </StackPanel>
</ItemsPanelTemplate>

Then your ListBox can reference the ZoomedItemsPanel and enjoy zooming on just its contents!

<Label Content="Zoom: "
   Target="{Binding ElementName=ZoomSlider}" />
<Slider x:Name="ZoomSlider"
   Minimum="0.25"
   Value="1"
   Maximum="5"
   SmallChange="0.5"
   LargeChange="1.0" />
<ListBox ItemsPanel="{DynamicResource ZoomedItemsPanel}" />

Wasn't that easy?

WPF TileBrush Nonsense

2008-03-07T10:08:00.006-05:00

For the absolute life of me I cannot get a custom TileBrush to tile outside of VS2k8 or Blend 2.5. The basics are that I'm constructing a ruler, which started programmatically after finding the current DPI. When that didn't work, I attempted to do the same thing in straight XAML, which wouldn't be relative to the DPI (thus would only be a nice ruler at 96dpi). Even this would not work. At this point my frustration knows no bounds.

The above is a screengrab from inside VS2k8. The screengrab from Blend 2.5 also shows the ruler tiling. Below is a screengrab during runtime, notice the distinctive lack of tiling, and now it is somehow stretching to Fill.

The tiled brush is a DrawingBrush consisting of a GeometryDrawing with a GeometryGroup of LineGeometry's. The annotated XAML is given below:

<DrawingBrush x:Key="RulerBrush"
  Stretch="None"
  TileMode="Tile"
  Viewport="0,0,96,16"
  ViewportUnits="Absolute"
  Viewbox="0 0 1 1"
  ViewboxUnits="RelativeToBoundingBox">
<DrawingBrush.Drawing>
  <GeometryDrawing>
  <GeometryDrawing.Geometry>
     <GeometryGroup>
     <LineGeometry EndPoint="0,16"
           StartPoint="0,0" />
     <!--   ...   -->
     <LineGeometry EndPoint="48,16"
           StartPoint="48,4" />
     <!--   ...   -->
     <LineGeometry EndPoint="96,16"
           StartPoint="96,0" />
     </GeometryGroup>
  </GeometryDrawing.Geometry>
  <GeometryDrawing.Pen>
     <Pen Brush="#FF000000"
        Thickness="1" />
  </GeometryDrawing.Pen>
  </GeometryDrawing>
</DrawingBrush.Drawing>
</DrawingBrush>

And the requisite XAML for the display area:

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="Test.Window1"
  x:Name="Window"
  Title="Window"
  Width="640"
  Height="480">
  <DockPanel x:Name="LayoutRoot" LastChildFill="True">
     <ToolBarTray x:Name="ToolBarTray"
        DockPanel.Dock="Top">
        <ToolBar x:Name="MenuToolBar"
           ToolBar.Band="0"
           Width="{Binding Path=ActualWidth, ElementName=ToolBarTray}" />
     </ToolBarTray>
     <Rectangle x:Name="RulerY"
        DockPanel.Dock="Left"
        Height="15" Margin="0,15,0,0"
        Fill="{DynamicResource RulerBrush}">
        <Rectangle.LayoutTransform>
           <RotateTransform Angle="-90.0" />
        </Rectangle.LayoutTransform>
     </Rectangle>
     <Rectangle x:Name="RulerX"
        DockPanel.Dock="Top"
        Height="15" Margin="0,0,0,0"
        Fill="{DynamicResource RulerBrush}"/>
     <ScrollViewer Style="{DynamicResource SimpleScrollViewer}"/>
  </DockPanel>
</Window>

This is fairly obnoxious!

Writing Quality WPF Applications

2008-02-08T14:14:00.001-05:00

I've got together a few resources which are helpful when attempting to write a quality WPF application. While some of them are for C# 2.0 or .Net 2.0, I feel they are just as valid in C# 3.0 and .Net 3.5.

Without further ado, the (currently short) list:

Hopefully in the future there will be more guides for effective WPF development!

NREMT-B and NCEMT-B

2008-01-31T11:22:00.002-05:00

I passed both the National Registry EMT-Basic and North Carolina EMT-Basic certifications in December and January respectively. Soon I will be volunteering with a local EMS unit, probably at night. In March I will be taking Wilderness EMT training and finally in August I start Paramedic school. Lots of fun to be had in the near future!

Where the &%$@ is HashSet?

2008-01-24T11:09:00.002-05:00

If you've created a .Net 3.5 project in Expression Blend 2 (December Preview) and then opened it up in VS2k8, you may have noticed that using System.Collections.Generic does not give you HashSet.

The type or namespace name 'HashSet' could not be found.

You may be gnashing your teeth over this, but the simple solution is to add System.Core.dll as a reference to your project because it appears Blend 2 leaves this out.

Update: Zoom multiple controls from the same slider in XAML

2008-01-24T10:29:00.001-05:00

I've had a serious learning curve with XAML, and frequently find new and better ways of doing things. A good example of this is zooming multiple controls from the same slider. My previous solution used a DependencyProperty and an IValueConverter and was probably slow as dirt if you wired up more than a few controls to get zoomed. A much more succinct, maintainable, and readable solution would be:

<Page class="ZoomTest.Page1" name="page" xmlns="...">
xmlns:local="clr-namespace:ZoomTest"
local:AttachedProperties.Zoom="0.8">
<Grid>
 <Grid.LayoutTransform>
    <ScaleTransform ScaleX="{Binding Path=Zoom,
                                     ElementName=page}"
                    ScaleY="{Binding Path=Zoom,
                                     ElementName=page}" />
 </Grid.LayoutTransform>
</Grid>
</Page>

And yes, while I do have two bindings, it actually is very fast. One of the big things I've learned is you can really (ab)use the binding system and strangely enough have a faster UI than one you control! In a GUI application I'm designing in WPF, there are over 5000 data bindings on just one page, and yet it is nearly twice as fast as the version where I practically precompute the whole UI! My only guess as to why this is the case is that UIElement's are much more expensive than data bindings.

Another way to tackle the above problem, if say you're on the same UI without Page's, is actually much simpler:

<Window ...>
  <DockPanel x:Name="LayoutRoot"
             LastChildFill="True">
     <StackPanel DockPanel.Dock="Top">
        <Slider x:Name="ZoomSlider"
                Minimum="1" Value="5" Maximum="10" />
     </StackPanel>
     <ScrollViewer>
        <Grid x:Name="content">
           <Grid.LayoutTransform>
              <ScaleTransform ScaleX="{Binding Path=Value,
                              ElementName=ZoomSlider}"
                              ScaleY="{Binding Path=Value,
                              ElementName=ZoomSlider}" />
           </Grid.LayoutTransform>
        </Grid>
     </ScrollViewer>
  </DockPanel>
</Window>

Using strategies like this you can use less C# and more XAML. I've been able to take over 7000 lines of presentation code written for Java 1.4 (the C# 2.0 code would be roughly the same size) and turn it into roughly 550 lines of XAML and 100 lines of C# 3.0. Expect more little fun things you can do with WPF soon (like making a ListBox do whatever you please).

Zoom multiple controls from the same slider in XAML

2007-12-13T10:56:00.001-05:00

Recently we've been playing around with XAML and WPF at work, and a common situation we run across is wanting to zoom different Page's without having separate zoom functionality. One slider should be enough to zoom any Page we hook up.

The basics start with an attached DependencyProperty called Zoom.

public static class AttachedProperties
{
  public static readonly DependencyProperty ZoomProperty
     = DependencyProperty.RegisterAttached("Zoom", typeof(double), typeof(UIElement),
        new FrameworkPropertyMetadata(1.0,
        FrameworkPropertyMetadataOptions.AffectsRender, null /* PropChangedCallback */,
        new CoerceValueCallback((obj, value) => (double)value < 0.0 ? 0.0 : (double)value)));

  public static double GetZoom(DependencyObject obj)
  {
     return (double)obj.GetValue(ZoomProperty);
  }

  public static void SetZoom(DependencyObject obj, object value)
  {
     double val = Double.Parse(value.ToString());
     obj.SetValue(ZoomProperty, val);
  }
}

Now we have an attached property we can connect to any UI Element! Notice that I suffixed 'Zoom' with '-Property' for the static variable, yet gave RegisterAttached just 'Zoom'. This is by convention (coincidentally so are the Get/Set pair below the static value).

<Page x:Class="ZoomTest.Page1" x:Name="page" xmlns="...">
  xmlns:local="clr-namespace:ZoomTest"
  local:AttachedProperties.Zoom="0.8">
  <Grid />
</Page>

Now we have a Page that starts with a default zoom property of 80%. However, this does not do us much good. We don't actually tell the page how to zoom anywhere. This is where Binding comes into play.

<Page x:Class="ZoomTest.Page1" x:Name="page" xmlns="...">
  xmlns:local="clr-namespace:ZoomTest"
  local:AttachedProperties.Zoom="0.8">
  <Grid LayoutTransform="{Binding Zoom, ElementName=page}">
  </Grid>
</Page>

Now anything inside of the Grid will get a LayoutTransform based on the Zoom property of the Page! Unfortunately the LayoutTransform requires an actual Transform and not a double. Now we could have made the Zoom property a ScaleTransform, but that makes it less useful as an attached property. However, all is not lost:

public class ZoomConverter : IValueConverter
{
  public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
  {
     if (targetType != typeof(Transform))
        throw new InvalidOperationException();

     double val = Double.Parse(value.ToString()) / 100.0;
     return new ScaleTransform(val, val);
  }

  public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
  {
     throw new NotSupportedException();
  }
}

Now we just have to hook the converter up to the data binding, and viola! We have a Page who's Grid content zooms in and out with respect to a given scale.

<Page x:Class="ZoomTest.Page1" x:Name="page" xmlns="...">
  xmlns:local="clr-namespace:ZoomTest"
  local:AttachedProperties.Zoom="0.8">
  <Page.Resources><local:ZoomConverter x:Key="zoomConverter" /></Page.Resources>
  <Grid LayoutTransform="{Binding Zoom, ElementName=page, Converter={StaticResource zoomConverter}}">
  </Grid>
</Page>

At this point all we have to do is wire up a Slider (two step process wraaa)!

<Window x:Class="GeometryTest.Window1" x:Name="window"
  xmlns="..." local="clr-namespace:ZoomTest"
  Title="Zoom Test" Height="480" Width="640">
  <DockPanel LastChildFill="True">
     <ToolBarTray DockPanel.Dock="Top">
        <ToolBar>
           <Label>Zoom:</Label><Slider x:Name="zoomSlider" Minimum="1" Maximum="100" Value="50" />
        </ToolBar>
     </ToolBarTray>
     <Frame Source="Page1.xaml" LoadCompleted="ContentFrame_LoadCompleted" />
  </DockPanel>
</Window>
...
void ContentFrame_LoadCompleted(object sender, NavigationEventArgs e)
{
  Binding binding = new Binding();
  binding.Source = zoomSlider;
  binding.Path = new PropertyPath("Value");
  (ContentFrame.Content as UIElement).SetBinding(AttachedProperties.ZoomProperty, binding);
}

Now, changing the zoom value with the Slider will cause the Grid to zoom in and out! Bonus points for adding a ScrollViewer to the Page to let you actually see the change in size of your Grid.

Emergency Medical Technician

2007-11-13T11:11:00.001-05:00

My absence from blogging lately can be attributed to a recent change in my life. I'm nearly finished with my Emergency Medical Technician - Basic training at a local community college. This class has been really challenging, and quite a lot of fun. However, studying has dominated my free time, and I have less time at work to blog (because I work less hours now).

Recap of fun things:

Hospital clinicals were great
Ambulance ride-alongs have been fun as well (one more left!)
The Jaws-of-Life are so indescribably cool (I got to cut the roof off of a car), quite literally the Jaws-of-Life will cut through anything you can fit them around on a car.

In August I begin Paramedic school, however, to fill the gap from January (certification as an EMT-B) until August I will be volunteering for a local Fire/Rescue squad as either an EMT-B first responder or an EMT-B in an ambulance. I will keep everyone (all seven of you) updated as this part of my life continues.

Nota bene: I will still be working as a software engineer, just volunteering as an EMT-B.

I Work in an Almost Award Winning Trailer

2007-10-02T10:00:00.002-04:00

People often tell me they think I work in some glorious office building, or at least somewhere cool. This is pretty far from the truth. On site I've worked in "Green Acres", the e-Cave, shop floor mezzanines, and now a trailer.

"Green Acres" was the first place I worked on site. It was the green office area, which picked up its folksy nickname because you were deep inside a manufacturing building, bathed in constant fluorescent light, unable to hear anything from the outside. If you came in to work and the sun was shining, your brain expected the sun to be shining when you left. Unless lightning struck the building, we were completely oblivious to outside noise. Just the constant hum of fluorescent lighting.

Later I switched groups and was given the opportunity to work in the e-Cave. Imagine a room with open faced cubicles lining the walls. Seven interns and four salaried workers all crammed into a big open room with some conference room chairs, a projector, and a screen. My fondest memories of working on site were from the e-Cave. Come 11am, the whole crew would rally for lunch. I swear those were the most productive years; my old boss swears they were the least productive years.

This same group got bounced around to various locations, eventually settling down in a shop floor mezzanine. We stayed there for almost 3 years. It wasn't bad, the interns had their own 'row', we spent a lot of time in each others cubes. Pretty standard corporate experience....except the place smelled like feet (ed: as I am writing this my shoes are off and I'm just in socks...no idea why that place smelled like feet, nope).

Not too long ago we got the news that we would be moving to the 14-wide. This 14 trailer wide (yes 14) "modular office space" is actually the bigger of two trailers built on the far side of the site. Our sister trailer is only 13-wide, but it is hard to tell they are short one trailer. Our trailer is complete with a buried septic tank (that has hit the critical level alarm twice), offsite power (we've lost it no less than 3 times), and a gravel parking lot. I will say though that parking is a lot more fun when you can fishtail into a spot.

It is hard not to laugh at where I work. I work for a Fortune 10 company...in a trailer. We do all sorts of crazy nuclear methods...in a trailer. But wait, this isn't just any trailer. This is an Almost Award Winning Trailer. Our 14-wide received honorable mention in the 2007 Modular Building Institute Awards of Distinction for a modular office space of <5,000sqft. I'm sure we were neck-and-neck with the Trenton Police Department, so congratulations to them for their hard work and modular working environment.

Let us remember that in the world of working in a trailer, everybody is a winner!

To my noname friend: atoi and atof as they should never be done

2007-09-19T22:54:00.001-04:00

Sometimes, when I get bored, I spend an hour or so reinventing the wheel. Earlier tonight I was asked how code like atoi worked. A quick look at an ASCII table and a few multiply-accumulates later, we have something like:

/* atoi - christopher.watford@gmail.com */
/* PUBLIC DOMAIN */
long atoi(const char *value) {
  long ival = 0, c, n = 1, i = 0, oval;
  for( ; c = value[i]; ++i) /* chomp leading spaces */
    if(!isspace(c)) break;
  if(c=='-' || c=='+') { /* chomp sign */
    n = (c!='-' ? n : -1); i++;
  }
  while(c = value[i++]) { /* parse number */
    if(!isdigit(c)) return 0;
    oval = ival; /* save ival for overflow detection */
    ival = (ival * 10) + (c - '0'); /* mult/accum */
    if(ival < oval) { /* report overflow/underflow */
      errno = ERANGE;
      return (n>0 ? LONG_MAX : LONG_MIN);
    }
  }
  return (n>0 ? ival : -ival);
}

Yes, this is quite ugly, and if I ever catch you writing something this cryptic I'll force a 15 page code review on you. However, one can tell how much fun atoi actually is once you take into account error checking!

Naturally our conversation drifted to atof--well in his defense I drifted to atof--and I decided I should write a compliant implementation. As it turns out implementing overflow and underflow checking for floating point numbers is much harder (and trickier too!) than for integers. Below are the pretty printed sources to both my atoi and atof implementations, along with links to download. They are in the public domain and you should use them at your own risk, because if I were to catch you using either of these I will hold a code review so harsh it would make a death row inmate cry.

View atoi source (download)
View atof source (download)

Fun with FORTRAN intrinsics and portability

2007-08-20T15:04:00.004-04:00

When porting code from one compiler to the next, you run into all sorts of fun syntactical issues, gotchas with floating point handling, and how each maintainer semantically interpreted the standard.

When porting code from one runtime library to the next, you run into even more fun! Who says the API of your favorite function has not changed? Perhaps you no longer can reference some functions. What could you do to mitigate these risks?

I stumbled across some code that attempted to mitigate these risks associated with the Compaq FORTRAN non-standard (yet invaluable) intrinsic SLEEP by calling out to the C Runtime Library's sleep routine (compliant under ISO/IEC 9945-1:1990, "POSIX.1"). As the code progressed through the years, the original maintainers noted that on Windows, the sleep routine was renamed to Sleep. A simple change to the interface definition fixed the linking issues:

interface
subroutine SLEEP(seconds)
!DEC$ATTRIBUTES DECORATE, STDCALL, ALIAS:'Sleep' :: SLEEP
integer*4 :: seconds
end subroutine
end interface

However, careful users would notice that this change (as an attempt to use the more stable C RTL version of sleep) has an unexpected side effect. MSDN states that the single parameter given to Sleep is actually, "The minimum time interval for which execution is to be suspended, in milliseconds."

So, code that once called SLEEP(1) or SLEEP(5) expecting to regain control in 1s and 5s respectively, now sleeps for 1ms and 5ms respectively. This is well beneath the timeslice/quantum given to a process (6-55ms on Windows), effectively making the call an inefficient Sleep(0) (which in and of itself is an inefficient thread yield!). The correct action is to consult the Intel FORTRAN Libraries reference and note that in the portability library is a SLEEP function that replicates the non-standard intrinsic found for Compaq, and will work across all platforms Intel's FORTRAN compiler is supported. This is not a great solution, but it is also not the worst solution (hacking a layer on top of the Windows Sleep function to multiply the parameter by 1000).

As an aside, it is a bit of a programming error to rely on sleep for hard timing of any interval other than integer multiples of the timeslice/quantum (plus some amount of jitter). It is also a bit of a programming error to ignore changes to API's when moving compilers and libraries and operating systems.

Too bad compilers cannot catch either of these...

MPICH.NT, MPICH2, and TCP Offloading (continued)

2007-07-25T11:10:00.003-04:00

Well we tried updated drivers for the NC373i but with no avail. We were still seeing TOE errors which resulted in MPICH.NT and MPICH2 hanging. Luckily the machines have second NIC's, NC380T PCIe DP Multifunc Gigabit Server Adapters. Unluckily for us, those network cards exhibited the same problem as the embedded NC373i.

This leads me to believe that there is a problem with the Windows 2003 R2 Scalable Networking Pack. Specifically with the Chimney TCP Offloading portion. There may even be an issue in MPICH.NT and MPICH2 and Windows 2003 R2's SNP. However, that just seems highly unlikely as MPICH.NT and MPICH2 are wildly different under the hood.

We've initiated a case with Microsoft to get to the bottom of this issue. Meanwhile our new servers have TOE disabled, which isn't bad, but it isn't good either.

MPICH.NT, MPICH2, and TCP Offloading

2007-07-23T10:39:00.001-04:00

Recently we came across a strange problem where on some new machines MPICH.NT and MPICH2 both would fail to correctly operate across machines. On a single machine there were no problems, and actually the application partially worked under MPICH.NT.

My initial guess was MPICH.NT did not play well with Windows 2003 Server R2. Previously we have only had Windows 2000 Server for the MPI jobs, so it seemed logical that changing the server OS would cause some issues. I recompiled the application for MPICH2 (bigger, newer, better) and found the application "hung" in exactly the same fashion as under MPICH.NT.

So now I had a common failure mode across two versions of MPICH (which are wildly different under the hood) on the same OS. I started running MPICH in debug/verbose mode and spent a lot of time looking at the thousands of lines of output and noticed that both under MPICH.NT and MPICH2 they came to the same place and halted, only I couldn't tell where in the code this was.

You may think this is where I fired up the parallel debugger and did wild and crazy things, but that takes too much time. I went with good ole fashioned printf debugging. I ended up getting output like the following:

[0] calling MPI_Bcast ...
[1] calling MPI_Bcast ...
[2] calling MPI_Bcast ...
[3] calling MPI_Bcast ...
[4] calling MPI_Bcast ...
...
[N-2] calling MPI_Bcast ...
[N-1] calling MPI_Bcast ...

Where [X] is the process number and if the call was successful the MPI_STATUS code would be returned on the next line, however, none of these calls returned. An important thing to note is these MPI_Bcast calls were sending buffers of 150MiB+, which is quite large. This fact drove me to check on the network card settings.

While poking around in the network card settings, I noticed two things:

Network card drivers were out of date
Network card status tool counters showed some errors in TCP Offloading

Using the information that TOE had reported errors in the past, I reran the application and watched the TOE error counters. Sure enough, when that MPI_Bcast line was reached, the TOE error counters incremented by one. So I went and disabled TOE on my two test machines and reran the application.

Boom, problem solved. Well...not really.

Disabling TOE will kill performance for other applications that do not have an issue with offloading. However, I cannot upgrade the drivers for the network card (even as a test) without going through 10 miles of red tape. That is neither here nor there, the important part is the problem has been identified and can be solved.

So if you have an HP NC373i Multifunction Gigabit Ethernet Adapter and experience problems with MPICH or MPICH2 on Windows, it is probably the TCP Offloading Engine. Try updating your drivers or disabling TOE to solve the issue. I will post an update if the latest drivers indeed fix this issue.

CNN, Kashiwazaki NPP, and the 2007 Niigata Earthquake

2007-07-17T16:29:00.002-04:00

(ed: I normally don't blog about non-technical issues, but this chaps my cheeks to no end)

If you haven't heard yesterday an earthquake happened of the coast off the Niigata prefecture in Japan. It had a magnitude of 6.8 and caused serious problems for the Kashiwazaki-Kariwa NPP. A transformer caught fire at unit 3 (there are 7 units) and radioactive liquids spilled into the ocean. This is obviously a serious event and should be treated as such, however, the news coverage was yellow journalism at best. All of the initial reports were sensationalist and biased with little facts (partially due to the tight lipped nature of TEPCO) to support any of their claims.

To see how bad the yellow journalism got just read the following headline blurb:

Radioactive leak, tremors follow Japan quake
A strong earthquake struck northwestern Japan today, causing a radioactive leak and fire at one of the world's most powerful nuclear power plants. Eight people were killed and hundreds injured. The plant leaked about 315 gallons of water, according to a Tokyo Electric official.

So, how many casualties were a result of the radioactive leak and fire:

8 deaths and hundreds of injuries
6 deaths and hundreds of injuries
1 death and tens of injuries
0 deaths and 0 injuries

If you guessed 0 and 0 you would be right!

But wait...

Didn't the blurb say that eight people died and hundreds were injured by the radioactive leak and fire?! Why yes, yes it did. This is far from ethical, yet CNN went right ahead and posted that online.

Don't believe me? Check out this screenshot of CNN's misrepresentation of the Kashiwazaki-Kariwa leak and fire.

Lessons Learned Flying Space Available

2007-07-11T10:56:00.001-04:00

Flying space available is great. It is cheap, fun, and can be very flexible. However, when things get busy you can find yourself in trouble. Space available travel is prioritized and if you aren't an employee of an airline, you'll find yourself at the bottom of the pile.

You can mitigate your troubles by always arriving for the earliest flight possible. Quite often people oversleep and miss the early flights. Waking up at 3:30 AM to possibly catch the 5:00 AM flight might sound awful, but it may be the only way to make it to your destination.

If you are not able to make it onto a flight you are listed for, you are automatically rolled over to the next flight. However, twice I have not been rolled over for one reason or another and had to be manually moved. Always double check to make sure you have been added to the next flight.

When you miss a flight, it may seem tempting to use the 1-800 number most airlines have to change to a different option. However, I've found they tend to not get the change made properly. Always use the gate agents to make the change and quite often they will also suggest alternate routes (if only to get you off their back).

If you happen to be woefully unlucky and are bumped from one day to the next save your boarding pass from the day before. You can use that to skip the lines at the ticketing counter and go straight through security. Once you get to the gate double check that you are indeed listed on the flight and get yourself a new flight coupon (or if really lucky a boarding pass).

The last bit of advice is to be as sociable as possible. Hang out with the gate agents, any flight attendants who are stuck, and yuck it up with other space available passengers. I've met so many great people sitting around in airports waiting on flights. Some of these people can even help you out if you're really stuck, so it's worth being polite and friendly. Getting somebody a $3 airport coffee can go a long way towards making it onto a flight.

Conflicting COM Interop DLL Names

2007-06-24T11:02:00.001-04:00

Recently our job scheduling software got a version bump from 5 to 6 and I'm in charge of bringing our support libraries up to date. A quick look into the changelog showed that I would have to do some under the hood work, but I have a relatively abstracted class library which would be easy to add support for version 6.

Not so fast. The job scheduler uses COM objects as its method of interaction, and .Net has to build an interop assembly to talk to it. The easy way, Add Reference -> COM, should work. It should work, provided the COM DLL's have different names. Thanks to Murphy's Law, the two DLL's, while under different folders, have the same name!

.Net generates Interop.X.dll and Interop.X.dll, even though the two are in different folders and represent different versions, solely because our job scheduler's COM DLL is X.dll, in both folders. While this is not necessarily their fault, it certainly makes the lives of those of us who do integration harder (their COM object model is pretty bad to start with).

Thankfully, Microsoft provides the means to create your own Primary Interop Assembly from a DLL. Using TlbImp you can create your own COM Interop DLL, complete with a non-conflicting name and namespace.

TlbImp version5\X.dll /namespace:X /out:Interop.X.dll
TlbImp version6\X.dll /namespace:X6 /out:Interop.X6.dll

Now I can import these two conflict free and deal with more important issues, like the poor documentation included with the COM library.

KB925902: X is not a valid Win32 application

2007-06-20T10:20:00.002-04:00

Recently we've had a number of new hires and interns come in as the business expands and schools get out. They've been given new computers, Core 2 Duo's and Xeon 51XX's. Last week a few users reported no longer being able to run certain older applications. Windows XP SP2 stated that "X is not a valid Win32 application."

Yet earlier in the day or in the week they had been able to run the same executable without any issues. On my XPSP2 machine I could run the executables fine, and Win2ksp4 had no problems either. At this point a massive search for "what changed" began.

The executables were compiled on MSVS6 and Compaq Visual FORTRAN, so perhaps it was their newer processors coupled with the way the executables were compiled. Sure enough recompiling under MSVS8 or Intel Visual FORTRAN allowed them to run the executables. However, one of the executables still had a problem. Thankfully, we got a new error (I hate old errors):

XXXXX.EXE - Illegal System DLL Relocation
The system DLL user32.dll was relocated in memory. The application will not run properly. The relocation occurred because the DLL C:\WINNT\system32\HHCTRL.OCX occupied an address range reserved for Windows system DLLs. The vendor supplying the DLL should be contacted for a new DLL.

Lovely, a Windows OCX control bumped user32. A quick google search brought up KB925902 as the offending patch. I went to one of the machines to look for the patch, but it appeared from Add/Remove Programs that this patch was never installed!

Before giving up saying the patch is not installed, a useful thing to note is you can browse to %WINDIR% and take a look at all the NTUNINSTALL$KB* folders to see every patch that has been applied. This list is much more exhaustive than the Add/Remove Programs list.

Sure enough, there was %WINDIR%\ntuninstall$kb925902\, and after uninstalling the patch, everything was fine on these machines. I wonder what KB925902 could have possibly changed to cause such a colossal error.

MS07-017: Vulnerability in GDI could allow remote code execution

So, a security bug in the graphics subsystem gets a patch which affects the ability to run console applications? You should read the article on MS07-017 to get a feel for how many subsystems are affected by their patch. Thank you Windows for making my life so wonderful.

New Intel Visual FORTRAN 10.0.025

2007-06-13T14:47:00.003-04:00

Intel Visual FORTRAN 10.0.025 was just released, and of course I got my hands on it. I'd had troubles in 9.1 that were "Targeted to Fix," but I needed the codes compiled as soon as possible. So I install IVF10, and get started with my first project. I press F7 and wait...

Crash.

The new version of IVF has a static verification component. It turns out that my project (about 105KLOC) causes the verification tool to run into the per-process memory limit (2GiB). Talk about cool. I've now broken two versions of the Intel compiler right out of the box!

I can't really blame Intel, I would imagine full static verification of a project of that size would be hard to do in 2GiB of memory. Besides, it is only a nicety, so I disabled it and compiled again. Without static verification it worked, however, when I went to run, my program reported that it could not find a file.

This file is pulled from an environment variable and as soon as I stepped through the application it became obvious what happened. Visual Studio's Environment configuration option for debugging had delimited the key value pair lines with \r\n instead of just \n. A temporary solution for this problem is to bring up a C++ project and input the environment there, then copy and paste the string into the IVF10 project's Environment setting. Not sure if this is an IVF10 or VS2005 issue.

I am now known at work as the code killer. Put something in front of me and I'll break it. Whoops.

.Net Deployment Build Error HRESULT = '80004005'

2007-06-12T11:58:00.003-04:00

I've got a Visual Studio 2005 Deployment project for an application I distribute internally, and came across this crazy error while rebuilding the MSI file.

------ Starting pre-build validation for project 'MyProjectInstall' ------
ERROR: An error occurred while validating.  HRESULT = '80004005'
------ Pre-build validation for project 'MyProjectInstall' completed ------

No other clues as to the actual problem. Some googling revealed that this has to do with a project building with references it does not need (or in my case stale references). A quick fix is to go to the offending 'Primary Output' project, and remove all of its non-Microsoft references. Then add them one by one until the project compiles. At this point your deployment project should compile without any hassles.

Drive Letter Economics

2007-06-08T13:59:00.000-04:00

On Windows there is a fun property of the command line (not quite DOS) where you cannot change directory to a UNC path. This effectively makes it impossible to set your working directory to a UNC path from a batch file. To address this issue Microsoft has two methods of switching to a UNC path.

You can NET USE the path as a drive letter. However, you have to be sure that the drive letter you chose is not in use. When running in a large multi-user environment, you can see how this would become troublesome. More importantly, NET USE is semi-permanent, living for as long as the computer is on. You must unuse the drive letter assignment to free this up for other people.

Your other option is pushd which pushes a path name onto a virtual stack, making the path you specify the current working directory. If you pushd a UNC path, it is assigned a drive letter from the pool of open drive letters. Now, this too is semi-permanent (i.e. outlives the cmd instance it was done in). This assignment lives on until you unuse it or use popd. The more vexing part is on Windows 2000 Server these drive letter assignments affect everyone who uses the machine.

Let's say user A has a script that calls pushd without popd, if his script gets run enough times, eventually Windows 2000 Server machines begin running out of drive letters. So when user B's script runs on a machine without free drive letters, they are greeted with this fun message:

C:\>PUSHD \\machine\unc\path\here\
' ' is an invalid current directory path.  UNC paths are not supported.

Aren't you glad you get an error message which reflects the problem?

Now on Windows 2003 Server this problem is non-existent. Users can only muck up drive letter assignments for themselves, not for everyone logged in to a machine. However, upgrading production servers to another operating system is not always a valid fix. The problem does not go away, just users are insulated from other users.

The correct solution is to follow the best practices and have a matching popd for ever pushd call you make. Of course, it wouldn't be a best practice if nobody ignored it.

Premature Optimization is the Root of all Evil

2007-06-01T11:24:00.003-04:00

Donald Knuth was indeed right when he said that, "premature optimization is the root of all evil." In a few FORTRAN codes I have, the original programmers made use of boolean short circuiting. This technique is extremely popular in languages which support it. If you are unfamiliar with short circuiting it goes a little something like this, given:

if (expression1 .and. expression2 ... .and. expressionN) then
 ! some code here
end if

Short circuiting relies on the fact that the language will evaluate boolean expressions in order of precedence, from left to right. So if and only if expression1 is .TRUE. then expression2 will be evaluated. If and only if expression2 is .TRUE. then expression3 is evaluated, and so on and so forth. If, from left to right, any expression is found to be .FALSE. then the entire If statement is considered to be .FALSE., which in boolean algebra makes sense.

A common use of boolean short circuiting would be to protect against out of bounds array access in loops which may not stop at the end of an array. For instance:

real, dimension(:), allocatable :: myArray
allocate(myArray(n))
...
do i = 1,m
if (i .lt. n .and. myArray(i) .op. someVal) then
  ! do something
end if
end do

Many languages support short circuiting by design, many support it by consensus, however FORTRAN does not make short circuiting part of the design and there is no consensus on its adoption. The above example works fine under Compaq Visual FORTRAN, but if you enable bounds checking on Intel Visual FORTRAN you get a run-time error.

Both CVF and IVF are following the standard with their interpretations, FORTRAN does not specify how a compiler should implement the above if statement. However, often times people adopt the unofficial standards created by compilers which interpret the standard in a certain way. CVF evaluates the statement above left-to-right and applies boolean short circuiting. IVF evaluates all components of the expression before making a decision. Both of these interpretations are correct, but they have interesting implications.

if (b .op. k .and. somefunc() .op. someval) then
! CVF and IVF may not execute this in the same fashion
end if

The problem with the above statement is that if IVF were to evaluate somefunc() before the comparison between b and k, potential side effects inside somefunc() could alter b or k, fundamentally changing the meaning of the statement. Worse still if the code was originally defined for CVF, the side effects of somefunc() could depend on being ignored when the comparison between b and k is .FALSE..

As a programmer you should mind the relevant standards and strive to rely on as few platform or compiler specific behaviors. The two above examples could be rewritten with their intentions preserved in only a few extra lines.

real, dimension(:), allocatable :: myArray
allocate(myArray(n))
...
do i = 1,m
if (i .lt. n) then
  if (myArray(i) .op. someVal) then
     ! all FORTRAN compilers will get here for the same
     ! reason
  end if
end if
end do
...
if (b .op. k) then
if (somefunc() .op. someval) then
  ! all FORTRAN compilers will get here for the same
  ! reason
end if
end if

So pay attention to the fun problems you may create for the guy who inherits your code when you get all crazy. It has been said that 60% of programming is maintaining your code, however, I find in my job that number is closer to 80 or even 90%. Don't make your life any harder than it already is.

.Net XmlSerializer and InvalidCastException

2007-05-31T18:52:00.001-04:00

Many of our applications work via a plugin architecture, which allows us to be flexible in a lot of ways. A while back I ran into a problem with XML serialization and our plugin system. The error was confusing and the solution was non-obvious. The exception I recieved was the following:

System.InvalidOperationException: There was an error generating the XML document.
---System.InvalidCastException: Unable to cast object
of type 'MyNamespace.Settings' to type 'MyNamespace.Settings'. at
Microsoft.Xml.Serialization.GeneratedAssembly.
  XmlSerializationWriterSettings.Write3_Settings(Object o)

I've made bold the confusing (and vexing!) part of the error. Apparently the XmlSerializer could not cast a type to itself? Worse still, the MSDN documentation does not list InvalidCastException as a common exception (which normally lists the boneheaded mistake your program made).

After a large amount of googling, I came across a snippet--which if you place in App.Config--makes the error disappear (but is not meant to remove any errors):

<system.diagnostics>
  <switches>
     <add name="XmlSerialization.Compilation" value="4" />
  </switches>
</system.diagnostics>

What the "4" means, I could not tell you, but this magical block of code solved my problem. However, I am never satisfied with hacks like this, so I dug deeper. The root cause apparently is due to how I load my plugin and where the assembly is that called the XmlSerializer.

In .Net there are 3 assembly load contexts (plus assemblies can be loaded without context), each causes your types to be slightly different. If your plugin is loaded in the Load-From context (as mine was), the type MyNamespace.Settings is "branded" (so to speak) with the context it was resolved in. If your plugin uses an XmlSerializer, the temporary assemblies generated to speed (de)serialization are part of the Load context (or perhaps are without context, I haven't found out for sure). Therefore the type the XmlSerializer attempts to create is different in context from the type in your plugin.

I found the most effective strategy to combat this interesting error is to always use the Load context. This requires your plugin DLLs lie under the ApplicationBase or PrivateBinBase paths. All in all this is the best solution, considering Side-by-Side is the new Microsoft way of deploying applications and DLLs (to avoid DLL Hell).

Here is a short snippet of what the plugins may look like in your App.Config:

<plugins>
  <plugin
     name="My Plugin"
     assemblyName="MyPlugin, Version=1.0.0.0,
     Culture=neutral, PublicKeyToken=deadbeefbaadf00d" />
</plugins>

You could then load this plugin (after reading in the appropriate ConfigurationSection) like so, to ensure XmlSerializer works in your plugin:

PluginsSection pluginsSection =
  config.GetSection("plugins") as PluginsSection;
foreach(PluginElement elt in pluginsSection.Plugins)
{
  Assembly pluginAsm = Assembly.Load(elt.AssemblyName);
  /* Reflect across the assembly looking for types with
   * [MyAppPluginAttribute] or those that implement
   * IMyAppPlugin, so an assembly can contain more than
   * one plugin.
   */
}

The .Net world has many intricacies and most seem to stem from this notion of Assemblies and satellite assemblies and manifests and ligers and unicorns, so don't be discouraged if you have a hard time working it all out.

Tracking down network gremlins

2007-05-30T19:10:00.000-04:00

I've been besieged as of late by gremlins somewhere in the ether. They have stolen our token rings and have set fire to my home. Actually, it appears our file server is crapping out (again with those technical terms) at random intervals.

Well, how do I know it is the file server?

I did not know at first, the errors returned from FORTRAN applications were code 30, which basically means it could not open a file, but it did not know why. Later, I received some errors during reading and writing, which confirmed an issue with the file server (and not the application).

However, there were no useful error codes being returned!

Instead of rewriting these older applications to return the system error codes (newer ones include said detail) I wrote a canary application (in C if you must know). This tester would attempt to open a few files thousands of times in random order. Then read, write, read+write to each of these files thousands of times. It would do all of this in a giant loop, sleeping for a set amount of time at the end. During this loop it would rigorously check the return values of the functions, and die immediately (and loudly!) with the corresponding error code.

Sure enough it caught the error!

Wait, now that we know what the error is, why are we getting this error?

Preliminary analysis had it that the file server was CPU bound during the "hiccup". How could we really know what was the cause? Sysinternals has a lovely suite called PsTools which provides everything you could ever need to monitor processes from the command line. A simple trigger for the canary job to run a PsExec job when it died with an error was implemented:

psexec \\machinename pslist -s 90 -r 5 -x

Now we could get some output from the file server as to what it was doing when the job had the "hiccup". This worked well and we were able to identify the offending process (and even the offending thread!), yet that did not solve our problem. It only identified a cause and most likely not even the root cause! Eventually we will drill down to the actual problem and solve that (only to move on to the next issue, phew).

VAX Floating Point Numbers

2007-05-30T11:04:00.001-04:00

So in the world of old hardware you have the DEC VAX. Big ole honkin' machines from the days of yore. They were introduced a decade before I was born and support for them was withdrawn before I graduated high school. By the time I began interacting with them, they were the old gray mare having been largely replaced by hardware like the DEC Alpha (AXP).

The transition from VAX to AXP was pretty smooth on OpenVMS and many companies, including the one I work for, made the move. Modern AXP processors are impressive and for a long time held the record for the fastest supercomputers in the United States.

Part of the allure of the AXP was it's support for data found on the VAX. VAXen came long before the IEEE 754 standard for floating point numbers, so it is not hard to see how they developed their own standard. IBM mainframes and Cray supercomputers both have (popular) floating point formats from around that time. Interestingly the VAX floating point format has some formatting dependencies on the PDP-11 (craaaazy) format, which can really make life hell.

So why would I bring this up?

When a company has been using computers for a long time, you end up with a need to store data somewhere. Now data that is a decade old is easy to interact with. Imagine going back another ten years. Imagine another ten. You're now knocking on the door of the advent of (roughly) modern computing. FORTRAN 66 (and later 77) is in its prime. VAXen and IBM mainframes rule the earth! Kidding, but at least VAXen ruled my company.

The amount of data which has been preserved is staggering. The only issue is, the number of machines which can natively read the data is diminishing rapidly. Compaq (the new DEC) is phasing out support for the AXP in 2004 and transitioning users to the Intel Itanium and Itanium 2 (cue up Itanic jokes). A certain nagging problem with this transition is the loss of native support for the VAX floating point format.

The two common formats I deal with are the VAX F_Float and G_Float, single and double precision respectively. The F_Float is bias-128 and the G_Float is bias-1024. Both the F and G representations have an implicitly defined hidden-bit normalized mantissa (m) like so:

0.1mmm...mmm

F_Float is held in 32 bits and G_Float is held in 64 bits. Both formats ~~suffer~~inherit from the PDP-11 memory layout, so the actual bits stored on disk is not true little endian.

So why is this a problem?

There are no modern processors (read: with future support) with native support for the VAX format. All of our codes which read in floating point data from old data files must make the conversion from the VAX format to their host format (which in all cases is IEEE754). This conversion is not nice and is in fact lossy.

IEEE754 S_Float and T_float, single and double precision respectively, cannot exactly represent all VAX floating point data. S_Float is bias-127 and T_Float is bias-1023 (note this is different than F and G). Both S and T have hidden-bit normalized mantissas, however IEEE754 supports "subnormal" or "denormal" forms, where the leading bit could be a 1 or a 0.

1.mmm...mmm (normal)
0.mmm...mmm (subnormal)

This does not bode well for direct conversion between the formats.

Even if the byte layout was the same, we still have two different forms for floating point numbers. Every time we make the conversion we lose precision. What is even more insidious is that VAX and IEEE754 do not have the same rounding rules (I'm not even sure the VAX has defined rounding rules!). Floating point formats are inherently inexact and how these inexact representations are interpreted with respect to rounding is very important.

Moreover, even if we overlooked the problems in representation of floating point numbers, what about exceptional numbers like Infinity and the result of a divide by zero operation? The VAX format only defines positive and negative "excess," which while akin to Infinity, causes an exception and cannot be used in math. IEEE754 encodes both positive and negative Infinity and includes a special case for mathematical operations which have no defined result, Not A Number (NaN). IEEE754 supports both quiet NaN's, which always produce NaN, and loud NaN's which throw floating point exceptions.

Ok, so if we ignore Infinity and NaN we still have a problem. IEEE754 supports positive and negative zero. VAX only supports positive zero. Why is this a problem? Not only is negative zero unrepresentable on the VAX, but many common mathematical operations on IEEE754 can result in a negative zero (say converging from the "left" of zero).

Wow, so basically we're screwed.

Or not. The path to go down is one where the data gets converted to the new standard (new being in the last 15 years or so) which is (more-or-less) a universal standard on processors. This is a time consuming task, and one that needs to be approached carefully to ensure a high degree of fidelity. However, it needs to be made to ensure the longevity of both the software and the data.

Intel Visual FORTRAN oddity

2007-05-29T19:46:00.003-04:00

So I come across some excellent FORTRAN77 code that I must convert to F90 and use Intel Visual FORTRAN with. Not a big deal, the code is well formed F77 and should convert to F90 in a straightforward manner.

Ha ha ha, I know, what was I thinking.

The conversion was easy going until mysteriously the compiler began crapping out (yes how very technical) with an abort code of 3. No error in my code, just the compiler was having internal issues. The specific error from the Intel FORTRAN 9.1 compiler was:

GEM_LO_GET_LOCATOR_INFO: zero locator value

This was truly vexing, because at the time I was in a rush to get this code ported over to IVF. Sure enough, there was an internal problem with the Intel compiler, confirmed by their support staff. A specific variable name (SNGL), coupled with some specific compiler flags (/iface:stdref /names:as_is) caused the abort.

A patch is in the works, meanwhile SNGL becomes singleVal in the converted code, and viola the problem vanishes. I'd love to see the root cause analysis on that bug!

Finally got one of these for work

2007-05-29T17:50:00.000-04:00

I now have a blog for work related things, finally. I found my company's "Social Media & Blogging Guidelines," document and we're allowed to blog. We have to keep things appropriate, of course, but otherwise we are golden.

So I work for ~~GE Energy, Nuclear~~GE-Hitachi Nuclear Energy Americas (ed: name change as of 4 June 2007) as a software engineer. I'm the responsible engineer for codes ranging from FORTRAN 77/90, K&R C, C++, VB, VB.Net, Java, and C# 2.0. Mostly I work on GUI's (C# and Java) and support libraries (C, C++, FORTRAN, C#, Java), however, being a jack of many trades I also get in on the technology codes in FORTRAN.

Our systems range from Windows 2000 and XP on the desktop, Windows 2000 and 2003 on the servers, OpenVMS 7.X and 8.X servers, and a few scattered Linux/HP-UX/Tru64 boxen. We're trying to consolidate all of these systems, but personally I would rather the effort be placed on insuring interoperability across all of them (while least common denominator programming is at times frustrating, it keeps your code simple and most of the time easier to debug).

I spend a lot of time ensuring that our software remains well integrated, mainly utilizing API's which were set in stone before I was born. I get called upon to debug the crazy situations which happen when you bring together such an unholy trinity as FORTRAN, C, and C#. Yet the work is challenging and fun; my biggest grief being hard to find bugs and managing to break things which should not break. Ok, I lied, my biggest grief is procedures, but I think any engineer will tell you that.

I will be posting lots of technical issues that I come across and how I made it around them (or why I cannot seem to get around them). We'll see how this goes.