Showing posts with label data analysis. Show all posts
Showing posts with label data analysis. Show all posts

Tuesday, September 25, 2012

Stuck in the middle with you.....

So, due to recent research efforts, the path to enlightenment - well, at least, reasonable progress on a project - has become clearer.  Of course, it entails going back and preparing otherwise identical samples, albeit with a different labeling scheme.  Naturally, this will require some optimization.

In other news, I've recently been inspired to think about how to characterize extremely nasty and messy mixtures of appallingly complex and egregiously sensitive molecules.  My initial thought was that I should just let other people do this sort of thing.  However, I had a number of uncharitable thoughts about certain areas of the research community and realized that I should think more carefully about this situation.   I then had the notion that I need to do what my blog name suggests and think about things with less than precise site-specific chemical resolution for a bit.  I can layer on some perfectly reasonable physical parameters and other particular measures of interest.   Some people will complain, but then again, there are always those sorts.

Another unrelated topic I've been pondering - just how "open source" is chemistry?  How many of us have data trapped in proprietary formats in backup discs or external hard drives?  How often have you had to grudgingly use readily available software in ways it should never be used since more appropriate software doesn't exist or is egregiously expensive for the extent one needs it? Any information, griping personal anecdotes,  or interesting reads on the topic would be appreciated.

That will be all for tonight, I'd say.

Read more!

Saturday, December 10, 2011

Chemists, controls, and computing.

I have no experience with drug discovery, so I suggest one reads the excellent commentary offered over at The Curious Wavefunction and In the Pipeline inspired by a recent article on the role of computer simulation in pharmaceutical research, presuming that they haven’t already done so. What I thought was interesting enough to post about in response is in Wavefunction’s blog post.

They are reluctant to carry out the kind of basic measurements … which would be enormously valuable in benchmarking modeling techniques.

Methods development research can be difficult to support. Even obtaining modest funding can be difficult. It’s one reason why it can usually seem incremental in nature, as it’s easier to scrounge a few small devices or specialty materials to use with existing research infrastructure. This one is near and dear to my heart, as I have two such projects going on at the moment, and a third which is still in the planning stages. Unfortunately, it’s not the kind of stuff one could convince people it needs to be funded and generously at that. That was really more just me griping. But that is par for the course for me here at my blog…..

Unlike chemists, engineers are usually more naturally inclined to learn programming and mathematical modeling. Most engineers I know know at least some programming. Even if they don't extensively write code they can still use Matlab or Mathematica, and this is independent of their specialty (mechanical, civil, electrical etc.). …The lesson to be drawn here is that programming, simulation and better mathematical grounding need to be more widely integrated in the traditional education of chemists of all stripes, especially those inclined toward the life sciences.

I of course agree, but am inclined to mention a few things. This may be an artifact from my recollection/experience and is no longer the case, but I’ve seen a tendency for computational methods & applications courses intended for chemists to be heavy on the typical computational chemistry aspects (basic electronic structure calculations, a dash of MD, some molecular mechanics) along with a fair bit of introductory programming. Not that there’s anything wrong with that….but wait, actually, it is problematic.

I would think a more useful course might still contain some introductory programming and some of the typical computational chemistry, but I’d like to think that one could also take the time to introduce the students to chemo/bioinformatics as well as a module on proper data fitting. Of course, it might be claimed that it’s better suited for an upper-division chemistry laboratory, which would be fine. The important thing is to get people weaned from MS Excel and to actually start fitting data, not algebraically torturing your data until it’s in a format that can be linearly plotted and then fit with Excel.

Also, given that I have this notion of this course being something that all students will probably find useful in the future, the programming and software elements should be those that will easily lend themselves to a broad range of applications and uses in the future. I would imagine that introducing students to something like Origin or Igor Pro would be useful, as well as (re)introducing them to Mathematica, Matlab, Maple, or other comparable software. While the power of Fortran is well established for the numerical-heavy applications in computational sciences, I feel it would be better to have students introduced to something like Python. You can leave the Fortran for those who want to do the computationally intensive theoretical chemistry, while I’m sure the majority can use Python as a useful tool in their work.

This above is clearly influenced by personal biases (I'm a bio/physical chemist who is in the process of adding "systems biologist" if he keeps it up for much longer), but I think that sort of mix in a "computers & chemistry" course would serve a good cross-section of the chemical community. Any and all commentary, feedback, suggestions, and brutal eviscerations of my points are welcomed. Read more!