Wednesday, December 26, 2012

What Are The Signs of Bioreactor Contamination?

For animal cell culture, look to dissolved oxygen (dO2) for signs of bioeactor contamination.

Animal (and certainly plant) cells grow more slowly than bacterial cells.  A population of animal cells will double once per day (specific growth rate ~ 0.70 day-1), where as bacterial cells can double as fast as once every 20 minutes (specific growth rate ~ 70 day-1).

Bacterial cells that make their way into a bioreactor (be it because you failed to kill them or because you failed to keep them out), have less cellular infrastructure to maintain, and when they find a nutrient-rich, oxygen-rich environment, they will multiply until the excess oxygen in their environment is exhausted.

Have a look at this batch:

dissolved oxygen contamination
What's plotted here is dissolved oxygen (blue) and volume (dark blue).  We inoculate the bioreactor and the dO2 falls to set point.  Once it hits setpoint, the controller comes on and maintains the setpoint by adding air or oxygen (blue line goes flat).  But a few days in, you can see that all of the sudden, the dissolved oxygen crashes for no reason.  This is usually the first sign of contamination... when dO2 in the culture gets consumed.

Let's have a look at the same trend, except with dO2 controller output also plotted.
dissolved oxygen contamination
You can see that the controller is gliding along on a slow upward path.  And then all of a sudden, an inflection point and then it shoots to 100%. (She's all I've got captain!)  And even at 100% controller output, the culture's dissolved oxygen still gets exhausted.

Watching the dissolved oxygen trend is a daily task for campaign monitoring.  If you're looking at these trends, you ought to be able to detect a contamination.

Of course, verify that the culture is contaminated by sampling the bioreactor and sending it off to QC Micro(biology).  They'll tell you for certain whether the culture is contaminated.

But you can use these trends to tell you when to suspect contamination.

Additional Reading:

Friday, December 21, 2012

Use #FDA 483s to Your Advantage

If you have a minute...

One thousand FDA Form 483s are in the FDAzilla 483 Store.

As they say, "A smart man learns from his mistakes.  A wise man learns from others' mistakes."

Disclosure: Zymergi LLC receives nothing from FDAzilla sales.  They are a licensee of our software and we think they add signifcant value to commercial cell culture.

Thursday, December 20, 2012

Gun Violence Is Not a Univariate Problem

The public seems to have a hard time debating multivariate problems.

I remember the Ford Explorer/Firestone Tires issue years back very distinctly.  Was driving a Ford Explorer the cause of the SUV flipping over?  Those who say Ford was culpable pointed to the fact that few other SUVs were flipping over.  Ford pointed out that there were Explorers that weren't flipping over... just the ones with Firestone Tires.

Firestone was saying that there were plenty of cars driving around on Firestone tires without issue and it was Ford's fault that their SUV sucked.

This debate went on and on.  What my boss when I worked at Genentech Vacaville, Jesse Bergevin, said to me at the time was that this was a classic multivariate problem with one interaction.

Likewise, gun violence in America is a classical multivariate problem: there are not one, not two, but many variables that contribute to these horrific events.  And like most complex systems, gun violence is many variables coming together (interacting) for a specific effect.

  • When it comes to gun violence, we know that guns are a factor... as in, were it not for guns, we wouldn't have gun violence. (Yes, we'd have some sort of other violence).
  • We also know that mental illness is a factor.  After all, not all gun owners are going around shooting up malls and elementary schools.
  • We also know gun-free zones are favorite targets for gunmen with bad intentions
We know of these factors.  And we know that they interact.  To treat this issue as a univariate problem will change the response.

The right thing to do is to model the system and optimize for least number of gun-related deaths.

In the meantime, I will be thinking often of the children who died at Sandy Hook Elementary.  When I think of them, there's this vacuous hole that fills my stomach and my skin feels numb.

We must solve the problem of violence in our society; but we can't afford to do it wrong and treat it as a univariate problem (i.e. ban guns and be done with it).

Friday, December 14, 2012

