• 沒有找到結果。

考量快取記憶體的立體資料呈像技術

N/A
N/A
Protected

Academic year: 2021

Share "考量快取記憶體的立體資料呈像技術"

Copied!
9
0
0

加載中.... (立即查看全文)

全文

(1)

行政院國家科學委員會專題研究計畫 成果報告

考量快取記憶體的立體資料呈像技術

計畫類別: 個別型計畫

計畫編號: NSC94-2213-E-011-054-

執行期間: 94 年 08 月 01 日至 95 年 07 月 31 日 執行單位: 國立臺灣科技大學資訊管理系

計畫主持人: 楊傳凱

計畫參與人員: 楊惠琳 姜威廷

報告類型: 精簡報告

報告附件: 出席國際會議研究心得報告及發表論文 處理方式: 本計畫可公開查詢

中 華 民 國 95 年 10 月 25 日

(2)

行政院國家科學委員會補助專題研究計畫 ■ 成 果 報 告

□期中進度報告

(計畫名稱)

考量快取記憶體的立體資料呈像技術

計畫類別:■ 個別型計畫 □ 整合型計畫 計畫編號:NSC 94-2213-E-011-054-

執行期間: 94 年 8 月 1 日至 95 年 7 月 31 日

計畫主持人:楊傳凱 共同主持人:

計畫參與人員:楊惠琳,姜威廷

成果報告類型(依經費核定清單規定繳交):■精簡報告 □完整報告

本成果報告包括以下應繳交之附件:

□赴國外出差或研習心得報告一份

□赴大陸地區出差或研習心得報告一份

■出席國際學術會議心得報告(另外上傳)

□國際合作研究計畫國外研究報告書一份

處理方式:除產學合作研究計畫、提升產業技術及人才培育研究計畫、

列管計畫及下列情形者外,得立即公開查詢

□涉及專利或其他智慧財產權,□一年□二年後可公開查詢 執行單位:

中 華 民 國 95 年 10 月 25 日

附件一

(3)

一、研究計畫中文摘要:

關鍵詞:考量輸出入系統的立體資料呈像,資料預取,考量快取記憶體的立體資料呈像,

規則立體資料,快取記憶體失誤處理時間

立體資料呈像在科學界是一個十分重要的問題。不同於電腦繪圖的是,立體資料呈像的過 程涉及立體資料的內部結構,因而導致其在計算上速度的緩慢。一般來說,立體資料其資 料量的大小遠較於電腦繪圖時所處理之資料量來得大,因此將資料從硬碟載入至記憶體所 需的時間也成了評量系統效能時不可忽略的因素。對此我們曾提出一種方法稱為「考量輸 出入系統的立體資料呈像技術」(I/O-Conscious Volume Rendering),將給定資料先分割為相 等大小的區塊,而在檔案系統進行下一區塊的預取(Prefetching)時,中央處理器同時處理 之前所載入的區塊,如此即可用系統執行於計算的時間來遮蔽(mask)系統於資料載入時 所耗費的時間。至於本計劃的著眼點則是更進一步發展出一種「考量快取記憶體的立體資 料呈像技術」(Cache-Conscious Volume Rendering),所考慮的對象也從硬碟與記憶體間的 關係變更為記憶體與快取記憶體間的關係。儘管所涉及的基本觀念類似,但可預期的是至 少會面臨以下兩個新問題。其一,由於快取記憶體的大小十分有限,所以更為精準的資料 預取,以及資料在記憶體及快取記憶體之間的安排將變得更為重要,以避免資料在快取記 憶體中產生不必要的進出,導致效能的損失。其二,在快取記憶體中進行資料的預取有一 最大的困難性:我們無法知曉資料究竟於何時已預取完畢。這也使得整個系統的設計,尤 其是處理第一個問題時更顯棘手。此項計劃中,我們所針對的立體資料為「規則立體資料」

(Regular Volume Data),而且如前所述,資料必須先進行分割。為使於分割資料上產生之 呈像結果與原本資料相同,各區塊的載入順序必須進行一番考量。經過仔細的考量我們發 現僅需考量八種可能的順序即可應付在各方向上的呈像需求,而此對於解決前述第一個問 題大有助益。至於第二個問題,我們目前將訴諸一個較保守的做法,就是先測量「快取記 憶體失誤處理時間」(Cache Miss Service Time),並以此作為判斷資料預取至快取記憶體的 動作是否已完成的一個保守估計。最後透過仔細安排系統於計算動作及資料預取至快取記 憶體動作的比例,使得兩者皆不處於閒置的狀態,進而提昇系統的總效能。

