服务器发生故障，导致pFind的网站无法访问，我们正在修理硬件。这期间用户无法注册下载pFind Studio 2.6产品。我非常抱歉。
您可以先给pfind at ict dot ac do cn发一封邮件，咨询有关信息，索取软件注册的相关文件和表格进行填写。网站恢复后，我们会在第一时间通过邮件通知大家下载安装包。感谢朋友们一直以来对pFind的支持和帮助。
pFind网站发生故障
Leave a reply
Tag Archives: pFind
哪吒和太空镜子
上月底哪吒第一次对合作伙伴提供在线服务。开始和hchi哥、lyz美女折腾pFind@MapReduce。
以前写过思路，pFind原本是一个计算密集型的应用，面对擅长IO密集型的MapReduce模型，不只是把MPI版本代码移植过去那么简单，要从根子上重新设计整个框架。刚好hchi哥经过近半年的思考和实验，在算法上有了突破性的点子，我们一拍即合，开始动手干。
如果成功，pFind 3.0的架构就与信息检索领域的那些典型应用（例如Google搜索引擎）很像了，把目前的第一代蛋白质鉴定搜索引擎落下半里地。当然，刚开始做，有不少算法和工程问题需要啃。等待我们的论文和专利吧。
晚上陪老婆在小区里散步，看天上的星星发呆。然后对老婆说：人类可以在太空里建立一面巨大的镜子，用来挡住北京城的阳光，天气就没那么热了；反过来，能挡住就能反射，可以向阴冷地区或夜间的灾区送光；再邪恶一点的话，能反射就能制造成透镜，当成武器，瞬间聚焦地面某个区域，甚至融化南北极……老婆没有照例说我是邪恶的理工科，而说，你该写本科幻小说赚钱。这念头并不新奇，估计已经有人写了，甚至申请专利也说不定（用Google搜索全球专利，会发现很多有趣的奇思妙想）。回来一搜，果然刘慈欣已经写了这篇《中国太阳》。
由这个链接，发现42qu已经上线新版本了。
说到刘慈欣的小说，还有一件事值得敲出来。小学二年级的外甥壮壮很聪明好学，喜欢读书。前两天发现他在读《三体》的第三本。刚开始觉得，对小朋友来说这是不是太黑暗绝望了。转念一想，别太低估他们的心智了。倒是发现周围有些成人很少深度思考，只顾着纠结眼巴前那点儿事，应该找机会跳出来读读超脱点的文字。
想上来列书单，最近忙，原以为不会看太多新书。没想到一整理有十几本，还是太久没写BLOG。懒，明天再说。
LINPACK和WINE
最近在忙哪吒提供在线服务的事。全都是配置集群节点SSH、NFS、MPI和编译安装各种库这种杂事。
今天刚刚在集群上编译通了LINPACK和ATLAS两个数值计算的库。以前总在超级计算机排行榜的新闻里听到LINPACK的大名，这下有机会见识了。ATLAS编译时间好久，针对硬件做很多优化设置（Automatically Tuned）。本科学线性代数的时候总逃课去上网和编程，没学扎实。工作以后才发现，只要稍微涉及一点科研的事情，数值计算就缺不了。不懂这个的程序员，感觉工资都会少一截。连有关黑客电影都叫The Matrix。关于这个问题，参考孟岩2006年的经典BLOG《理解矩阵》。
移植工作的拦路虎之一是COM控件的问题。某质谱仪器公司的数据格式是私有的，必须用他们提供的控件去读。悲剧的是，他们只提供WIN32下的COM控件。上个月他们公司的软件部门负责人来中国访问，问他，答曰Win64很快会提供支持，但是Linux近期内不打算支持。悲剧呀。
所以就在考虑如何在云平台里解决这个问题。一种方案是在用户的桌面导成公开的文本格式再上传，但是这样影响用户体验，尤其是对那些数据量很大的用户，数据导出（和校准过滤）本来就是他们使用云计算的可能原因之一；另外一种方案是在服务端放一台Windows，专门转换数据，或者更玄一点，用虚拟机伺候，以便维护和并行；最后一个方案是用WINE，这个能搞通，当然是最好的。
还有若干软件的BUG等着解决。组里又都在忙着分析数据，四脚朝天，抓不到人手来帮我。哇哇哭。
像上次说的，一旦干起来，就有大量实际问题要解决。奋力开路中。
敬畏自己的代码
我一向对zf非常赞赏。zf在5年前刚来组里，不夸张地说，编程能力很弱。我记得是我告诉他应该用delete[]删除数组，而delete会导致内存泄漏。但是现在，同样不夸张地说，他写的每一行代码都是精品。BOSS H以前说：“joyfire的意思，好像如果zf愿意加入他的团队，他就有胆子去月球”，没错，我就是这个意思。
为什么？简单统计了一下，zf总共提交了17万行代码（当然，我统计的方式很简陋，有很多代码在不同版本重复提交，也有很多是临时性脚本，和一线实战的工业级产品不同），他的pParse（包括此前的pCompare）大概进行了39个版本的迭代重构和不断改进。组里有很多编程天才，在SVN提交代码是爆炸式的（例如我经常惊叹，hchi哥能在一下午敲出我一周的满载工作量）。但zf是独特的，他在SVN里提交代码量统计，永远是一条平稳的直线，每天，每周，每个月……这家伙最让人感到恐惧的，就是近乎机械的执行能力。
这不仅仅体现在他的代码上。我记得BOSS H有一次说他“过于内向，不敢发问，不善交流，会制约自己的发展”。那以后，我注意到，每次报告，无论规模场合和内容，zf必会举手向报告者提几个问题，一开始显得很勉强，时间长了，性格居然都变了。现在这家伙去全是老外的万圣节聚会上扮演凯撒大帝，谁敢再说他的内向障碍发展？BOSS H说，最早是在走廊上捡到个面试其他导师失败的彷徨考生，这么多年下来，zf教育了他这个导师。
能进我们组的新生，很多都得过ACM或者各种比赛的金、银、铜、铁奖。但并不一定实现过真正实用的大系统，达到合格软件工程师的标准。前两天发邮件给全组，以zf为例子，建议大家踏实一点，敬畏自己的代码，最终有本事在pFind代码里，留下自己的长久印记。
“哪咤”系统第一个milestone明天组内alpha发布
最近半个月和zf双人编程，全力开发“哪吒”系统。
和Web搜索引擎不同，pFind有自己的专业特点，最大特点就是要求尽可能高的查全率和查准率：平常Web搜索，大多数用户很少翻看三、五页以外更多的搜索结果。而对我们这个领域而言，质谱仪器原本就有很高的精度，数据集里那些含量稀少信号相对较弱的蛋白质，却往往正是科学家和医生们最重视的研究对象。pFind引擎有几十个参数，虽然很多默认推荐值经受过数百万数据的考验，但是在具体数据集上总会有优化的空间。
也就是说，花费上万块钱成本得到珍贵实验数据，不能只拿pFind引擎常规参数“一搜了之”，需要进一步大量深入分析。例如过滤和校准质谱数据，极端情况下通过数据发现前端实验过程和仪器维护中的问题，回去重做实验；再如进行初次试搜之后，对鉴定结果进行统计分析，优化参数，改变选项，再进行迭代搜索；又如，利用多种搜索引擎交叉验证，甚至是多种方法结果的相互对比验证（例如常规的基因翻译蛋白序列库搜索引擎，最近新兴的谱库搜索，以及探索性最高的de novo算法）……
深入解析依赖人工工作大大降低了效率。随着pFind的进展，我们与越来越多国内外生物学家建立了合作关系。然而每月收到成T的数据，每周要提交的分析报告，海量的工作量，把所有人都压垮了，不得不放弃很多送上门来的合作机会和经费。
数据解析的全流程自动化，国际上都在全力探索。例如现在红得发紫的Maxquant就做得不错。pFind组有不错的基础，由于有牛人yfu和他那一帮超常的算法研究天才在，我们在谱图搜索、de novo、修饰发现等等方面也有自己的独特之处。至于工程能力，生物实验室那些非计算机专业作者用C#写的桌面级别代码，要进一步拓展到大规模集群，甚至通过云计算提供在线服务，还差得很远。而这方面是计算所的长项。在超级计算机并行加速方面，我去年论文成果数据的可拓展性达到了320核，不谦虚地吹嘘，超过了全世界竞争对手目前为止公开报告数据效果一个量级，其实我已经做到了1000核，马上要做2000核。
通过pFind云提供对外服务，这始终是我的梦想。为此努力了5年，今年终于开始着手了。也许，它能成为未来生物医药数据处理的基础构件之一。
要建立实用的平台，就需要把方方面面的工作集成起来，解决大量很有挑战性的难题，例如单从并行加速这一个技术需求来看，不再像加速pFind搜索引擎这一具体环节这么简单，需要考虑整个流程各个环节的不同特点：在海量数据吞吐的地方，如全基因组翻译和索引，用得到MapReduce这一套；而打分鉴定这种95%CPU的工作，需要精心设计MPI类的程序；另一些特别的算法，例如de novo里面的动态规划，也许得考虑GPU加速……其实，加速还是最好做的事。
加班很累，一写BLOG又兴奋了，也是最近密集开发，没空上网，想写的东西比较多吧。明天带“哪咤”的雏形出来见人，这个平台尝试把组里pFind、pBuild、pCluster、pMatch、pXtract、pParse、pNovo等等主力软件串联起来，无人值守的对海量数据进行尽可能全面的挖掘，我们希望听取各位的意见。
挤地铁、堵车和zf双人编程
最近家里的网络有些故障，所以没怎么写BLOG。
早上从家里到单位居然开了将近两小时，实在太堵了。沿路看到好多追尾、刮蹭的事故现场，交警叔叔真辛苦。
09年以前，都是错开高峰坐地铁上下班，路上还能读小说。但被BOSS H骂，严令必须按时上下班，只好和别人一样7点出门，18点下班。地铁线路开通越多，感觉越像地狱。不止一次衣服被撕破，电脑背包带被拉断，背肌痉挛。去年10月的一天，不得不中途提前下车，找卫生间去吐，于是终于下了决心考照买车。刚买到，北京就摇号限牌了。和06年买房子一样，大家说我运气好，总能赶上趟。其实很多滋味只有自己知道。
每周限行那天，早上需要在天通苑地铁站入口的这个S形通道里煎熬40分钟
这些天除了在超级计算机上调试新一版的pFind，就是和zf一起双人编程，构建一个平台，把组里pFind、pXtract、pMatch、pParse、pNovo、pBuild等等这些都整合起来。按照惯例，zf会给它起昵称，我想和zf商量叫“哪吒”，三头六臂，掌握很多种不同武器的样子。zf编程很老道，所以交流起来很放松。双人编程这事儿和很多合作一样，最关键要价值观一致，看到bad smell不肯妥协。同时越写越喜欢python，写出来的东西很干净。
另外，老妈原单位一位同事的儿子突然猝死了，我记得比我小一点。上上周小曾跑pFind集群，周末加班没搞通，结果第二天就住院动手术了（人民纷纷血泪控诉我的压迫，这个，冤啊，真不是pFind集群折磨的……前几天和管理员一起安装Sector/Sphere的时候偷眼看了一下，他好像把$PATH环境设错了）。大家要注意身体。
简报，pFind两大牛人：yf和rxsun
fy大侠的文章“DeltAMT: a statistical algorithm for fast detection of protein modifications from LC-MS/MS data”在MCP上发表了，这是三年里的第二篇。而且相对第一篇，这一篇完全偏重算法。各界人士纷纷发来贺电。已经身在360，不准用QQ的第二作者袖子也特意写了一篇BLOG。
总在讨论战略、文化、策略神马的，其实都是浮云。能像fy这样，攻必果、战必克，有计划必有执行，有执行必有结果，就是所谓的Good to Great了。一年多，三次Revision，不管过程怎么痛苦，需要拼的时候能砸锅卖铁点灯熬油，需要忍的时候能卧薪尝胆持之以恒，最终咬牙扛过来。
不断创新是pFind的唯一活路。虽然有各种不同的声音，我个人强烈认为，新一代蛋白鉴定搜索引擎的最大特点之一将会是修饰参数的智能推荐功能。
rxsun刚通过投票成为iPRG member。此前Mann的论文里说，好的赛车需要好的赛车手。iPRG 2011比赛的题目是ETD，从结果来看，竞争很激烈。
pFind Studio 2.6发布
pFind Studio 2.6已经在网站上正式发布。2.6版根据2.4版发布以来收到的用户反馈，着重提高了软件的易用性和稳定性。欢迎大家注册下载。并祝大家新年快乐。
pFind单机版新界面
pFind引擎的第四代索引模块
因为CNCP2010，同时也有些私事，最近很忙。live spaces又拆迁。所以BLOG节奏受影响。这周末陆续敲点流水帐。
首先要祝贺zhch的后缀数组论文经过一年历练总算被BMC Bioinformatics接收。相关专利也提交了。（在这之前，sun老师的ETD论文也发表了，BOSS H昨天说，今年一年组里发了6、7篇，快等于此前几年的总和了）。
pFind搜索引擎的索引技术一直不断传承和推进：dq老大最先奠定基础，推出IndexToolkit开源项目并在Bioinformatics发表Application notes；之后ly哥凭借不懈努力吃透了倒排技术，重构了索引模块，发表论文申请专利；接下来zhch凭借ACM金牌的强悍算法功底继续前进，先是将倒排索引的数据容量上限提高了几个数量级，然后又另辟蹊径引入后缀数组技术，颠覆了前人的工作。
年底推出pFind 2.6之后，我们将着手把zhc的模块从develop分支移到release分支。这是pFind的第四代索引了。当然这只是刚开头，它必须通过全面严厉的测试，才能证明自己有资格替代老版本索引，在工业级产品中担当主力。
即将到来的pFind Studio 2.4.2版，还有CNCP2010大会
还在单位加班，在等一个漫长的测试进程结束，登录上来敲点BLOG。
之前说过，下半年的一个重点就是提高pFind Studio的产品质量。七月份的2.4.1版还是不够令人满意，最近除了忙知识产权的工作以外，就是逼迫几个主力继续不断测试，修改BUG，提高用户易用性。BugFree里的统计曲线不断创造新高，几位辛苦了。pFind Studio 2.4.2版比计划拖延了将近一个月，昨天提交了pFind Studio 2.4.2 RC3供组里验收，希望这次不会被打回来重写作业。当然，这次我比较有信心能通过投票。
越是到这个阶段，越觉得熊节的这篇《把事情做完》有道理。
这个版本发布，刚好可以赶上计算所主办的“首届中国计算蛋白质组学研讨会”，这次会议邀请了众多国内最出色的团队来作报告。为了保证质量和学术纯粹性，拒绝了很多公司的商业赞助。到目前为止，报名的踊跃程度大大超出了我们的想象，不得不更换原定的会场。提醒大家，尽管为了促进交流不收任何注册费，还是建议想参加的朋友提交参会回执，如果到时候不得不限制人数的话，不至于受影响。会前培训的名额已经快接近场地上限，大家要抓紧了。
请期待最新一版的pFind Studio 2.4.2，希望在11月的研讨会现场见到各位老朋友。