#GoogleMaps for #iPhone at 40,000 feet.

So I'm flying back from a client site yesterday and I'm on one of these Southwest airplanes with WiFi.

It was a 1 hour 20 minute flight and probably less than an hour for web surfing time, so I figured the cost wasn't worth it.

But I connected to the WiFi anyway and Southwest lets you go to their mobile website, track their flights.

Well, earlier in the day, I read that GoogleMaps for iOS6 made its debut and had downloaded it.

So I figure I'd kill five minutes checking it out.  So I'm at 40,000 feet, and it slowly dawns on me that I can zoom in, zoom out and pan to wherever I want in the world.  So I tried to see if GoogleMaps could find my location... and it did.

The GoogleMaps App must be getting data across the Southwest WiFi.  And since Southwest blocks port 80 (i.e. so you cannot surf the internet without paying them their 5 bucks), GoogleMaps must be working off some other port.

Here's me somewhere over a field in California's central valley:
Google Maps App iOS6

Here's me a few seconds later:
Google Maps App iOS6

And I'm clear in another field a few seconds after that.
Google Maps App iOS6

This GoogleMaps visualization was so cool because I could see what the land actually looked like below (in Satellite mode).  I could fly as high or as low as I wanted to (zoom level).

For the remaining 20 minutes of the flight, I was no longer a weary software consultant in seat 17E...  I was Superman blazing across the Central Valley fields.

Too bad we had to put away our electronic devices in preparation for landing, otherwise I'd have watched it the whole way.

Great job, Google Maps... Well done.

Related articles:

Tuesday, December 4, 2012

How the @OSIsoftPI System Tracks Time

Here's a primer on how PI tracks time.


The first thing you need to know is that everything is archived Greenwich Mean Time, so it doesn't matter what timezone the server is in. It doesn't matter what timezone you're in. Everything gets archived GMT.

When you create a PI point, you have to tell the PI server what data type it ought to store with the pointtype attribute. This is important because some data types can be converted to others while others cannot. Date/times happen to be one of those that can be tracked in at least two ways:

Time as Integer

One convention that PI uses to track time is using integers where the numerical value refers to the number of seconds since 31-Dec-1969 16:00. I'm not entirely certain of the significance of this date.... maybe prior to this date, no computers existed? Whatever the case, 0 refers to 12/31/1969 @ 4pm.

To get Jan 1, 1970 @ midnight, that's 8-hours. So 8 hour is the same as 480 minutes... which is 28800 seconds. So if you wanted to write the date 1/1/1970 to PI using integers, you'd send the numerical value 28800 as the timestamp field.

Time as Float32

Another convention that PI follows to track time is using floating points where the numerical value of the floating point refers to the number of days since 1/1/1900. Incidentally, this is the same as the Excel convention.

As an example, Marty McFly goes back on 5-Nov-55 (11/5/1955). To figure out what this is in the Float32 format, you simply do this:

1955 is 55 years after 1900... so 55 years * 365 days per year = 20088 days

Credit ©1985 Universal Pictures

November 5th is the 309th day of the year, so 20088 + 309 = 20398

Handling Local Time

PI uses the local time of the PI server or the local time of the PI client (ProcessBook as it were) to figure out how to display the time.  No data is deleted because all of it archived against GMT.

So take the silly American ritual of Daylight Savings where during the summer hours, we adjust our clocks forward and then in the winter, we adjust the clock back.

On 11/4, when we got to 2am, we set the clocks back to 1am and repeat the time from 1am to 2am.  This is what it looks like on PI:

OSI PI daylight savings
You can see that in the 1-day period between 11/4 and 11/5, 1.04 days is shown.

You can also see in the sinusoid trend (which is based on local clock time apparently), the trend repeats the hour between 1am and 2am.

In summary:

  • PI works off of GMT and the translation to local time depends on your computer or the PI server's local time.  
  • PI can store timestamps as integers representing seconds since 12/31/1969 @ 4pm
          - or -
  • PI can store timestamps as float32 representing days since 1/1/1900