(4)

二、研究計畫英文摘要:

Keywords: I/O-Conscious Volume Rendering, Prefetching, Cache-Conscious Volume Rendering, Regular Volume Data, Cache Miss Service Time

Volume Rendering has been an important topic for more than a decade. Unlike computer graphics, volume rendering involves the interior of a data object, thus making it a relatively slower process.

In general, a volume data set could be one order of magnitude larger than its surface data counterpart encountered in the computer graphics world, therefore the data loading time itself has become a non-negligible factor. One of our previous projects aims to reduce the end-to-end time by masking the data loading time with computation time. The basic idea of that project, called

I/O-Conscious Volume Rendering, is to divide a given data set into multiple partitions, and

while the disk subsystem is busy prefetching the next partition of the data set from disk to memory, CPU could simultaneously work on the partitions that were brought into memory previously. After efficiently masking I/O with computation, we propose this project, called

Cache-Conscious Volume Rendering, to further improve the rendering performance by dealing

with the arrangement between memory and cache, instead of the arrangement between disk and memory. Although the basic ideas are similar, there are two new issues to be addressed. First, because cache size is relatively smaller, a more accurate arrangement or coordination is required;

otherwise unnecessary cache misses and content replacements may occur too frequently to hurt the system performance. Second, unlike the case of loading data from disk to memory, there is no explicit mechanism to check if a desired portion of the data has been prefetched from memory to cache. This further complicates the whole process especially when dealing with the first issue. In this project, volume data sets are assumed to be regular data sets, and are divided into equal-sized partitions. To have a correct rendering result, the order in which partitions are loaded must be handled carefully. However, it can be shown that for any viewing requests of a regular volume data set, we only need to consider eight possible cases, thus greatly reducing the complexity when facing the first issue. To address the second issue, we propose an approach by measuring the longest “cache miss service time”, which could be used as a conservative hint to estimate if the desired portion of data has been loaded into the cache or not. Finally, based on the estimation of the cache miss service time, the system can make a proper arrangement on data prefetching and computation so that most of the time both parts could work simultaneously to enhance the overall system performance.

(5)

三、前言

立體資料呈像(Volume Rendering)的動作是以電腦將給定的三維立體資料(Volume Data)

在螢幕上呈現出來。至於資料的來源有許多種,如電腦斷層掃描(Computer Tomography)、

核磁共振呈像(Magnetic Resonance Imaging)、超音波(Ultrasound),及有限元素方法(Finite Element Method)等等。利用前三種方法所產生的資料通常為規則立體資料(Regular Volume Data),而最後一種方法所產生的通常為不規則立體資料(Irregular Volume Data)。本計劃 的研究主要範疇為規則立體資料,而規則立體資料的組成單位:網格(Grid Cell)為一長 方體或立方體,圖一所示即為一實例。

圖一

與一般電腦圖學(Computer Graphics)所使用的表面模型(Surface Model)不同的是,

在資料呈像的過程中不僅止於資料的表面,事實上資料內部的組成及分布情形才是決定 呈像結果的主要因素,而這也導致了資料呈像一般面臨的兩大問題:1. 資料量的龐大以 2. 執行速度的緩慢。資料量的龐大造成將資料自硬碟載入至記憶體時所費的時間成為 不可忽略的因素。我們解決此問題的辦法是先將資料進行分割,而使得當硬碟預取

(Prefetching)下一分割區域時,中央處理器可同時處理之前所載入之區域,以達到利 用中央處理器的計算時間來有效地「遮蔽」(Mask)系統耗費在資料輸入的時間。此項 方法我們稱為「考量輸出入系統的立體資料呈像技術」(I/O-Conscious Volume Rendering)

[1]。而在本計劃中,我們將所探討的問題更進一步延伸,希望發展出「考量快取記憶體 的立體資料呈像技術」,也就是當記憶體將下一資料區塊預取至快取記憶體時,中央處理 器可同時處理之前所載入的資料區塊。雖然這其中所涉及的技術與之前十分類似,但在 處理上卻會至少遭遇到以下兩項新問題。第一,由於快取記憶體的大小十分有限,因此 在資料預取時的拿捏必須更為精準,以免產生不必要的快取記憶體的內容更替,進而影 響系統效能。更具體的說,資料的預取不可過快,以免因有限的快取記憶體大小使得已 預取至快取記憶體的資料尚未被充分使用即遭下一批預取的資料替換出去;另一方面,

