編譯的案例
編譯型語言和解釋型語言的區別？
而這種轉換的方式有兩種：
1.編譯
2.解釋
由此高級語言也分為編譯型語言和解釋型語言。
主要區別在于，前者源程序編譯后即可在該平臺運行，后者是在運行期間才編譯。所以前者運行速度快，后者跨平臺性好。
編譯型語言
使用專門的編譯器，針對特定的平臺，將高級語言源代碼一次性的編譯成可被該平臺硬件執行的機器碼，并包裝成該平臺所能識別的可執行性程序的格式。
特點
在編譯型語言寫的程序執行之前，需要一個專門的編譯過程，把源代碼編譯成機器語言的文件，如exe格式的文件，以后要再運行時，直接使用編譯結果即可，如直接運行exe文件。因為只需編譯一次，以后運行時不需要編譯，所以編譯型語言執行效率高。
總結
1.一次性的編譯成平臺相關的機器語言文件，運行時脫離開發環境，運行效率高；
2.與特定平臺相關，一般無法移植到其他平臺；
3.現有的C、C++、Objective等都屬于編譯型語言。
解釋型語言
使用專門的解釋器對源程序逐行解釋成特定平臺的機器碼并立即執行。是代碼在執行時才被解釋器一行行動態翻譯和執行，而不是在執行之前就完成翻譯。
特點
解釋型語言不需要事先編譯，其直接將源代碼解釋成機器碼并立即執行，所以只要某一平臺提供了相應的解釋器即可運行該程序。
展開 ZEMAX軟件技術應用專題：如何編譯用戶自定義DLL
如果有任何內容未被讀出，那么該DLL可能不能編譯。即使編譯了，也未必能正常運行。使用C++編譯器絕大部分Zemax自帶的案例文件都是用C語言寫的。由于Visual Studio是個C++編譯器，這意味著必須對代碼進行一些修改來正確地編譯它們。如果還沒添加。那么在代碼開頭的初始化功能區放入“extern “C” {}”。同時確保把“BOOL WINAPI DllMain”這一行注釋掉。在C++編譯器里，程序(function)名往往會在后臺被修改，以使得每個程序都有其唯一的標識。如果程序名變化了，那么OpticStudio會無法運行該DLL，因為OpticStudio會尋找具體的名稱（例如：UserDefinedSurface、UserObjectDefinition等）采用上述改變可以強制編譯器保持原來C代碼里的程序名且忽略任何可能造成的錯誤。同樣地，可能也會需要無視由于C和C++的細微不同造成的警告，例如：C4996: ‘srtcpy’: This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.如果這是編譯中唯一遇到的警告，那么以下的代碼可以繞過這個問題：#pragma warning ( disable : 4996 )這行代碼會允許編譯器提供特定于電腦或者操作系統的功能，同時保持C和C++語言上大體的兼容性。Rebuild Solution選擇Build…Rebuild Solution來編譯你的代碼，或者直接按鍵盤“Ctrl+F5”。編譯成功后會輸出以下內容：這個DLL會在solution文件夾下。
展開 DEFORM二次開發編譯工具最新介紹
Absoft & Intel Fortran兩種編譯器編譯的FEM引擎計算效率的對比：
案例一：Spike forging–120K tet 和 FourTee forging–1M tet
該案例在Windows 10、AMD 5900X CPU環境下進行計算對比，不同求解器計算效率如下圖所示：
圖3 FEM引擎計算效率對比
由上圖可知：Intel Fortran相比Absoft編譯器編譯的FEM引擎CG 求解器計算速度提高了20 ~ 130%；MUMPS求解器計算速度提高了10~30%；Spooles求解器計算速度提高了約5%。
案例二：在Windows 10、i7-11700KF CPU環境下，三種算例均采用 MUMPS 求解器
圖4 FEM引擎計算效率對比
由上圖可知：1）碾環—20K, 60K六面體網格，計算速度提高了50 ~ 70%；2）ALE型軋—20K, 200K 六面體網格，計算速度提高了20 ~ 60%；3）自由鍛—200K, 600K 四面體網格，計算速度提高了15 ~ 50%。
綜上述，Intel Fortran相比Absoft編譯器編譯的FEM引擎具有更高計算效率。SFTC公司目前已經完成DEFORM軟件Intel Fortran FEM引擎的開發，針對于二次開發編譯器短期將同時支持Intel Fortran和Absoft編譯器，而Intel Fortran編譯器將成為趨勢。
展開 ZEMAX OpticStudio 如何編譯用戶自定義DLL
如果有任何內容未被讀出，那么該DLL可能不能編譯。即使編譯了，也未必能正常運行。
使用C++編譯器
絕大部分Zemax自帶的案例文件都是用C語言寫的。由于Visual Studio是個C++編譯器，這意味著必須對代碼進行一些修改來正確地編譯它們。
如果還沒添加。那么在代碼開頭的初始化功能區放入“extern “C” {}”。同時確保把“BOOL WINAPI DllMain”這一行注釋掉。
在C++編譯器里，程序(function)名往往會在后臺被修改，以使得每個程序都有其唯一的標識。如果程序名變化了，那么OpticStudio會無法運行該DLL，因為OpticStudio會尋找具體的名稱（例如：UserDefinedSurface、UserObjectDefinition等）采用上述改變可以強制編譯器保持原來C代碼里的程序名且忽略任何可能造成的錯誤。
同樣地，可能也會需要無視由于C和C++的細微不同造成的警告，例如：
C4996: ‘srtcpy’: This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
如果這是編譯中唯一遇到的警告，那么以下的代碼可以繞過這個問題：
#pragma warning ( disable : 4996 )
這行代碼會允許編譯器提供特定于電腦或者操作系統的功能，同時保持C和C++語言上大體的兼容性。
展開 
四十九、Fluent UDF編譯正確的流程
<p>很多同學會在群里面問一些UDF編譯的問題，特此寫一篇文章詳細說明一下對UDF進行編譯的正確流程。</p><p><br></p><p><strong>1. UDF正常編譯流程</strong></p><p><br></p><p>第一步：配置環境變量，參考公眾號文章<a href="http://mp.weixin.qq.com/s?__biz=MzkwMTAyNTc0Mw==&mid=2247483827&idx=1&sn=29963c6a8bfa7b0b7abd7d490bc300f9&chksm=c0ba5b13f7cdd2052f569bb77174b53946ae3d7cfbe119947caa07dbc9ec041b8bf2c3540cd1&scene=21#wechat_redirect" rel="noopener noreferrer" target="_blank">十.Fluent環境變量的配置</a></p><p>第二步：驗證環境變量是否成功</p><p>第三步：進行UDF編譯</p><p> </p><p><strong>2. 配置環境變量</strong></p><p><br></p><p><strong>2.1 編譯型VS解釋型</strong></p><p><br></p><p>推薦大家使用編譯型UDF</p><p> </p><p>有些同學為了方便省事，想直接用解釋型UDF，這樣就不用配置環境變量了。解釋型的UDF與編譯型UDF在UDF的編寫上沒有任何不同，只是將UDF加載到Fluent中的方式有所不同。
展開 damask 子程序在windows平臺直接編譯使用
再嘗試編譯過程中嘗試了大量的damask版本，發現2.02和2.01版本最適合作為移植到abaqus的軟件版本，原因是2.03雖然作為最后一個支持abaqus求解器的版本，然而當前版本不支持顯示求解器，因此為了方便后期的動態求解問題，不適合使用，同時2.0以前的damask版本相應的功能雖然已經滿足，但是存在各類不易輕易發現的bug，嚴重影響移植過程，同時damask移植過程中涉及到并行計算的問題，damask的子程序寫法對并行計算支持度一般，且存在大量的數值讀取和寫出，嚴重影響多核心并并行計算，因此建議調試時使用單核心進行，移植到windows下支持的編譯器和Fortran版本也有顯著差異，當前使用vs2017，Fortran2019，abaqus2022發現可以正常使用計算。對damask在windows下編譯感興趣的可以下載相應版本的abaqus嘗試編譯和運行。
damask在windows下使用的案例效果如下：
在編譯過程中測試了下圖所示的案例，分別是BCC鐵，位錯密度模型，FCC鋁，ＨＣＰ鎂合金，ＨＣＰ鈦合金，各項同性的粘塑性模型，taylor模型等以及動態顯示vumat的實現，發現運行結果良好，計算效率相較于linux平臺要稍快一些，指的注意的是，當前采用單核心計算，在后續的過程中會對整體的damask代碼進行完整的重構，充分支持多核心并行計算，即運算效率會顯著提到，運行效果如下：
同一個目錄下包含如下文件
預編譯為OBJ格式可以顯著較少每次編譯所消耗的時間，
使用包含200個晶粒進行拉伸拉伸測試，驗證程序的可靠性
運行過程中，會生成包含輸出變量含義的三個文件
整體運行結束需要的時間。
展開 UDF程序編譯常見問題，以及解決辦法！
圖1
如何修改：設置好環境變量，再次編譯就可以成功加載。
環境變量設置目前較為成熟和成功方法，經過多次給網友調試，總結認為按路徑設置環境變量是最好的方法，成功率百分之百！這里切記修改環境變量不是在系統變量中修改！！
設置如下：
圖2
主要找到編譯器安裝路徑下得include\lib\path就可以設置成功。具體見教程vs2010、2013環境變量設置。
另外需要注意是：由于程序字符格式問題，這種情況多為復制黏貼幫助文檔或者其他地方程序，直接黏貼在編譯器或者text文本里得，導致沒有完全編譯，加載過程時報錯，找不到liubuf.dll文件。
解決辦法：
編譯不成功原因是由于程序本身格式問題，編譯器不識別，多為復制黏貼過來程序。這時候可以將其復制黏貼到可以編譯成功程序里，即可解決問題。
2編譯過程中，由于書寫有誤，導致程序報錯。
圖3
這樣錯誤要根據報錯提示進行修改，千萬要注意看報錯提示，再進行逐行修改，事半功倍。
例如：第13行缺少分號，增加分號 即可。
圖4
具體調整見技術鄰視頻。
3由于程序結構問題，導致報錯，received a fata segmental?
例如：在邊界上進行面循環時，我們卻想去獲得網格上參數值，例如C_U(c,t)網格速度值，這樣就是不合理得，會出現分割錯誤。同時，對于C_VOF(c,t)體積分數這樣宏，一定要注意它的指針問題，否則你會出現常見錯誤。
4由于程序函數宏格式問題，導致缺少“}”,size of“0”，
圖5
程序本身沒有錯誤，但是編譯就是報錯！這時比較讓人著急，找不到頭緒！
解決辦法：這時只需要找一個能編譯程序，復制黏貼過去。如果還不行，就說明你的函數是不是哪個地方寫錯了，要進行仔細檢查！
展開 Ubuntu16.04編譯OpenFOAM5.0流程
二、下載解壓OF5.0源代碼包及第三方組件
1、在當前用戶根目錄下建立一個OpenFOAM目錄，用于保存OpenFOAM源代碼包以及作為編譯的中間目錄。重新開啟一個終端，輸入如下命令：
cd $HOME
mkdir OpenFOAM
cd OpenFOAM
2、下載OF源代碼包及第三方組件：
wget -O - http://dl.openfoam.org/source/5-0 | tar xvz
wget -O - http://dl.openfoam.org/third-party/5-0 | tar xvz
并重命名：
mv OpenFOAM-5.x-version-5.0 OpenFOAM-5.0
mv ThirdParty-5.x-version-5.0 ThirdParty-5.0
三、編譯
1、編譯前準備工作，設置環境變量（非常重要）
用你熟悉的文本編輯器打開$HOME/.bashrc，定位到文件結尾，加上一行
source $HOME/OpenFOAM/OpenFOAM-5.0/etc/bashrc
保存后執行：
source $HOME/.bashrc
2、編譯第三方組件
輸入如下命令：
cd $HOME/OpenFOAM/ThirdParty-5.0
./Allwmake -j
編譯ParaView
./makeParaView
漫長的等待…
如果出現“Qt5”字樣的錯誤，請用文本編輯器打開$HOME/OpenFOAM/ThirdParty-5.0/CMakeLists.txt文件，定位到462行，將
“set (PARAVIEW_QT_VERSION “5” CACHE STRING….)”
改為
“set (PARAVIEW_QT_VERSION “4” CACHE STRING….)”
展開 歡迎大家進行測試：數學表達式編譯計算動態庫FORCAL 
<BR> 另外，FORCAL編譯器在編譯表達式時能進行兩種形式的代碼優化，其一是預先計算表達式中可以計算的部分，其二是采用格式4表示的數學表達式的可優化形式。 <BR> FORCAL將最大限度地進行第一種代碼優化，但這種自動進行的優化并不徹底，若要獲得最優化的代碼，您需要將表達式中可以計算的部分用括號括起來（一般情況下不需要這樣做）。 <BR> 例如：要想進行徹底的第一種代碼優化，需要將式子： <BR> F(x,y)=x-5-7+y <BR> 寫成：F(x,y)=x-[5+7]+y或F(x,y)=x+[-5-7]+y <BR> 需要注意的是，在進行第一種代碼優化時，只有一級函數可以進行預先計算，二級函數的計算始終只能在編譯后的表達式中進行。 <BR> FORCAL的第二種代碼優化可以保證表達式中的任何相同部分只進行一次計算，從而最大限度地提高了計算速度。 <BR>二、FORCAL的速度： <BR> 由于編譯表達式所占的時間很少，所以這里只比較FORCAL與FORTRAN(或C/C++)的計算速度。 <BR> 1、對純數學表達式計算速度的比較 <BR> FORCAL是由FORTRAN(或C/C++)的編譯程序生成的，所以它的速度要稍慢些，約為FORTRAN(或C/C++)的編譯速度的50%左右。一般，表達式越長越復雜，FORCAL與FORTRAN(或C/C++)的計算速度就越接近。 <BR> 2、綜合比較 <BR> 綜合比較是指由FORCAL生成的實用程序和由FORTRAN(或C/C++)直接生成的實用程序的速度的比較。在實用程序中，除了計算表達式外，還有很多的算法處理，這使得它們之間的速度差別在縮小，毋庸質疑，算法處理所占的時間越長，它們的速度差別就越小。
展開 Nastran-95源代碼編譯及運行 ￥49
Nastran-95源代碼編譯及運行
1 NASTRAN源代碼簡介
NASTRAN是一個有限元分析程序，最初是在1960年代后期在美國政府對航空航天業的資助下為NASA開發的。這是世界上第一套成熟的有限元分析軟件，它打開了計算機輔助工程的大門。NASTRAN可以處理彈性穩定性分析、振動和動態穩定性分析的復雜特征值、瞬態和穩態載荷的動態響應、隨機激勵以及集中和分布載荷、熱膨脹和強制變形的靜態響應。
這套源代碼現在看起來已經過時了，里面的材料、單元以及接觸算法相比與現在通用的有限元軟件而言已經沒有任何先進性可言，但是這套源代碼構建了基本的有限元框架，研究人員可以通過這套源代碼理解有限元底層的運行邏輯，加深對有有限元基礎理論的認識，甚至可以在這套源代碼上進行二次開發，增加自己編寫的模塊，驗證自己的研究思路。
2 NASTRAN95源代碼下載
NASA在github上公開了NASTRAN-95的源代碼供研究人員自由下載，下載地址為：https://github.com/nasa/NASTRAN-95 。然而由于該版本開發較早，舊版操作系統、編譯器均與現在流行的配套軟件存在較大不同，因此該源代碼需要進行一系列修改才能編譯使用，這對于普通研究人員而言幾乎是不可能完成的事。當然，世上無難事，只怕有心人，有大牛對這套源代碼進行了修改，使之能夠適用于現在的編譯環境和操作系統。本人根據修改后的源代碼，并進一步對makefile文件以及配置文件進行修改編譯，使之能夠在linux以及windows下正確編譯運行。
花了大概整整兩天時間吧，收取一些時間成本費用，請大家體諒，有興趣的同學也可以自己去鉆研。
展開 EDEM最新版耦合接口編譯過程中問題說明
最后按照教程進行編譯，編譯成功的提示如下圖所示，同時檢查D:\edem_coupling_build\lib_edem_coupling\win64下每個文件夾里都有libudf.dll生成，說明編譯過程沒問題的。Fluent讀取.jou文件提示Done
轉沙發老師
PGI Fortran 編譯器
PGI Fortran 是與 Intel Visual Fortran 起名的著名編譯器產品，由隸屬于英偉達（NVIDIA）下的 Portland Group 小組開發，優化能力堪比IVF。
世界領先的獨立的高性能計算技術編譯器及開發工具供應商Portland Group?(PGI)，PGI Visual Fortran?(PVF?)全面銷售。PVF將 PGI的高性能64位及32位Fortran并行編譯器及開發工具套件與Microsoft Visual Studio 整合在一起，為科學工作者和工程師從32位升級到64位Microsoft Windows平臺提供一套高效的系統開發解決方案。
科研工作者將PGI編譯器及開發工具廣泛用于內置英特爾和AMD高性能微處理器的64位和32位 Linux工作站、服務器和集群器上。該版軟件使Portland Group對運行在Windows平臺上的64位和32位Fortran應用程序的開發支持擴展到英特爾和AMD的64位和32位微處理器，新軟件運行在深受市場歡迎的Microsoft Visual Studio 2005集成開發環境(IDE)。PGI Visual Fortran 套件整合了多種兼容性能，使從現有的支持Windows的32位Fortran升級到64位平臺變得十分簡單，具體兼容功能包括支持Windows 32位應用編程接口(API)、調用規則、匯編命令以及公認的標準實用工具庫。
Microsoft Visual Studio是世界上應用最廣泛的集成開發環境。Visual Studio 工具及技術（ 包括一個并行調試器 ）使開發人員可以利用他們現有的Windows開發技能及經驗開發在Windows Compute Cluster Server 2003平臺上運行的HPC（高性能計算）應用程序。
展開 【轉帖】總結：m文件轉化為c/c++語言文件，VC編譯
【轉帖】總結：m文件轉化為c/c++語言文件，VC編譯
[轉帖]總結：m文件轉化為c/c++語言文件，VC編譯
matlab使用很方便，但有時候一些特殊的應用需要我們將matlab中m格式的
文件中的程序翻譯成c/c++的形式的程序并在c/c++的編譯器中進行編譯，本
文總結了一般的方法。
需要分兩種情況，第一種是你的m文件中不涉及到有關繪圖的函數；第二種
是需要用到繪圖函數。下面分別用例子來說明：
第一種情況：
1. 建一個m文件，內容為：
%%%%%%%%%%%%%%%%%%%%%%
function y=fork_1(n)
y=0;
for i=1:n
y=y+i;
end
%%%%%%%%%%%%%%%%%%%%%%
保存后在命令窗口中：
輸入：（格式：mcc -t -L Cpp -h 文件名）
mcc -t -L Cpp -h fork_1
然后你會在你的工作目錄下找到fork_1.cpp和fork_1.hpp兩個文件。
2. 在VC中建一個基于對話框的MFC應用程序，名字為testFork1，添加一個
按鈕，并添加按鈕響應函數，函數內容在第五步中說明。將上面生成的
兩個文件拷貝到VC工程的testFork1目錄里。
3. 在VC中選擇：工程--->設置，再選屬性表Link選項，下拉菜單中選擇Input，
在對象/庫模塊中加入附錄A中所列出的內容，注意用空格將它們格開而在忽略
庫中加入附錄B中列出的內容；再選擇屬性表C/C++選項，下拉菜單選General，
在預處理程序定義中添加附錄C中的內容，原來有的內容要保留，并注意用逗號
將它們隔開。
展開 介紹將for文件編譯為obj文件的方法。
在交流程序的時候，部分文件有保密的需求，這些文件需要編譯為不可讀取的形式。
abaqus通過cmd窗口提供了方法，可以將for文件編譯為obj文件。
1、cmd窗口中的文件路徑切換方法
"盤符:"---將路徑切換到某一個盤符，如”c：“即將工作路徑切換到c盤。
"cd.."---將路徑后退一個文件夾.
"cd filename"---在當前工作路徑下前進到filename對應的文件中。
2、編譯for文件的命令行
將工作路徑移動到for文件對應的文件后，輸入下列命令行：
"abaqus make library=filename.for"---即將filename.for文件編譯為obj文件，
打開obj文件，發現該文件已經不可讀取，具有保密性。
展開 案例分享｜仿真軟件并行架構升級——基于編譯優化的風雷軟件性能突破
循環級緩存性能榨取</h3><ul><li>向量化加速：重構循環結構，利用Intel編譯器自動向量化技術將標量運算轉化為SIMD指令（如AVX512），單指令處理多數據；分塊與融合：通過循環分塊（Tiling）提升緩存命中率，融合獨立循環減少分支跳轉開銷；數據預取：優化內存訪問模式，引導編譯器自動插入預取指令，減少CPU等待延遲。</li></ul><p><br></p><h3>2. 鏈接時全局優化</h3><ul><li>LTO（鏈接時優化）：借助LLVM工具鏈對全程序代碼進行跨模塊分析，內聯關鍵函數、消除冗余計算；IPO（過程間優化）：跨函數邊界優化寄存器分配與指令調度，提升指令級并行度。</li></ul><p><br></p><h3>3. 零侵入式代碼重構</h3><ul><li>多維數組底層訪問優化：用多級指針替代傳統類封裝，減少隱式索引計算；編譯器指令嵌入：通過`pragma omp simd`等編譯制導語句引導編譯器生成高效機器碼。</li></ul><p><br></p><h2>四、結果測試：效率躍升與跨平臺驗證</h2><p class="ql-align-justify">在完成編譯優化方案的構建后，我們迎來了至關重要的實戰驗證階段。本次測試聚焦兩大核心目標：一是驗證優化后的風雷結構網格求解器在不同平臺上的計算效率是否實現顯著提升，二是確保優化過程絲毫未影響程序的計算精度。</p><h3>1.
展開 