非关系数据库在现在网络以及一些特殊应用中逐渐被接受和认可，其中Kyoto Cabinet是其中的佼佼者。 Kyoto Cabinet是跨平台的NOSQL数据库，支持Linux/Windows等平台，可以以静态库或者动态库形式使用，遵循GPL协议。 Kyoto Cabinet支持多种数据存储方式，包括内存型与文件型。 内存型包括ProtoHashDB、ProtoTreeDB、StashDB、CacheDB、GrassDB，文件型包括HashDB、TreeDB、DirDB、ForestDB、TextDB。另外PolyDB可以动态绑定上述各种数据库形式。具体的规格参数以及性能可以参考官方文档http://fallabs.com/kyotocabinet/spex.html#features。 Kyoto Cabinet官方提供了makefile，可以直接在windows平台上编译。但由于使用了ISO C9x的标准，官方默认使用VS2010，如果使用vs2008编译，需要手动修改几个地方： (1) 补充stdint.h头文件（http://msinttypes.googlecode.com/svn/trunk/stdint.h） (2) std空间中的unordered_map,hash,regexsmatch等位于std::tr1空间 (3) 修改VCmakefile， VCPATH = C:\Program Files\Microsoft Visual Studio 9.0\VCSDKPATH = C:\Program Files\Microsoft SDKs\Windows\v6.0A 性能测试后续再补充。

2011年专业技术回顾-Q1 2011年专业技术回顾-Q2 2011年专业技术回顾-Q3 10. 2011年10月 国庆节只休息了3天，4号上班。 10月6日，乔布斯走了，一个传奇。 在9月的时候，有很多的进展。经过了地毯式的测试，有限元这一部分功能基本上完善，也很稳定。后面基本上是专题性质的专项计算的深入调优，包括了施工模拟分析、随机活荷载不利布置分析、局部人防模型分析，整体上不错。 其他的内容大体上有这几个，都做得非常好。 一个是上部结构刚度传递到基础计算中，这一块涉及到上部结构和基础两个模型的计算，我们做得非常巧妙，很智能。上部刚度的凝聚支持动态的凝聚参数判断，对于超大底盘的结构，能动态减少出口数量，在牺牲较小精度的条件下大量减少计算量。 在基础模型计算，也用了了很妙的机制，进行上部刚度矩阵凝聚结果的自动拆分为合适的MATRIX单元。 第二个是有限元程序自动支持进程内计算与子进程计算，可以混用。这样可以隔离一些管理和内存上的问题。两种模式下的进度log，数据管理等都完全不需要变化，这里又再一次很骄傲地受益于精良的程序架构。子进程方式下采用异步的log控制器，而且支持很先进的中断计算。 还有一个，在ICF中增加了一种模式，称为Transaction。 和经典的数据库一致，在开启Transaction后，读写性能会大幅度提高，而且Transaction是自治的，只需要开启关闭，其他的不需要有任何变化。 然后开始进行大规模题目的测试，上限已经达到100w自由度，很领先。 ——————————— 10月也是一个很好的月份，都很开心。 11. 2011年11月 这个月还是测试，测试，不提。 这个月又被要求加一个新的功能，基础计算中后浇带的模拟计算，很罗嗦。但是我们有先进的储备，死活单元+自动单元分组，很简单的处理就好了，抽象了一个局部模型分析出来，取名PartialModelAnalysis，很稳定。 然后还是继续改进，改进无止境。重构了下命令行参数的解析，定义通用的规则，后面的增加参数也不用逐个解析。 ICF逐渐成为了后处理的瓶颈，查到原因是频繁的缓冲交换，于是增加了一个多并发的Turbo模式，根据系统内存智能适应，效果很好。 目标总是一步一步被提高，从最初的要求能计算30w自由度，逐渐被要求到50w、70w、100w。而且随着多塔的要求，还要适应越来越多的振型。原先的有些设计是针对50w的优化设计，100w再加100个振型是不能承受之重。好在，谁让咱们的设计牛呢。加入内存映射，ICF同步支持，只需要局部的小量代码就可以了。 11月就这么多啰嗦事情。相对前两个月来说，这个月有时候并不是非常开心，难免有些低谷起伏，但是我是小强，我喜欢向前，喜欢努力，加油。 12. 2011年12月 资源是一点一点省出来的，就像钱要开源，更要节流。 除去优化之外，本月逐渐增加竖向地震的计算，这一部分由于以前糟糕的代码，加一点东西都会引入错误和不兼容。找到一个肯动脑筋水平又好的人真的很难很难。 由于Midas building和etabs的特点，本月决定把原计划下一版本的功能提前，就是根据振型参与质量来自动决断振型个数，Midas building的这个功能很赞，于是我们也有了。 ETABS的RITZ向量法在很多情况下会是一个比较好的手段，于是我们有了。 —————- 2011年要结束了，12月开心。 感谢2011。