資料的預取也不可過慢,導致中央處理器常常處於等待資料的狀態。換句話說,資料預 取入快取記憶體的速度必須恰到好處,系統的效能才會有所增進,比較起來,前述「考 量輸出入系統的立體資料呈像技術」因系統的記憶體空間相對較大故所需的精確度亦較 低。第二,在快取記憶體的資料預取上,並不像預取資料至記憶體時有一個明顯的機制 來檢驗資料預取的動作是否已完成,這也使得前述所言第一項問題顯得更為棘手。此外,

將資料分割後,為確保正確的呈像結果,不論是將各分割區域預取至記憶體或是快取記 憶體,其順序皆必須做適當的安排。這主要因為資料呈像的過程中立體資料內部的順序 必須納入考量,而一般說來同一資料若離觀看位置較近,所產生的貢獻也較大。然而這 也並不意味著我們一定得將各區塊以其距離觀看位置的距離來排序,並將各分割區以此 順序載入才能產生正確的結果。事實上,只要沿著觀看的方向一旦有兩分割區重疊時其 載入順序為正確即可。由此我們發展了一套方法可以有效及正確地決定各分割區域應如 何預取以提昇系統的效能,而這方法僅需考慮八種可能的順序即能應付在任意方向上的 呈像需求。不僅如此,我們亦希望系統的流程能具有以下特色,亦即任一區塊皆在被充 分利用後方為後來預取的資料所取代,這樣就可解決第一個問題的絕大部分。至於在解 決第二個的問題上,主要的關鍵在得知某一區塊其預取至快取記憶體的動作是否已完

(6)

成。對此目前我們將以系統的「快取記憶體失誤處理時間」作為一保守估計,因一般說 來資料預取至快取記憶體的時間不應超過此時間。事實上在解決第一個問題時尚有另一 關鍵:妥善安排資料預取動作及計算動作的比率,而這除了牽涉資料預取至快取記憶體 的時間,也牽涉到中央處理器執行一個分割區域呈像計算時所耗費的時間。根據這兩個 時間的比例我們可妥善地設定系統於計算及預取的比例,使得系統大部分時間皆處於不 閒置的狀態,進而提昇系統的總體效能。

四、研究目的

發展一套「考量快取記憶體的立體資料呈像技術」(Cache-Conscious Volume Rendering),

希望系統執行計算的時間與系統將資料預取至快取記憶體的時間能重疊,而使兩者同時 進行的結果可以提昇系統的整體效能。

五、文獻探討(引用論文請參見稍後重要參考文獻部分) 1. 立體資料呈像:

對於立體資料呈像的研究迄今已經近十五年。其中規則立體資料的呈像方法大致可 分 兩 類 : 直 接 呈 像 (Direct Volume Rendering ) 與 間 接 呈 像 ( Indirect Volume Rendering)。其中間接呈像的代表方法是「網格前進法」(Marching Cubes)[8]。其 做法是從立體資料中依據某些使用者有興趣的數值取出「表面模型」(Surface Model),再利用電腦圖學的方式去「呈像」(Render)這個表面模型;至於直接呈像 法則是直接從立體資料產生影像。這其中最有名的有「射線法」(Raycasting)[9, 10],

「足印法」(Splatting)[11, 12], 以及「切扭法」(Shear-Warp)[13]。其中僅射線法 與我們的研究較為相關,而其做法為從螢幕上的每一像點射出一條射線,而於每一 條射線上等距地取「樣本點」(Sample Points)。若樣本點未取在原本有資料的位置,

則利用其周圍的資料點作一「內插」「Interpolation」,再將所得數值轉換成適當的顏 色及「不透度」(Opacity),最後每一條線上前後點的顏色及不透度再以某種非線性 的方式前後合成起來,形成每一點在螢幕上所見最終的顏色。

2. 資料「快取」(Caching)及「預取」(Prefetching):

為加快資料的存取速度,利用資料預取這樣的觀念是其來有自。基於過往資料存取 模式預測未來[17],或是藉由對程式進行編譯分析[18],或是程式可直接、間接將存 取模式預先告知[19, 20],或是完全進行自動化的預取[3],都是曾被研究的課題。另 一派做法是更改資料在記憶體內的「配置」(Layout)進而增進資料的「局部性」

