【防火墙源码框架】【暴走熊猫源码】【想做笔记源码】dpm源码
1.dpmԴ??
2.曳力在CFD-DEM流体动量方程中的处理 （以MFiX和OpenFOAM为例）
3.流体颗粒耦合（CFD-DEM）求解器 sediFoam 简介和安装步骤
4.Wind River产品与服务
dpmԴ??
在研究推荐和排序算法的过程中，DSSM（深度结构语义模型）是不可或缺的一部分。本文将详细介绍DSSM及其变体CNN-DSSM和LSTM-DSSM。
论文链接：microsoft.com/en-us/res...
源码：github.com/baharefatemi...
简介
现代搜索引擎在检索文章时，通常将文章中的关键字与query中的内容进行比较。然而，防火墙源码框架这种做法存在一个问题，即文字具有多义性，同样的含义可以用多种表达方式进行表达。因此，我们需要对query和document进行语义上的相似度匹配。
通常，我们会使用隐语义模型LSA、LDA来衡量Query和Document之间的相似性。然而，由于LSA、LDA是无监督学习的模型，这些模型的效果并不符合预期。基于隐语义模型，有两种扩展：第一种是使用BLTM结合DPM来拟合query和document之间的关系，另一种方法是采用深度模型对query和document进行自编码，但这两种方法都是无监督的方法。
本文针对搜索场景，提出了一系列深度网络语义模型（Deep Structured Semantic Models），模型的暴走熊猫源码核心思想是：首先将query和document映射到同一个低维语义空间，然后通过cosine来计算query和document之间的距离。与之前的无监督学习模型不同，DSSM使用document的点击量进行训练，因此DSSM的效果要优于其他无监督模型。
接下来，我们来看看DSSM是如何对query和document进行处理的。
DSSM的结构采用DNN结构，将输入的query和document转换到低维的语义空间，然后计算他们的cosine相似度。
语义特征计算部分，首先使用DNN网络将query和document从高维的空间转换到低维的空间。对输入的query和document假设他们是x，经过转换的向量为y，[公式]表示隐藏层，[公式]分别表示隐藏层的参数和偏置。
最后一层采用tanh函数作为激活函数。最后将query和document映射到低维向量之后，我们采用cosine计算他们的相似度。
为了解决query和document在第一层维度非常大的问题，本文提出了word hashing的方法，来对文本进行降维。做法就是使用n-gram来表示一个词语，例如good，我们把它拆分成trigram：go goo ood od。想做笔记源码
为了训练DSSM，我们需要得到query和他们对应的点击的document。作者假设如果用户点击了某个document，那么这个query和document就是相关的。因此，作者认为DSSM的目标是最大化给定query所对应的document的条件似然函数。条件似然函数的计算方式为：[公式]。其中，[公式]是平滑参数，D是针对query的所有可能相关的document集合，[公式]表示和query有关的且用户点击的document。
有了以上的介绍，我们所要最大化的条件似然函数就是[公式]。因此，loss函数就是：[公式]。文中作者采用梯度下降法来最大化loss函数。
作者收集了现实生活中用户搜索的日志作为实验的数据集，这份数据包含条用户query，平均每条query包含条url。每一个(query, document)的相关性分为5档，分别是0~4分，得分是人工评价的。模型的排序效果通过NDCG来衡量，这是行人计数 源码推荐系统常见的评价指标，具体就是评价推荐给用户的内容是否是用户感兴趣的，而用户的阅读习惯一般是从上到下，所以我们希望将最相关的内容排在前面，然后以此类推。
实验效果如下，其中：首先我们可以看出DSSM的效果优于其他模型，并且L-WH DNN的效果是最好的。
DSSM是搜索里非常经典的一个算法，在工业界也广泛被使用。而且，根据应用场景的不同，对特征处理也会有一些区别。例如，在推荐召回模块的应用中，我们的输入可能就不再是query和doc的word embedding，而是用户和推荐的物品（例如**，商品）的特征。
本文依然是由DSSM的作者提出，在语义特征计算部分采用CNN网络，网络结构如上图所示。在词向量的表达上依然采用了word hash（不知道为啥作者对word hash这么执着）。
不过，trigram表示不能忽略了文本的上下文信息，因此作者在word trigram的环保平台源码基础上增加了letter trigram。在一定的窗口大小内，对该窗口内的word进行拼接就是letter trigram，例如I have an apple，可以被拼接为 # I have, I have an, ... 以此类推。
然后以上表示经过卷积层，max-pooling，和全连接之后得到query和doc的低维向量。最后计算相似度的时候还是cosine距离。
本文针对CNN-DSSM无法捕捉长文本的上下文信息的缺点，引入了LSTM。同时在LSTM的cell中加入了peehole，LSTM的cell结构如上图所示。
与传统的LSTM不同，作者在遗忘门、输入门、输出门中都考虑了[公式]，总体来说考虑的信息更丰富。
曳力在CFD-DEM流体动量方程中的处理 （以MFiX和OpenFOAM为例）
曳力在CFD-DEM流体动量方程中的处理涉及多个方面。首先，右侧曳力Ug使用n+1时刻的值时采用半隐式方法，这种方法在动量方程中表现出良好的稳定性。然而，如果使用n时刻的Ug进行显式处理，整个曳力作为源项可能会对稳定性产生不利影响。
在MFiX文档中，所谓的显式耦合是指描述粒子曳力的方法。粒子在单个CFD时间步长内会经历多个时间步。这种显式耦合意味着曳力在单个CFD时间步长内不会被重新计算。
从我的理解来看，半隐式处理意味着在方程中的曳力项中，使用un+1的气体速度来隐式计算曳力，而不是显式地使用un。我相信这种数值处理已经在开源软件中实现了。
以下是在OpenFOAM和MFiX中的实现方式：
MFiX：请参阅文件中的方程
链接：mfix.netl.doe.gov/doc/m...
同时，您也可以查看源代码，其中曳力项被分为与气体速度相关的隐式部分（A_M）和与粒子速度相关的显式部分（B_M）。
1) 文件：solve_vel_star.f
2) 文件：gas_drag.f
3) 文件：drag_gs_des1.f
OpenFOAM：我没有找到DPMFoam实现的文档，但源代码表明它对曳力采用了半隐式处理，请参见突出显示的代码。Uc是气体速度，UCoeff()是曳力系数b，UTrans()是粒子对气体的曳力。因此，在SU函数的第行：
UTrans() - fvm:Sp(UCoeff(), U) + UCoeff()*U
可以简化为：
b(Up-Ug) - fvm:Sp(b,Ug) + bUg
简化后的表达式为：
bUp - fvm:Sp(b,Ug)
fvm::Sp使得源项隐式化，从而对对角线有贡献。
流体颗粒耦合（CFD-DEM）求解器 sediFoam 简介和安装步骤
<sediFoam是由弗吉尼亚理工学院肖恒团队开发的，它在OpenFOAM框架内实现了流体动力学（CFD）和颗粒动力学（DEM）的耦合，其在学术界和工程界获得一定认可。相较于OpenFOAM自带的欧拉-拉格朗日耦合求解器，如MPPICFoam和DPMFoam，sediFoam更擅长处理颗粒间复杂的相互作用，特别是考虑颗粒形状、尺寸及颗粒间化学反应的模拟。离散单元法（DEM）是稠密颗粒流体模拟的优选方法，它能够精确解析颗粒间的相互作用力。
sediFoam的核心在于使用LAMMPS软件处理颗粒间的相互作用，并结合OpenFOAM模拟流体运动。它自主研发了拖曳力模型和湍流模型，专门用于处理颗粒与流体的交互过程，提高模拟的精度和效率。
安装和编译sediFoam大致分为三个步骤：
1. **安装OpenFOAM**：sediFoam基于OpenFOAM 2.4.0版本构建，因此，建议使用此版本以确保最佳兼容性和功能支持。然而，要注意OpenFOAM 2.4.0与Ubuntu .自带的GCC不兼容，这需要对部分源代码进行修改。幸运的是，开发者Henry已确认不再在2.4.x版本中修复bug，并转至3.0版本。然而，通过访问openfoamwiki（openfoamwiki.net/index....）上的相关修正方法，可以顺利编译好OpenFOAM。
2. **安装LAMMPS**：选择特定版本，如lammps-1Feb，以确保与sediFoam的兼容性。按照sediFoam开发者提供的配置文件进行编译设置，这一步骤的细节可在xiaoh/sediFoam中找到。
3. **编译sediFoam**：在完成上述步骤后，按照xiaoh/sediFoam的指引编译动态链接库和lammpsFoam。最后，通过执行lammpsFoam -help命令验证编译是否成功。
值得注意的是，sediFoam的官方文档可能不够详尽，因此，遇到编译问题时，欢迎在评论区寻求帮助、提问或通过私信与开发者交流。
总之，sediFoam提供了一种先进的CFD-DEM耦合解决方案，尤其适用于复杂颗粒流体模拟。遵循上述步骤，结合社区支持和文档资源，能够成功安装并使用该软件，解决特定的工程和科研问题。
Wind River产品与服务
Wind River公司为了适应设备软件优化策略（DSO），采用了双操作系统（Vxworks & Linux）的解决方案。Workbench作为强大的集成开发环境，适用于多种目标机OS平台，包括Bootloader的开发、BSP/Driver的开发、上层应用程序的开发、测试和生产，直至产品的售后服务，贯穿产品生命周期的全过程。
GPP-LE产品集成了WindRiver验证过的开源软件，包括2.6内核和应用程序，以及相关补丁包。该产品还带有针对当前主流处理器体系结构的交叉编译工具链，使得用户能够编译出在目标机上运行的代码。
PNE-LE产品遵循OSDL CGL工作组的CGL specification V2.0，集成了超过个网络应用程序包和其他应用程序包。它以稳定的、验证过的Linux-2.6.作为内核。
PCD-LE产品具备动态电源管理技术（DPM）、基于FLASH的鲁棒文件系统（cramfs）、快速的系统启动时间以及较小的内核footprint。最小系统资源需求为k的flash和k的RAM。
Workbench作为开发工具，采用了基于Eclipse开放标准架构，可以方便集成第三方插件。支持多种目标机操作系统，如Linux、Vxworks、ThreadX等，覆盖硬件板子调试、BSP/Driver开发、应用软件开发和产品测试等全生命周期阶段。支持多种架构的目标机处理器，包括ARM、XScale、MIPS、PPC和X等。Workbench还支持源代码的静态符号解析，允许用户进行交叉代码浏览。
Workbench演示展示了其强大的功能和易用性，为开发者提供了高效的工作流程和丰富的资源。