在前一段时间考虑云服务的时候，大致整理了一个系统架构。只是业余工作，和公司工作无关。 借用了一下云服务的概念，目前通过服务端的程序为用户提供对应的数据服务。而整个架构是在满足工程计算方面的实际需求，而不进行过度设计。 1. 整体特点 UcoCloud架构如下图所示，主要包括web前端、Master主控服务以及一系列的Worker工作机。 UcoCloud以Master服务为核心，负责任务队列、调度以及Worker的管理，不涉及具体业务。这里的Master服务不同与Gate服务，如果后来业务需要可以增加Gate服务，从而支持多个Master。 Worker承担具体业务，可以不同类型，可以随时增加更多worker来增强计算能力。 Web前端只是一个Master服务交互的界面，与用户进行交互。 必要时可以增加专门的File Server。

无聊的技术笔记： 环境：VS2008 sp1 调试机(A)：win7 32bit         被调试机(B)： xp 32bit 即在B机上运行程序，A机上进行调试。 ———————————— 最简单的步骤如下： B机上 (1) B机上的建立一个与A机当前账户相同的用户名，密码相同，管理员权限。 (2) 在B机安装rdbgsetup.exe，位于VS2008安装光盘上，选择对应的OS类型。 (3) 在B机上打开组策略(gpedit.msc)，修改“网络访问：本地账户的共享与安全模式”，选择“经典-本地账户以自己身份验证” (4) B机上打开Remote Debuging Monitor A机上 选择Debug-Attach to Process Qualifier: 通过浏览找到对应B机。 注意 需要注意防火墙要对相关端口放行。 其他的就和本机调试一致。

TAR(Type And Run)是我一直以来所用的快速启动软件，最喜欢的是它那个快捷键呼出的超级简洁的命令行，而且TAR支持自动提取系统中已经注册的别名，比如excel就可以打开excel，mspaint打开画图。另外TAR支持插件，最常用的就是tar_math，可以对输入命令行的计算式进行计算，给出结果。 当然tar_math也存在缺点，那就是对大整数不支持，而且函数也不够丰富。另外还想增加一个查字典的功能。于是决定给TAR做个插件，取名叫tar_pytar。tar_pytar不只是个插件，而是一个python的接口插件。有了这个插件之后，就可以直接用python给TAR增加功能，而不是重新编译。 官方网站上有插件接口文件找不到了，于是给作者-=GaLaN=-发邮件要来了接口。TAR是拿Delphi写的，不过没关系。 时间紧张，只说明一下tar_pytar通过python接口提供的功能： 完整的math功能，完全可以取代tar_math。因为背后是python嘛。 词典功能，输入查询的英文单词，可以返回中文解释。（从dict.cn查询，同样感谢python的强大） 以后： 作为一个工作的中心，就是一些人对待emacs/tc的态度。

有一段接近1000行的Fortran77程序，需要在一个新程序中重用，而且非常不想编译新程序的时候还需要fortran编译器，而且为了日后维护方便，也不想把它弄成静态lib。于是决定把它转换成C程序。 以往都是手动转或者看懂后重写，不过这段计算复杂，而且有不少隐含变量，还有equivalence语句，于是找到了f2c这个工具，使用效果非常好。转换后的结果可以直接编译，而且通过简单的处理也可以去掉对f2c.h的依赖。 f2c的主页在：http://www.netlib.org/f2c/，提供源代码和二进制文件下载。 f2c完整源代码(126KB) f2c的mswin平台命令行(131KB) f2c使用说明 f2c更新记录   其实f2c的使用方法非常简单： f2c [ option ... ] file ... 一般option取默认即可，如 f2c romform.f 。 需要注意的是，fortran的文件后缀必须是.f或者.F，.for是不认的，而且严格执行72列的限制。