(Locality)[14],或降低資料在快取記憶體中因與其他資料的衝突而造成的快取記 憶體內的「衝突性失誤」(Conflict Misses)[16],進而提昇系統的效能。至於對快取 記憶體的詳盡描述,可見[15, 23],其中包含如 L1、L2 快取記憶體的大小,其「存 取延遲」(Accessing Latency),及其他相關硬體結構的資訊等。

3. 「超記憶體需求」(Out-of-Core)之資料處理:

除了參考快取及預取的概念之外,對於有超記憶體需求的資料處理也是一個提供借 鏡的地方。最簡單的做法是不做任何處理,而將具超記憶體需求的計算完全交給「作 業系統」(Operating System)以其「虛擬記憶體」(Virtual Memory)來處理。然而,

由於作業系統對執行程序的本身並無了解,這樣的做法通常十分沒有效率。一般說 來,對於有超記憶體需求的資料處理我們常採取兩種策略:其一是將資料進行資料 分割,其二是利用「用完就丟」或是「資源回收」(Garbage Collection)的觀念,以 盡量減少系統於記憶體上的消耗。這樣的觀念亦可應用於立體資料呈像上[21, 22, 24],而達到不錯的效果。

參考文獻:

[1] C. Yang and T. Chiueh, “I/O-Conscious Volume Rendering”, VisSym ’01, Joint Eurographics - IEEE TCVG Symposium on Visualization, May 2001.

(7)

[2] T. Mitra, C. Yang and T. Chiueh, “Application-Specific File Prefetching for MultimediaPrograms,IEEE Multimedia2000,pp. 459-462, July 2000.

[3] C. Yang, T. Mitra and T. Chiueh, A Decoupled Architecture forApplication-Specific File -Prefetching”, Usenix Annual Conference, FREENIX track 2002, pp. 157-170, June 2002.

[4] T. Chiueh, C. Yang, T. He, H. Pfister and A. Kaufman, “Integrated Volume Compression and Visualization”, IEEE Visualization 97,pp. 329-336, October 1997.

[5] C. Yang, T. Mitra and T. Chiueh, “On-the-Fly Rendering Of Losslessly Compressed IrregularVolumeData, IEEE Visualization 2000,pp. 101-108, October 2000.

[6] T. Chiueh, T. Mitra, A. Neogi and C. Yang, Zodiac:A History-Based Interactive Video Authoring System”, ACM Multimedia 1998, pp. 435-444, September 1998.

[7] T.Chiueh,T.Mitra,A.Neogiand C.Yang,“Zodiac:A history-based interactive video authoring system”, Multimedia Systems, vol. 8, no. 3, pp. 201-211, 2000.

[8] W. Lorensen and H. Cline, “Marching Cube: A High Resolution 3D Surface Construction Algorithm”, Computer Graphics, vol. 21, no. 4, pp. 163-169, July 1987.

[9] M. Levoy, “Display of Surfaces from Volume Data”, IEEE Computer Graphics and Applications, vol. 8, no. 3, pp. 29-37, March 1988.

[10] M. Levoy, “Efficient Ray Tracing of Volume Data”, ACM Transactions on Graphics, vol. 9, no. 3, pp. 245-261, 1990.

[11] L. Westover, “Interactive Volume Rendering”, Volume Visualization Workshop, pp.

9-16, May 1989.

[12] L. Westover, “Footprint Evaluation for Volume Rendering”, Computer Graphics, vol.

24, no. 4, pp. 367-376, 1990.

[13] P. Lacroute and M. Levoy, “ Fast Volume Rendering Using a Shear-Warp Factorization of the Viewing Transformation”, Computer Graphics, pp. 451-458, July 1994.

[14] M. Doggett and M. Meiner, “A Memory Addressing and Access Design for Real Time Volume Rendering”, Proceedings of IEEE Circuits and Systems, 1999.

[15] C. Sears, “The Elements of Cache Programming Style”, 4th Annual Linux Showcase

& Conference, 2000.

[16] G. Knittel, “The UltraVis System”, Proceedings of the 2000 IEEE Symposium on Volume Visualization, pp. 71-79, October 2000.

[17] D. Kotz and C. S. Ellis, Practical Prefetching Techniques for Parallel File Systems”, First International Conference on Parallel and Distributed Information Systems, December 1991.

