-
Notifications
You must be signed in to change notification settings - Fork 0
/
search.xml
283 lines (283 loc) · 31.3 KB
/
search.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
<?xml version="1.0" encoding="utf-8"?>
<search>
<entry>
<title>Docker常用命令合集</title>
<url>/7e70837c2992/</url>
<content><![CDATA[<h1 id="概念介绍"><a class="markdownIt-Anchor" href="#概念介绍"></a> 概念介绍</h1>
<ul>
<li>Docker：是一个开放平台，用于开发、打包、交付（shipping）、运行应用。Docker允许用户将基础设施中的应用单独分割出来，形成更小的颗粒，从而提高交付软件的速度</li>
<li>Container：容器，可理解应用运行的环境，与虚拟机不同的是，容器为保持文件体积较小，可以只包含应用运行所必须的依赖库</li>
<li>Image：容器的镜像文件，当镜像未运行时，可以对其进行分享，构建等操作；当镜像运行时，才会创造容器环境（container environment），即Container是镜像的运行环境，注意二者的区别</li>
<li>Docker Hub：公开的容器镜像仓库，可以在其他云服务提供商付费获取私人仓库</li>
<li>Docker Desktop：Docker的图形界面软件，可以在图形界面上对镜像及容器进行管理；对于支持WSL 2的Windows系统而言，可以选择WSL 2作为Docker Desktop的后端，相较于Windows Hyper-V后端性能更好</li>
</ul>
<h1 id="基础命令合集"><a class="markdownIt-Anchor" href="#基础命令合集"></a> 基础命令合集</h1>
<h2 id="image相关命令"><a class="markdownIt-Anchor" href="#image相关命令"></a> Image相关命令</h2>
<ul>
<li><code>docker pull image_name:version</code> ：从Docker Hub拉取镜像</li>
</ul>
<span id="more"></span>
<ul>
<li><code>docker run image_name:version</code> ：运行镜像，镜像不存在则先下载镜像
<ul>
<li><code>-d</code> ：分离模式，即返回信息只有容器的ID</li>
<li><code>--name container_name</code>：对创造的容器环境命名</li>
<li>每次运行此命令都会创造新的容器环境，不同的容器环境ID不同</li>
</ul>
</li>
<li><code>docker images</code>：查看本地所有镜像</li>
<li><code>docker rmi image_name</code>：移除镜像</li>
</ul>
<h2 id="container相关命令"><a class="markdownIt-Anchor" href="#container相关命令"></a> Container相关命令</h2>
<ul>
<li><code>docker ps</code> ：查看正在运行的容器
<ul>
<li><code>-a</code>：此参数同时显示未运行的容器</li>
</ul>
</li>
<li><code>docker start container_ID</code>：重启容器，此命令不会创造新容器，注意与<code>docker run</code>区分</li>
<li><code>docker stop container_ID</code>：停止正在运行的容器</li>
<li><code>docker logs container_ID</code>或者<code>docker logs container_NAMES</code>：查看容器日志
<ul>
<li><code>-f</code>：日志流，即实时记录容器的日志并打印至命令行</li>
<li><code>| tail</code>：查看尾部几条日志</li>
</ul>
</li>
<li><code>docker exec -it container_ID /bin/bash</code>或者<code>docker exec -it container_NAMES /bin/bash</code>：进入容器的命令行环境
<ul>
<li><code>exit</code>：容器内部的命令行环境中输入此命令可返回<code>localhost</code>的命令行环境</li>
</ul>
</li>
<li><code>docker rm container_ID</code>：移除容器</li>
</ul>
<h1 id="高级命令合集"><a class="markdownIt-Anchor" href="#高级命令合集"></a> 高级命令合集</h1>
<h2 id="port"><a class="markdownIt-Anchor" href="#port"></a> Port</h2>
<ul>
<li><code>docker run -p localhost_port:container_port</code>：以此命令运行容器后，本地应用可基于<code>localhost:localhost_port</code>端口与容器进行通信</li>
</ul>
<h2 id="docker-network"><a class="markdownIt-Anchor" href="#docker-network"></a> Docker Network</h2>
<p>Docker Network：可以让同一网络下的容器之间依据容器名进行通信</p>
<ul>
<li><code>docker network create net_name</code>：创建docker network</li>
<li><code>docker network ls</code>：查看所有docker network</li>
<li><code>docker run -e XXX=xxx -e YYY=yyy --net net_name image_name</code>：指定容器运行时的环境变量和network</li>
</ul>
<h2 id="docker-compose"><a class="markdownIt-Anchor" href="#docker-compose"></a> Docker Compose</h2>
<p>Docker Compose：一次性运行多个容器，而不是在命令行中一条条开启运行。实现原理是将多条命令映射成结构化文件</p>
<ul>
<li><code>docker-compose -f filename.yaml up</code>：运行结构化文件中设定的所有容器，并且这些容器都运行在同一network中</li>
<li><code>docker-compose -f filename.yaml down</code>：暂停结构化文件中设定的所有容器，并移除它们及其所在的network，这样也会移除数据，无法保证数据持久化</li>
</ul>
<h2 id="dockerfile"><a class="markdownIt-Anchor" href="#dockerfile"></a> Dockerfile</h2>
<p>Dockerfile：依据结构化文件<code>Dockerfile</code>构建自己的Docker镜像，即将自己编写的代码程序打包至已存在镜像中，打包需要基于某个base镜像，注意名字必须为Dockerfile</p>
<ul>
<li><code>docker build -t image_name:tag .</code>：构建自己的镜像，后面的<code>.</code>为<code>Dockerfile</code>文件所在的路径
<ul>
<li>每次修改了dockerfile，都必须重新构建镜像</li>
</ul>
</li>
</ul>
<h2 id="docker-volumes"><a class="markdownIt-Anchor" href="#docker-volumes"></a> Docker Volumes</h2>
<p>Docker Volumes：于数据的长久保存，容器运行时数据储存在虚拟的文件系统中，每次重启容器文件会消失。因此通过将主机文件系统与虚拟文件系统挂载，所有文件将拷贝至主机文件系统，即可实现数据的持久化。</p>
<ul>
<li><code>docker run -v name:virtualdirectory</code>最推荐的挂载形式，只需为本地文件目录指定一个名字，具体路径由Docker决定，同样也可在docker compose中完成。
<ul>
<li><code>C:\ProgramData\docker\volumes</code>：Windows系统默认的本地挂载路径</li>
<li><code>/var/lib/docker/volumes</code>：Linux系统默认的本地挂载路径</li>
<li><code>/var/lib/docker/volumes</code>：Mac系统默认的本地挂载路径</li>
</ul>
</li>
</ul>
]]></content>
<categories>
<category>Tools of Programming</category>
</categories>
<tags>
<tag>Commands Collection</tag>
<tag>Development & Deployment</tag>
</tags>
</entry>
<entry>
<title>git简明教程</title>
<url>/bd540e03a768/</url>
<content><![CDATA[<p>Git是目前世界上最先进的分布式版本控制系统，此文章简述了Git的基本原理、代码版本控制、GitHub联动（远程仓库）、分支管理以及标签管理等内容。</p>
<p>Git安装后需要通过以下命令配置用户名和邮箱，被用于远程仓库记录commits的相关信息，即用于查询哪次提交是谁完成的，配置的用户名和邮箱<strong>不会用于</strong>push代码到远程仓库时的身份验证。 <code>--global</code>参数表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。</p>
<figure class="highlight bash"><table><tr><td class="code"><pre><span class="line">$ git config --global user.name <span class="string">"Your Name"</span></span><br><span class="line">$ git config --global user.email <span class="string">"email@example.com"</span></span><br></pre></td></tr></table></figure>
<hr>
<h2 id="基本原理"><a class="markdownIt-Anchor" href="#基本原理"></a> 基本原理</h2>
<p>Git跟踪代码仓库（Repository）中每个文件的改动，并基于改动提交的时间线形成日志（Log），后续便可根据相应的版本号进行版本回滚等操作。</p>
<span id="more"></span>
<h3 id="仓库建立"><a class="markdownIt-Anchor" href="#仓库建立"></a> 仓库建立</h3>
<p>本地的代码仓库来源有两种：</p>
<ul>
<li>通过<code>git init</code>命令将本地某个文件夹变成Git可以管理的仓库</li>
<li>通过<code>git clone</code>命令将某个远程仓库克隆至本地，生成项目同名文件夹<br>
基于Git的版本库文件夹下，具有<code>.git</code>子文件夹，这个文件夹是用来跟踪管理代码版本的</li>
</ul>
<h3 id="基础命令"><a class="markdownIt-Anchor" href="#基础命令"></a> 基础命令</h3>
<p><img src="/bd540e03a768/git_theory.png" alt></p>
<p>上图展示了Git管理下本地的三个工作区，包含代码库（Repository）的文件夹可以理解成工作目录(Working directory)，同时此文件夹下还具有一个暂存区（Stage）。当文件夹内出现新文件时，此文件会被标记为<strong>Untracked</strong>，表明此文件未被Git跟踪，即此文件未被包含至代码库内。对于本身就包含于代码库的文件，在其未修改时是<strong>Unmodify</strong>状态，修改后为<strong>Modified</strong>的状态。如果我们希望Git记录修改以及新增的内容，就可以先通过<code>git add [filename]</code>命令将其加入暂存区，此时改动文件被标记为<code>Staged</code>的状态。随后通过<code>git commit -m "message"</code>命令将改动内容提交到代码库，<code>-m</code>参数是添加此提交的注释信息。每次commit对应一个十六进制的<code>commit id</code>（版本号）。</p>
<p>常用的命令还包括以下几条：</p>
<ul>
<li><code>git status</code>查看当前目录下文件状态</li>
<li><code>git log</code>查看commit历史的时间线，版本回滚会导致时间线也回溯</li>
<li><code>git reflog</code>查看所有的命令，可以用来查询发生于回滚版本后的<code>commit id</code></li>
</ul>
<hr>
<h2 id="代码版本控制"><a class="markdownIt-Anchor" href="#代码版本控制"></a> 代码版本控制</h2>
<h3 id="版本回滚或回调"><a class="markdownIt-Anchor" href="#版本回滚或回调"></a> 版本回滚或回调</h3>
<p>所谓代码版本控制，即将代码库的版本根据需求变成对应<code>commit id</code>的版本，即对代码库版本进行回滚或者回调。下面是版本控制的常用命令，<code>HEAD</code>是当前分支当前版本的指针。</p>
<ul>
<li><code>git reset --hard HEAD^</code> 将当前版本回滚至上一个版本，<code>^</code>的数量表示回滚的数量，如果回滚的版本数太多，可以写成 <code>HEAD~100</code></li>
<li><code>git reset --hard id</code>将代码库改动至指定版本，版本号可以通过上述的<code>git log</code>和<code>git reflog</code>查询</li>
</ul>
<h3 id="单文件回滚"><a class="markdownIt-Anchor" href="#单文件回滚"></a> 单文件回滚</h3>
<p>上面叙述了如何在不同版本的代码库中进行切换，实际使用中还会涉及到单个文件的回滚，即撤销对某个文件的修改。下面分三种情况讨论如何撤销单个文件的修改：</p>
<ol>
<li>修改的文件处于<strong>Modified</strong>的状态，即还未将修改加入暂存区，使用<code> git checkout -- [filename]</code>命令撤销修改，此时文件变成和版本库一样，此命令本质是将版本库中记录的文件替换工作区中的对应文件。</li>
<li>修改的文件处于<strong>Staged</strong>的状态，即修改已经放入了暂存区，使用<code> git reset HEAD [filename]</code>将暂存区的修改退回工作区，然后使用<code> git checkout -- [filename]</code>丢弃工作区的修改。</li>
<li>如果文件的修改commit到了本地代码库，形成了新的代码版本，可以对版本进行回滚。</li>
</ol>
<h3 id="文件删除"><a class="markdownIt-Anchor" href="#文件删除"></a> 文件删除</h3>
<p>在工作目录使用文件管理器删除后，如果希望将代码库中对应的文件也删除，可以先通过<code> git rm [filename]</code>删除，然后<code>git commit</code>提交；如果文件是误删，可以通过<code>git checkout -- [filename]</code>将文件恢复</p>
<hr>
<h2 id="github联动"><a class="markdownIt-Anchor" href="#github联动"></a> GitHub联动</h2>
<p><strong>分布式</strong>版本控制系统Git中的分布式意味着项目中的所有开发人员都具有完整的版本库，但是通常需要某台中央服务器充当代码交换的作用，在其中建立远程代码库。本文以GitHub为例讲述本地仓库与远程仓库的联动，其他平台也是同理。既然本地仓库要与远程仓库联动，那么就需要在建立远程仓库与本地仓库的链接。通俗来说，当我们使用<code>git push</code>命令时，本地仓库需要知道push到哪个远程仓库。</p>
<ol>
<li>如果本地仓库是通过<code>git init</code>创建的，可以通过<code>git remote add origin git@github.com:username/reponame.git</code>命令将本地仓库与远程新建空仓库建立链接。 远程库的名字就是<code>origin</code>，这是Git默认的叫法，也可以改成别的 。随后使用<code>git push -u origin master</code>将本地的master分支推送到远程。 <code>-u</code>参数，会把本地的<code>master</code>分支和远程的<code>master</code>分支关联起来，在以后的推送或者拉取时就可以简化命令 。解绑链接通过<code>git remote rm origin</code>命令。</li>
<li>如果通过<code>git clone</code>创建的本地仓库，则本地仓库与远程仓库之间的链接是自动建立的。</li>
</ol>
<p>建立连接后，可以通过<code>git remote -v</code>查看远程仓库的信息。</p>
<h3 id="参与开源项目"><a class="markdownIt-Anchor" href="#参与开源项目"></a> 参与开源项目</h3>
<p>通常上述的push操作只能推送修改到自己的账号下，也就是将本地生成的SSH公钥添加至GitHub账号中。而通常的开源项目，核心外的开发人员通常不具备推送权限，因此可以通过以下流程参与开源项目：</p>
<ol>
<li>Fork别人的开源项目，就在自己的账号下克隆了一个同样的仓库</li>
<li>从自己的账号下的项目仓库克隆到本地</li>
<li>本地修改，推送到自己的仓库</li>
<li>发起Pull Request（PR）</li>
<li>等待对方接收合并或者拒绝</li>
</ol>
<hr>
<h2 id="分支管理"><a class="markdownIt-Anchor" href="#分支管理"></a> 分支管理</h2>
<p>类似于平行宇宙，建立新分支意味着我们从某次commit后开启另一条提交时间线，此时间线与原始的提交时间线中的修改互不干扰。开发中新分支具体用途是用来测试不稳定的feature或者修改原始分支中的Bug。前文提到HEAD指向<strong>master</strong>分支，<strong>master</strong>指向当前版本的代码库。</p>
<p>创立新分支本质上是创立了一个新的分支指针指向当前版本的代码库，而切换分支是更改HEAD指向，因此每次改动的commit都会提交到HEAD所指的当前分支中。常用命令如下：</p>
<ul>
<li><code>git checkout -b dev</code>创建<code>dev</code>分支并且切换到<code>dev</code>分支</li>
<li><code>git branch dev</code>创建<code>dev</code>分支</li>
<li><code>git checkout dev</code>切换到<code>dev</code>分支</li>
<li><code>git branch</code>查看当前分支</li>
<li><code>git merge dev</code> 把<code>dev</code>分支的工作成果合并到<code>master</code>分支上 ，默认<code>Fast forward</code>模式合并</li>
<li><code>git branch -d dev</code>删除<code>dev</code>分支</li>
</ul>
<p>值得注意的是，分支合并时，如果不同分支中的同一文件的修改不同，那么合并会发生<strong>冲突（Merge conflict in filename）</strong>。冲突的修改方式为将不同分支中冲突的文件内容修改一致，然后再通过<code>git add</code>和<code>git commit</code>合并。</p>
<p>默认合并模式下， 删除分支后，会丢掉分支信息（失去合并历史） 。如果需要保留分支合并前的信息，可以禁用<code>Fast forward</code>模式，即使用<code>git merge --no-ff -m "merge with no-ff" dev</code>合并，会对分支合并前形成快照，即可以通过<code>git log --graph --pretty=oneline --abbrev-commit</code>命令以图的形式查看到合并历史。</p>
<h3 id="多人开发"><a class="markdownIt-Anchor" href="#多人开发"></a> 多人开发</h3>
<p>在实际开发中，远程库通常具有<code>dev</code>和<code>master</code>两个分支。日常的新功能尝试都会在<code>dev</code>分支中进行，而<code>master</code>分支通常用来发布稳定的新版本，发布时将<code>dev</code>合并至<code>master</code>分支。每位开发员都可以拥有自己的独立开发分支， 时不时地往<code>dev</code>分支上合并就可以了 。</p>
<p>通常开发中远程仓库的分支管理涉及到以下问题：</p>
<ol>
<li>基于<code>master</code>发布的版本存在Bug，需要紧急修复，但自己目前在其他分支上的工作还没有提交。可以通过<code>git stash</code>将当前的工作现场保存，后续恢复现场继续工作。
<ul>
<li><code>git stash list</code>查看所有保存的工作现场</li>
<li><code>git stash pop </code> 恢复现场、同时把stash内容删除</li>
<li><code>git stash apply</code>恢复 ， <code>git stash drop</code>删除 stash内容</li>
<li>如果修复的Bug在其他分支上也存在，可以通过<code>git cherry-pick id</code> 复制一个特定的提交到当前分支</li>
</ul>
</li>
<li>某个分支被开发出来后，还未被合并就要被删除，需要通过<code>git branch -D name</code>强行删除。</li>
<li><code>git push origin name</code>推送远程仓库时，需要指定本地分支名字， 这样，Git就会把该分支推送到远程库对应的远程分支上 。</li>
<li>从远程仓库克隆时，只能看到<code>master</code>分支， 要在<code>dev</code>分支上开发，就必须创建远程<code>origin</code>的<code>dev</code>分支到本地 <code>git checkout -b dev origin/dev</code>。</li>
<li>如果<code>git pull</code>提示<code>no tracking information</code>，则说明本地分支和远程分支的链接关系没有创建， <code>git branch --set-upstream-to=origin/dev dev</code>指定本地<code>dev</code>分支与远程<code>origin/dev</code>分支的链接 。</li>
<li>如果向远程仓库推送发生了冲突，即本地修改的文件与远程仓库中对应文件的修改存在冲突，可以 先用<code>git pull</code>把最新的提交从<code>origin/dev</code>抓下来，然后，在本地合并，解决冲突，再推送 。本质上是将本地的代码库进行更新，然后合并本地的修改。</li>
<li><code>git pull</code>本质是更新本地代码库，在提交历史上会形成分叉，看起来类似分支合并。使用<code>git rebase</code> 把分叉的提交历史“整理”成一条直线，看上去更直观 。</li>
</ol>
<hr>
<h2 id="标签管理"><a class="markdownIt-Anchor" href="#标签管理"></a> 标签管理</h2>
<p>标签管理就是对十六进制的<code>commit id</code>添加一个别名，具体操作如下：</p>
<ol>
<li>切换到需要打标签的分支</li>
<li><code>git tag [name] </code>就可以打一个新标签</li>
</ol>
<p>值得注意的是标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。 另外一些常用命令如下：</p>
<ul>
<li><code>git tag</code>查看所有标签，标签展示按照字母排序</li>
<li><code>git tag <tagname> </code> id<code>对指定的版本打标签，也可以使用</code>-m`参数添加信息</li>
<li><code>git show <tagname> </code>可以查看标签的具体说明</li>
<li><code>git tag -d <tagname> </code>删除某标签</li>
<li><code>git push origin <tagname> </code>推送标签到远程</li>
<li><code>git push origin --tags</code> 一次性推送全部尚未推送到远程的本地标签</li>
<li><code>git tag -d <tagname> </code>结合<code>git push origin :refs/tags/<tagname> </code>删除远程标签</li>
</ul>
<hr>
<h2 id="参考文献"><a class="markdownIt-Anchor" href="#参考文献"></a> 参考文献</h2>
<p>[1] 廖雪峰，Git教程，<a href="https://www.liaoxuefeng.com/wiki/896043488029600">https://www.liaoxuefeng.com/wiki/896043488029600</a></p>
<p>[2] Scott Chacon，Pro Git，<a href="http://iissnan.com/progit/">http://iissnan.com/progit/</a></p>
]]></content>
<categories>
<category>Tools of Programming</category>
</categories>
<tags>
<tag>Tutorial</tag>
<tag>Version control</tag>
</tags>
</entry>
<entry>
<title>关于离散元接触力组构分析的讨论</title>
<url>/5b569d1cb868/</url>
<content><![CDATA[<h1 id="introduction"><a class="markdownIt-Anchor" href="#introduction"></a> Introduction</h1>
<p>所谓接触力组构分析（Analysis of Fabric Anisotropy），就是分析颗粒体系间法向、切向接触力的作用方向，研究力的传递规律，是研究细观介质的一个重要手段，可参考Rothenburg <sup>[1]</sup> 接触力分布函数相关内容。</p>
<div align="center"> <img src="/5b569d1cb868/zgfx.png" width="70%" height="70%"> </div>
<center> 图1 接触力组构分析示意图 </center>
<span id="more"></span>
<h1 id="二维案例"><a class="markdownIt-Anchor" href="#二维案例"></a> 二维案例</h1>
<p>二维的情况就比较简单了，每两个颗粒间的接触力可以分为法向力和切向力，PFC中可以通过内置的FISH函数导出接触力的单位方向向量(<code>contact.shear/contact.normal</code>)以及力的模(<code>contact.force.shear/contact.force.normal</code>)。但是值得注意的是法向力的模是具有正负号的，用于标识法向力为拉力还是压力。二维案列的玫瑰花图绘制的原理就是将平面空间的方位划分成一系列方位子区间，然后统计接触力在这些区间的分布特征。以图1为例，就是将360度的方位分布以15度为一个区间进行分区，按照接触力的方向单位向量将接触划分到所属的子方位分区，最后统计该区间包含的所有接触力。对于某个单位向量<code>(x,y)</code>，计算其所属的区间只需要计算<code>degree=arctan(y/x)</code>即可。</p>
<div align="center"> <img src="/5b569d1cb868/2dtn.png" width="70%" height="70%"> </div>
对力具体所属的区间进行划分后，下一步我们需要确定的就是如何统计各区间内包含的接触力。第一个需要考虑的问题就是对区间包含的力是计算平均值还是求和值。笔者目前没有在网上找到关于接触力统计的开源代码实现，自编程序的实现只能根据已有的论文资料以及石崇老师在书籍《颗粒流（PFC5.0）数值模拟技术及应用》中的配套程序进行反推。论文<sup>[2]</sup>中， 给出了双轴试验接触力统计结果的拟合公式，见下式。简单来说，就是对画出来的玫瑰花图的轮廓用函数进行描述。其中f<sub>0</sub>这个系数的量级到了10<sup>5</sup>至10<sup>6</sup>，而<code>辅助分析小程序/6-组构分析-石/pfc_contact_information.dat</code>的数据显示两颗粒间接触力的量级大约为几百到几千。因此，第一个推论为<b>每个方位子区间统计的模式是计算所有包含接触力的求和值</b>。第二个值得讨论的问题为展示法向力时，求和是有符号求和还是对绝对值求和。根据图1给出的展示以及石崇在<code>辅助分析小程序/6-组构分析-石</code>中给出的展示结果，并未观察到玫瑰花图径向数值有负值的存在。因此第二个推论为<b>统计方位子区间的求和值之前需要对每个力的模量取绝对值</b>。
<div align="center"> <img src="/5b569d1cb868/tu3.png" width="50%" height="50%"> </div>
理论介绍结束，实践验证开始。将<code>辅助分析小程序/6-组构分析-石</code>文件夹中的<code>pfc_contact_information.dat</code>文件在基于上述理论编写的Python代码进行验证，并同石崇<code>plot_rose_picture_2D.exe</code>程序的结果进行对比。切向力与法向力比较结果如下，左图为石崇<code>plot_rose_picture_2D.exe</code>的结果，结果接近，但存在差异，<b>哪里存在问题？</b>大家不必在意图形的大小问题，因为石崇径向半径的比例尺是固定值，笔者程序径向半径比例尺为自适应调整。
<div align="center"> <img src="/5b569d1cb868/shear_comp1.png" width="80%" height="80%"> </div>
<center>切向力结果比对</center>
<div align="center"> <img src="/5b569d1cb868/normal_comp1.png" width="90%" height="90%"> </div>
<center>法向力结果比对</center>
为了找到问题所在，笔者又将某个二维单轴压缩模型的接触力信息导出并绘制玫瑰花图，比对结果如下：
<div align="center"> <img src="/5b569d1cb868/shear_comp2.png" width="80%" height="80%"> </div>
<center>切向力结果比对</center>
<div align="center"> <img src="/5b569d1cb868/normal_comp2.png" width="90%" height="90%"> </div>
<center>法向力结果比对</center>
这样看的话，将石崇的图形旋转90度才能和笔者程序的图对应上。笔者推断自编程序和石崇程序对于接触力的方位区间划分存在差异，那么存在差异的话，<b>石崇程序可能是如何编写？孰对孰错？</b>但是从文献<sup>[1,2]</sup>中对于法向力的展示结果来看，单轴、双轴试验的法向力玫瑰花图都是竖着的而不是横着的。难道网上公布的这个<code>辅助分析小程序/6-组构分析-石/plot_rose_picture_2D.exe</code>程序是个错误的版本？
<div align="center"> <img src="/5b569d1cb868/sznormal.png" width="80%" height="80%"> </div>
<center>文献2中法向力的玫瑰花图结果</center>
<h1 id="三维案例"><a class="markdownIt-Anchor" href="#三维案例"></a> 三维案例</h1>
<h2 id="三维模型的二维可视化展示"><a class="markdownIt-Anchor" href="#三维模型的二维可视化展示"></a> 三维模型的二维可视化展示</h2>
<p>对于三维离散元模型而言，二维的可视化展示就是继续用上面的二维玫瑰花图展示三维的接触力。石崇在<code>辅助分析小程序\6-2三维直接剪切xoz面组构分析-石\三维直接剪切xoz面组构图分布.exe</code>中给出了三维直剪案例的二维可视化程序。字面意思上理解，似乎是对于接触力的三维方向单位向量<code>(x,y,z)</code>，直接舍弃掉<code>y</code>分量，然后通过<code>arctan(z/x)</code>来计算接触力所属的方位子区间。直觉上理解，就是把三维空间沿着<code>y</code>轴投影到<code>XOZ</code>平面上，默认情况下，XOZ的假定如下图所示。暂且这么假定，让我们看看结果。</p>
<div align="center"> <img src="/5b569d1cb868/xoz.png" width="50%" height="50%"> </div>
<h3 id="y分量丢弃方案"><a class="markdownIt-Anchor" href="#y分量丢弃方案"></a> y分量丢弃方案</h3>
<p>首先可以看到 <code>辅助分析小程序\6-2三维直接剪切xoz面组构分析-石</code>文件夹下，用于示范的<code>pfc_contact_information.dat</code>文件每行只有9个数据，而如果按照<code>辅助分析小程序\6-2三维直接剪切xoz面组构分析-石\导出接触信息命令流PFC3D5.0.txt</code>中的代码（下示代码），导出的数据每行应该具有12个数据。点击运行<code>三维直接剪切xoz面组构图分布.exe</code>，每行9个数据的文件报错，也就是说这里文件夹本身包含的示范文件有错误，应该要按照下示代码导出每行12个数据的接触信息文件。</p>
<figure class="highlight python"><table><tr><td class="code"><pre><span class="line">contact_info(count)= string(contact.<span class="built_in">id</span>(cp))+<span class="string">' '</span>+string(contact.pos.x(cp))+<span class="string">' '</span> + string(contact.pos.y(cp)) +<span class="string">' '</span> + string(contact.pos.z(cp)) </span><br><span class="line">contact_info(count)=contact_info(count)+<span class="string">' '</span> +string(contact.normal.x(cp))+<span class="string">' '</span> +string(contact.normal.y(cp))+<span class="string">' '</span> +string(contact.normal.z(cp)) </span><br><span class="line">contact_info(count)=contact_info(count)+<span class="string">' '</span> +string(contact.shear.x(cp))+<span class="string">' '</span> +string(contact.shear.y(cp))+<span class="string">' '</span> +string(contact.shear.z(cp))</span><br><span class="line">contact_info(count)=contact_info(count)+<span class="string">' '</span> +string(contact.force.normal(cp))+<span class="string">' '</span> +string(contact.force.shear(cp))</span><br></pre></td></tr></table></figure>
<p>因此，笔者又导出了某个三维单轴压缩模型的接触力信息文件，用于推测这个绘制XOZ面组构玫瑰花图程序的实现方式。下面是石崇程序的结果：</p>
<div align="center"> <img src="/5b569d1cb868/sc_xoz.png" width="80%" height="80%"> </div>
<center>石崇程序XOZ面组构分析结果</center>
单论法向力而言，主要分布方向还是水平的，<b>什么问题？</b>
<p>根据舍弃y分量方案，笔者给出了自己的实现结果：</p>
<div align="center"> <img src="/5b569d1cb868/ty_hb.png" width="80%" height="80%"> </div>
<center>自编程序-y分量舍弃方案分析结果</center>
我们可以看到对于玫瑰花图存在向90度以及270度聚集的异常，这是可以预见的，由于y分量的舍弃，计算接触力方位的子区间（等价于计算方向向量的倾角）公式由<code>arctan(z/sqrt(x2+y2))</code>变成了<code>arctan(z/x)</code>，如果y分量的值较大，那么使用<code>arctan(z/x)</code>计算的结果也会变大，即统计结果向90度和270度聚集。
<h3 id="方向向量旋转方案"><a class="markdownIt-Anchor" href="#方向向量旋转方案"></a> 方向向量旋转方案</h3>
<p>既然直接舍弃y分量，会使得分区的统计结果向90度和270聚集，那么就依据接触力方向向量的倾角划分，并且结合x分量的正负值决定该方向向量归属于XOZ面的X正半轴还是X负半轴，直觉上理解就是将接触力依据X分量的正负旋转到XOZ平面上，然后对接触力进行统计，结果如下：</p>
<div align="center"> <img src="/5b569d1cb868/xz_hb.png" width="80%" height="80%"> </div>
<center>自编程序-旋转方案分析结果</center>
<h3 id="讨论"><a class="markdownIt-Anchor" href="#讨论"></a> 讨论</h3>
<p>似乎上面两种方案由于信息的压缩呈现结果都不太完美，<b>大家觉得哪种用于论文更合理？或者是否存在更佳的三维模型二维化展示方案？</b></p>
<h2 id="三维模型的三维可视化展示"><a class="markdownIt-Anchor" href="#三维模型的三维可视化展示"></a> 三维模型的三维可视化展示</h2>
<p>即用三维图形来展示三维的接触力，理论上可以把一个球面进行分区，然后在每个分区上绘制统计结果的柱状图。然而目前笔者还没有很好的思路做到这一点，欢迎大家交流讨论。</p>
<h1 id="references"><a class="markdownIt-Anchor" href="#references"></a> References</h1>
<p>[1] ROTHENBURG L, BATHURST R J. Analytical study of induced anisotropy in idealized granular materials[J]. Géotechnique, 1989, 39(4): 601–614.</p>
<p>[2] 张强,汪小刚,赵宇飞,刘立鹏，林兴超，石崇.不同围压加载方式下土石混合体变形破坏机制颗粒流模拟研究[J].岩土工程学报, 2018, 40(11):10.DOI:10.11779/CJGE201811011.</p>
]]></content>
<categories>
<category>PFC</category>
</categories>
<tags>
<tag>Mechanics Analysis</tag>
</tags>
</entry>
</search>