[18] T. C. Mowry, M. S. Lam and A. Gupta, “Design and Evaluation of a Compiler Algorithm for Prefetching”, The Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, pp. 62-73, October 1992.

[19] R. H. Patterson, G. Gibson, E. Ginting, D. Stodolsky and J. Zelenka, “Informed Prefetching and Caching”, 15th ACM Symposium on Operating System Principle, December 1995.

[20] P. Cao, E. W. Felten, A. Karlin and K. Li, “A Study of Integrated Prefetching and Caching Strategies”, ACM SIGMETRICS Conference on Measurement and Modeling of Computer Systems, May 1995.

[21] M. Cox and D. Ellsworth, “Application-Controlled Demand Paging for Out-of-Core Visualization”,IEEE Visualization’97, October 1997.

[22] M. Cox, “Managing Big Data for Scientific Visualization”, ACM SIGGRAPH ’98 Course, August 1997.

(8)

[23]

http://developer.intel.com/design/pentium/manuals/

[24] S. K. Ueng, K. Siborski and K. L. Ma “Out-of-Core Streamline Visualization on Large Unstructured meshes”, ICASE Report, April 1997.

六、研究方法

研究方法與原因:

1. 文獻的蒐集及研究:

在此第一階段進行的是對相關文獻的蒐集及研究。由於科技的進步一日千里,我們也必 須跟得上時代。例如應用快取記憶體的研究過往有許多,但大多係針對Intel PentiumIII 的硬體結構,而如今主流的硬體設備已更新為Intel Pentium 4,由於其效能相差頗大,

所以新系統對設計上的影響不可不計。尤其 Intel 於線上常更新其相關產品的規格、資 訊、以及操作手冊的內容(見前述參考文獻[23]),更是對從事系統設計的人而言不可 或缺的重要參考資源。這其中對於快取記憶體的預取指令更是我們的研究重點。例如在 Pentium III 中有 Prefetch0,Prefetch1,Prefetch2 及 Prefetcha 等四個指令可以將資料預 取至 L1 或 L2 快取記憶體內。除了對快取記憶體有基本的瞭解外,關於記憶體內資料 的安排亦是文獻研究的重點之一,因其對立體資料的分割,以至於日後系統的效能都將 產生影響。

2. 系統特徵(System Characteristics)實測:

第二階段實測的重點主要是測量快取記憶體失誤的處理時間。一般說來,「L1 快取記憶 體」(L1 Caches)的失誤處理時間是由「L2 快取記憶體的延遲」(L2 Cache Latency)來 決定,而「L2 快取記憶體」(L2 Caches)的失誤處理時間是由「記憶體延遲」(Memory Latency)來決定,至於「L1 快取記憶體的延遲」(L1 Cache Latency)則是對 L1 快取 記憶體存取所需耗費的時間。這些數據我們可由 Intel 手冊或前人與自己的實測上來瞭 解系統在這方面的延遲大小。例如根據一些實測結果,在一Pentium III 800MHz 處理器 上的L1、L2、及主記憶體的延遲分別大約為 3.75ns、16.25ns、以及 100ns,而在一 Pentium4 2.4GHz 的處理器上相對的數字則分別變為只有 0.83ns、7.5ns、以及 63ns,此處 ns 為 10-9秒。注意到手冊所載僅能做為參考值,而在實際系統的運作上我們尚需考慮到其他 的「作業程序」(Processes)對快取記憶體效能所可能產生的影響。

3. 第三階段是瞭解資料分割的區塊大小對快取記憶體的存取有何影響,以及系統的「計 算時間」(Computation Time)對其可能產生的遮蔽效應,並據此來決定系統在進行初 始整合測試時的分割區塊大小。此處的區塊大小顯然必須小於系統的「資料快取記憶體」

(Data Cache)的大小,例如根據[23],在 Pentium III 中 L1 的資料快取記憶體約有 16KB,而 L2 快取記憶體則可有 256KB 或 512KB,但 L2 快取記憶體卻是由資料及「指 令」(Instructions)來共享。一般來說,每一分割區愈大,則快取記憶體所能容納的分 割區域數愈少。從遮蔽效應來說,快取記憶體內至少必須容納兩塊分割區,因此分割區 塊的大小可依此定出上界。另一方面,每一分割區塊的大小也於某種程度決定了在其上 執行呈像計算時所需耗費的時間。此二者的關係十分密切,因為我們可以據此決定快取 記憶體預取的速度。舉例來說,假設快取記憶體大小可容納四個分割區域,而執行每一 分割區域的計算相當於預取兩個分割區域至快取記憶體的時間,則系統應於每一次計算 開始時也同時開始進行預取的動作。預取速度快過於此將導致隨後取入的分割區域無處 可去,進而將一些之前預取至記憶體但尚未使用的分割區域排擠出去;預取速度慢過於 此將導致中央處理器必須閒置來等待資料進入快取記憶體,而這兩者都將造成效能的損 失。另一個可能必需考慮的效應是各分割區域的執行計算時間是否相去不遠?理論上看 來是如此,因為於立體資料呈像的計算中,「內插」佔計算工作的主要部分,而執行內 插的次數與每一分割區塊內所包含的「樣本點」(Sample Points)的次數成正比,又因 為每一分割區域所包含之樣本數大約相等,故在計算上所花的時間也應該大致相等。這 樣的關係也不應隨著觀看的角度不同而有所差異,因為位於一個分割區域內的樣本點的 數目仍應大致相等。

(9)

4. 第四階段是根據前一階段所選定的區塊大小,來測試系統在資料的各種不同記憶體

「配置」(Layout)情況下的存取表現,以作為決定系統記憶體配置的根據。在此前述 參考文獻中[14, 16]的做法頗可作為借鏡,而所需掌握的原則是在資料中空間關係鄰近 的資料點在記憶體中最好也能盡量保持其鄰近的關係,使得在同一分割區域被載入快取 記憶體時能一起被載入,而相同的資料也可以供鄰近的資料點在進行內插計算時使用。

5. 在此階段於各重要參數皆決定後,我們將進行系統的細部設計及初次整合。我們之 前所發展的部分程式[1]雖在此可以派上用場,進而降低系統開發時間,然而正如同於 背景部分所言,由於程式設計在協調快取記憶體的預取部分的困難度較高,而且系統進 行預取時是否已完成也較難掌握,所以預計本計劃在此階段可能將耗費較長的時間。

6. 最後一階段我們將進行系統整體效能的評估,以決定是否有調整各參數(資料分割 區 域 大 小 、 記 憶 體 配 置 方 法 ) 的 必 要 , 之 後 再 進 行 系 統 效 能 的 總 體 「 最 佳 化 」

(Optimization)。

七、結果與討論

目前系統開發已完成,並可正確地執行立體資料視覺化的動作。然而較不幸的是,由 於對快取記憶體的L2 Latency 估計的困難,造成整體效能的增進並不十分明顯,故未 來尚需對相關議題做持續探討,以找出其主要的原因。

參考文獻

相關文件

76 TAXAS DE VARIAÇÃO REAIS HOMÓLOGAS DE DESPESA DE CONSUMO FINAL DO GOVERNO, DADOS DE VOLUME EM CADEIA (ANO DE REFERÊNCIA = 2018) CHAIN VOLUME MEASURES OF QUARTERLY GOVERNMENT

76 TAXAS DE VARIAÇÃO REAIS HOMÓLOGAS DE DESPESA DE CONSUMO FINAL DO GOVERNO, DADOS DE VOLUME EM CADEIA (ANO DE REFERÊNCIA = 2018) CHAIN VOLUME MEASURES OF QUARTERLY GOVERNMENT

76 TAXAS DE VARIAÇÃO REAIS HOMÓLOGAS DE DESPESA DE CONSUMO FINAL DO GOVERNO, DADOS DE VOLUME EM CADEIA (ANO DE REFERÊNCIA = 2018) CHAIN VOLUME MEASURES OF QUARTERLY GOVERNMENT

Now given the volume fraction for the interface cell C i , we seek a reconstruction that mimics the sub-grid structure of the jump between 0 and 1 in the volume fraction

Take a time step on current grid to update cell averages of volume fractions at next time step (b) Interface reconstruction. Find new interface location based on volume

Take a time step on current grid to update cell averages of volume fractions at next time step (b) Interface reconstruction. Find new interface location based on volume

Take a time step on current grid to update cell averages of volume fractions at next time step (b) Interface reconstruction.. Find new interface location based on volume

Keywords: Finite volume method; Heterostructure; Large scale polynomial eigenvalue problem; Semiconductor pyramid quantum dot;.. Schr€