https://fluid.colorado.edu/wiki/api.php?action=feedcontributions&feedformat=atom&user=Mabl7046PHASTA Wiki - User contributions [en]2026-05-23T00:02:56ZUser contributionsMediaWiki 1.30.0https://fluid.colorado.edu/wiki/index.php?title=ParaView/Automation_with_Python&diff=1283ParaView/Automation with Python2021-02-16T21:24:40Z<p>Mabl7046: </p>
<hr />
<div>1. Extract surface using paraview, the code will look like <br />
<br />
<nowiki>from paraview.simple import *<br />
<br />
#========== read in data file<br />
print 'Read phasta file'<br />
dataObj = PhastaReader( FileName= 'restart_one.pht' ) # you have to change the name of this pht file<br />
SRF = ExtractSurface(Input=dataObj)<br />
MGBLK1 = MergeBlocks(Input=SRF)<br />
vtkWriter = DataSetWriter(FileName = 'Surface.vtk' , Input = MGBLK1, FileType = 1) # you have to change the name of this vtk file<br />
vtkWriter.UpdatePipeline()<br />
</nowiki><br />
<br />
Get the python file from <br />
<br />
<code>/users/ychen/NGC/geometry2012/pvExtractSuface.py</code><br />
[[Category:Paraview]] [[Category:Post-processing]]<br />
<br />
<br />
<br />
==Generating Python Scripts for Data Extraction==<br />
<br />
Generating python scripts can be done in the Paraview GUI and is actually pretty easy and straightforward. This process is documented [https://fluid.colorado.edu/tutorials/Paraview_Data_Extraction_Automation_1.mp4 here] in an example. Once the the script you want is generated, that script can be edited to automate data extraction. Again, a general example of this is outlined [https://fluid.colorado.edu/tutorials/Paraview_Data_Extraction_Automation_2.mp4 here]. Finally, once the script is run, data will be exported and look something like [https://fluid.colorado.edu/tutorials/Paraview_Data_Extraction_Automation_3.mp4 this].</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Automation_with_Python&diff=1282ParaView/Automation with Python2021-02-16T21:18:42Z<p>Mabl7046: </p>
<hr />
<div>1. Extract surface using paraview, the code will look like <br />
<br />
<nowiki>from paraview.simple import *<br />
<br />
#========== read in data file<br />
print 'Read phasta file'<br />
dataObj = PhastaReader( FileName= 'restart_one.pht' ) # you have to change the name of this pht file<br />
SRF = ExtractSurface(Input=dataObj)<br />
MGBLK1 = MergeBlocks(Input=SRF)<br />
vtkWriter = DataSetWriter(FileName = 'Surface.vtk' , Input = MGBLK1, FileType = 1) # you have to change the name of this vtk file<br />
vtkWriter.UpdatePipeline()<br />
</nowiki><br />
<br />
Get the python file from <br />
<br />
<code>/users/ychen/NGC/geometry2012/pvExtractSuface.py</code><br />
[[Category:Paraview]] [[Category:Post-processing]]<br />
<br />
<br />
<br />
==Generating Python Scripts for Data Extraction==<br />
<br />
which is documented [https://fluid.colorado.edu/tutorials/Paraview_Data_Extraction_Automation_1.mp4 here].</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1279ParaView/Tricks2021-02-05T00:02:09Z<p>Mabl7046: /* Step 2 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that the velocity field is set as the Scalar Array. When this is set, click apply.<br />
<br />
======Step 2======<br />
Once the velocity gradient vector is computed, use the <code>Python Calculator</code> filter. In the box labeled expression, type <code>eigenvalue(strain(Velocity)**2 + (Gradients - strain(Velocity))**2)</code>. Note that your velocity field may not be called Velocity. If this is the case, change the aforementioned formula accordingly. Also, I recommend calling the Array name <code>lambda</code> opposed to the default <code>result</code>. The lambda_2 values will be the entries in the second column of this computed vector. <br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1278ParaView/Tricks2021-02-05T00:01:23Z<p>Mabl7046: /* Step 2 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that the velocity field is set as the Scalar Array. When this is set, click apply.<br />
<br />
======Step 2======<br />
Once the velocity gradient vector is computed, use the <code>Python Calculator</code> filter. In the box labeled expression, type <code>eigenvalue(strain(Velocity)**2 + (Gradients - strain(Velocity))**2)</code>. Note that your velocity field may not be called Velocity. If this is the case, change the aforementioned formula accordingly. Also, I recommend calling the Array name <code>lambda</code> opposed to the default <code>result</code>. <br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1277ParaView/Tricks2021-02-04T23:59:04Z<p>Mabl7046: /* Step 2 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that the velocity field is set as the Scalar Array. When this is set, click apply.<br />
<br />
======Step 2======<br />
Once the velocity gradient vector is computed, use the <code>Python Calculator</code> filter. In the box labeled expression, type <code>eigenvalue(strain(Velocity)**2 + (Gradients - strain(Velocity))**2)</code>. Note that your velocity field may not be called Velocity. If this is the case, change the formula accordingly. <br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1276ParaView/Tricks2021-02-04T23:55:11Z<p>Mabl7046: /* Step 2 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that the velocity field is set as the Scalar Array. When this is set, click apply.<br />
<br />
======Step 2======<br />
Once the velocity gradient vector is computed, use the <code>Python Calculator</code> filter. <br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1275ParaView/Tricks2021-02-04T23:55:01Z<p>Mabl7046: /* Step 2 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that the velocity field is set as the Scalar Array. When this is set, click apply.<br />
<br />
======Step 2======<br />
Once the velocity gradient vector is computed, use the <code>Python Calculator </code> filter. <br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1274ParaView/Tricks2021-02-04T23:54:53Z<p>Mabl7046: /* Step 1 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that the velocity field is set as the Scalar Array. When this is set, click apply.<br />
<br />
======Step 2======<br />
Once the velocity gradient vector is computed, use the <code>Python Calculator <\code> filter. <br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1273ParaView/Tricks2021-02-04T23:54:42Z<p>Mabl7046: /* Step 2 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that the velocity field is set as the Scalar Array. When this is set, click apply.<br />
<br />
<br />
======Step 2======<br />
Once the velocity gradient vector is computed, use the <code>Python Calculator <\code> filter. <br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1272ParaView/Tricks2021-02-04T23:53:07Z<p>Mabl7046: /* Step 1 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that the velocity field is set as the Scalar Array. When this is set, click apply.<br />
<br />
<br />
======Step 2======<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1271ParaView/Tricks2021-02-04T23:52:35Z<p>Mabl7046: /* Step 1 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that the velocity field is set as the Scalar Array.<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1270ParaView/Tricks2021-02-04T23:52:02Z<p>Mabl7046: /* Step 1 */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter. Make sure the box labeled <code>Computed Gradient</code> has an x and that <code>u</code> is set as the Scalar Array.<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1269ParaView/Tricks2021-02-04T23:47:16Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
There is also a third useful metric for visualizing vortices. This is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter.<br />
<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1268ParaView/Tricks2021-02-04T23:46:23Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for visualizing vortices is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
First, you will need to compute the velocity gradient vector. This can be done using Paraview's <code>Gradient of Unstructured DataSet</code> filter.<br />
<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1267ParaView/Tricks2021-02-04T23:42:06Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for visualizing vortices is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1266ParaView/Tricks2021-02-04T23:41:55Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for visualizing vortices is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
=======Step 1=======<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1265ParaView/Tricks2021-02-04T23:41:46Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for visualizing vortices is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
======Step 1======<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1264ParaView/Tricks2021-02-04T23:41:35Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for visualizing vortices is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
=====Step 1=====<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1263ParaView/Tricks2021-02-04T23:41:25Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for visualizing vortices is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
====Step 1====<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1262ParaView/Tricks2021-02-04T23:41:06Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for visualizing vortices is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
===Step 1===<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1261ParaView/Tricks2021-02-04T23:40:48Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for visualizing vortices is lambda_2 criterion. This process is outlined below.<br />
<br />
; Lambda_2-criterion<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1260ParaView/Tricks2021-02-04T23:37:36Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for visualizing vortices is lambda_2 criterion.<br />
<br />
; Lambda_2-criterion<br />
<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=ParaView/Tricks&diff=1259ParaView/Tricks2021-02-04T23:35:03Z<p>Mabl7046: /* Visualizing Vortices */</p>
<hr />
<div>This page contains a list of tips and tricks for ParaView, which may be useful for others.<br />
<br />
==Difference Between Two Timesteps==<br />
To look at the "delta" between two timesteps, follow these steps.<br />
# Load your data file twice, so your pipeline browser has two separate instances of "flow.pht" or whatever file you open.<br />
# Apply one Force Time filter to each input file, and specify the physical time (not time index) for each. This will force the time for each and make them independent of the global ParaView time control in the upper toolbar.<br />
# Select both Force Time filters simultaneously, and apply a Programmable Filter. Your pipeline browser will now show arrows representing multiple inputs to the single programmable filter.<br />
# Populate the programmable filter with the following code:<br><code>tmp = inputs[0].PointData['myAvailableFieldName'] - inputs[1].PointData['myAvailableFieldName']<br>output.PointData.append(tmp, 'delta of myAvailableFieldName')</code><br />
# You can now view the field, "delta of myAvailableFieldName," and change the time steps it uses to compute the time-delta by modifying the Force Time filter properties.<br />
<br />
Example script: relative change in eddy viscosity<br><br />
<nowiki><br />
s = 'EV'<br />
a = inputs[0].PointData[s]<br />
b = inputs[1].PointData[s]<br />
tmp = (a - b) / b<br />
output.PointData.append(tmp, 'delta')</nowiki><br />
<br />
==Stepping Forward in Time==<br />
Let's say you load your ParaView file (for PHASTA, *.pht or *.phts) as <code>phtFile</code>. The times associated with each timestep referenced by the file are given by <code>phtFile.TimestepValues</code>.<br />
<br />
To step forward in time, set the time of the current view. For example, <code>GetActiveView().ViewTime = myTime</code>. When you save an image, all visible sources will be rendered using data from that time (<code>myTime</code>).<br />
<br />
==Saving Data at a Given Time==<br />
It turns out the data fields you access through Python are not updated simply by setting the active view's <code>ViewTime</code> property. For example, if you're trying to extract data from a probe location or along a line, simply saving that pipeline object does not reflect the updated timestep. Instead, you need to call the <code>UpdatePipeline(time=myTime)</code> method of your <code>ProbeLocation</code>, <code>Slice</code>, or other pipeline object. This method is inherited from <code>SourceProxy</code>.<br />
<br />
==Visualizing Vortices==<br />
Two methods for visualizing vortices are taking iso-surfaces of either Q-criterion or the Omega-criterion (Liu 2016, "New omega vortex identification method"). To compute both, apply "Gradient of Unstructured Dataset" to the velocity field in ParaView, and name the result <code>g</code>. Then enter one of the following expressions into a Calculator, and finally apply a Contour at the appropriate value:<br />
; Q-criterion<br />
: <code>-g_1*g_3-g_2*g_6-g_5*g_7+g_4*g_8+g_0*(g_4+g_8)</code><br />
: Contour at whatever value shows the features you want; try 1e7 as a starting point, but Q has a huge range of magnitudes<br />
; Omega-criterion<br />
: <code>(g_1^2 + g_2^2 - 2*g_1*g_3 + g_3^2 + g_5^2 - 2*g_2*g_6 + g_6^2 - 2*g_5*g_7 + g_7^2) / (2 * (g_0^2 + g_1^2 + g_2^2 + g_3^2 + g_4^2 + g_5^2 + g_6^2 + g_7^2 + g_8^2 + 1e-14))</code><br />
: Contour at 0.52 as recommended in the Liu (2016) paper to start; Omega is always between 0 and 1<br />
<br />
A third useful metric for<br />
[[Category:Paraview]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1219Chef/Building2020-10-24T19:50:47Z<p>Mabl7046: /* General Instruction */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
For students looking to see what compiled successfully on the viz nodes, please go to <code>/users/mabl7046/Group_Dir</code>. The workflow is exactly the same as what is outlined below, however, the scripts were of course altered to set the environment properly for the viz nodes.<br />
<br />
<br />
<br />
Note that <code>.smdmodels</code> made with a new version of <code>simModeler</code> will likely only work with chef compiled with a recent version of <code>simModSuite</code>.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714</code>. When this is encountered, the SCORE/core source code must be changed. From the build directory vim the file <code>FindSimModSuite.cmake</code>. This is in the directory <code>/core/cmake</code>. Scroll down to line 87 and edit <code>set(MAX_VALID_SIM_VERSION 15.0.200714)</code> to a Simmetrix version within the range of the version you are using to compile.<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1218Chef/Building2020-10-24T19:49:19Z<p>Mabl7046: /* General Instruction */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
For students looking to see what compiled successfully on the viz nodes, please go to <code>/users/mabl7046/Group_Dir</code>.<br />
<br />
<br />
<br />
Note that <code>.smdmodels</code> made with a new version of <code>simModeler</code> will likely only work with chef compiled with a recent version of <code>simModSuite</code>.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714</code>. When this is encountered, the SCORE/core source code must be changed. From the build directory vim the file <code>FindSimModSuite.cmake</code>. This is in the directory <code>/core/cmake</code>. Scroll down to line 87 and edit <code>set(MAX_VALID_SIM_VERSION 15.0.200714)</code> to a Simmetrix version within the range of the version you are using to compile.<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1217Chef/Building2020-10-24T19:48:48Z<p>Mabl7046: /* General Instruction */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
For students looking to see what compiled successfully on the viz nodes, please go to <code>/users/mabl7046/Group_Dir</code>.<br />
<br />
<br />
<br />
<code>.smdmodels</code> made with a new version of <code>simModeler</code> will likely only work with chef compiled with a recent version of <code>simModSuite</code>.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714</code>. When this is encountered, the SCORE/core source code must be changed. From the build directory vim the file <code>FindSimModSuite.cmake</code>. This is in the directory <code>/core/cmake</code>. Scroll down to line 87 and edit <code>set(MAX_VALID_SIM_VERSION 15.0.200714)</code> to a Simmetrix version within the range of the version you are using to compile.<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1216Chef/Building2020-10-24T19:44:09Z<p>Mabl7046: /* General Instruction */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
<code>.smdmodels</code> made with a new version of <code>simModeler</code> will likely only work with chef compiled with a recent version of <code>simModSuite</code>.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714</code>. When this is encountered, the SCORE/core source code must be changed. From the build directory vim the file <code>FindSimModSuite.cmake</code>. This is in the directory <code>/core/cmake</code>. Scroll down to line 87 and edit <code>set(MAX_VALID_SIM_VERSION 15.0.200714)</code> to a Simmetrix version within the range of the version you are using to compile.<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1215Chef/Building2020-10-24T19:42:15Z<p>Mabl7046: /* Common Errors */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
Here would go some general instructions. I'm not experienced enough to know what they would be.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714</code>. When this is encountered, the SCORE/core source code must be changed. From the build directory vim the file <code>FindSimModSuite.cmake</code>. This is in the directory <code>/core/cmake</code>. Scroll down to line 87 and edit <code>set(MAX_VALID_SIM_VERSION 15.0.200714)</code> to a Simmetrix version within the range of the version you are using to compile.<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1214Chef/Building2020-10-24T19:41:55Z<p>Mabl7046: /* General Instruction */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
Here would go some general instructions. I'm not experienced enough to know what they would be.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714</code>. When the is encountered, the SCORE/core source code must be changed. From the build directory vim the file <code>FindSimModSuite.cmake</code>. This is in the directory <code>/core/cmake</code>. Scroll down to line 87 and edit <code>set(MAX_VALID_SIM_VERSION 15.0.200714)</code> to a Simmetrix version within the range of the version you are using to compile.<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1213Chef/Building2020-10-24T19:40:19Z<p>Mabl7046: /* Common Errors */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
Here would go some general instructions. I'm not experienced enough to know what they would be.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714</code>. When the is encountered, the SCORE/core source code must be changed. From the build directory vim the file <code>FindSimModSuite.cmake</code>. This is in the directory <code>/core/cmake</code>. Scroll down to line 87 and edit <code>set(MAX_VALID_SIM_VERSION 17.0.200714)</code><br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1212Chef/Building2020-10-24T19:39:20Z<p>Mabl7046: /* General Instruction */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
Here would go some general instructions. I'm not experienced enough to know what they would be.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714</code>. When the is encountered, the SCORE/core source code must be changed. From the build directory vim the file <code>FindSimModSuite.cmake</code>. This is in the directory <code>/core/cmake</code>.<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1211Chef/Building2020-10-24T19:36:31Z<p>Mabl7046: /* Common Errors */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
Here would go some general instructions. I'm not experienced enough to know what they would be.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714 </code>.<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1210Chef/Building2020-10-24T19:36:01Z<p>Mabl7046: /* Common Errors */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
Here would go some general instructions. I'm not experienced enough to know what they would be.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714 <\code>.<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1209Chef/Building2020-10-24T19:35:14Z<p>Mabl7046: /* Common Errors */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
Here would go some general instructions. I'm not experienced enough to know what they would be.<br />
<br />
<br />
===Common Errors ===<br />
The following error is very common when Compiling Chef: <code> CMake Error at cmake/FindSimModSuite.cmake:93 (MESSAGE):<br />
invalid Simmetrix version: 15.0.201010, valid versions are 12.0.190225 to 15.0.200714 <\code><br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Chef/Building&diff=1208Chef/Building2020-10-24T19:24:47Z<p>Mabl7046: /* General Instruction */</p>
<hr />
<div>This goes over how to compile Chef and some system specific instructions for doing so.<br />
<br />
== General Instruction ==<br />
<br />
Here would go some general instructions. I'm not experienced enough to know what they would be.<br />
<br />
<br />
===Common Errors ===<br />
<br />
== System Specific ==<br />
<br />
=== Summit (RMACC) ===<br />
<br />
====Copy Simmetrix Libraries from Viz Nodes====<br />
<br />
Note that in order for Chef to operate, it must be compiled with the proper Simmetrix libraries. That is to say, there needs to be compatibility between Simmetrix and SCOREC-core for compilation of Chef to run smoothly. Please see [[Building_SCOREC_Core|Building SCOREC Core]] for instructions on cloning the source code. An example (what worked for me) is provided throughout the wiki. From the viz nodes (<code>/projects/tools/SimmetrixTest</code>), I ran<br />
<br />
scp -r 14.0-190626beta/ <username>@login.rc.colorado.edu:<path><br />
<br />
to copy over the directory <code>14.0-190626beta/</code> to Summit.<br />
<br />
====Set Proper Environment====<br />
<br />
To start with a clean slate, run <br />
<br />
module purge<br />
<br />
This unloads all currently loaded modules.<br />
<br />
Next, run<br />
<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
<br />
Note that /6.1.0 and /2.0.1 can be swapped with the intended versions of GCC and OpenMPI the user intends on using.<br />
<br />
====Generate Partition Wrapper====<br />
<br />
After the directory is copied over to Summit and the environment is set, a Partition Wrapper needs to be generated. Go to:<br />
<br />
<path>/14.0-190626beta/code/PartitionWrapper<br />
<br />
and open the file <br />
<br />
Makefile.custom<br />
<br />
Obviously, <code>14.0-190626beta/</code> is a placeholder and any version of Simmetrix (i.e. the version you used to create the mesh) will work. In this example, I used OpenMPI . I also used <code>mpicc</code> and <code>mpicxx</code> as MPI-C and MPI-C++ compilers respectively. If this is what is intended, in the <code>Makefile</code>, set the following variables:<br />
<br />
PQUAL:= -openmpi<br />
CC:=/curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicc <br />
CXX:= /curc/sw/openmpi/2.0.1/gcc/6.1.0/bin/mpicxx<br />
<br />
Notice the compatibility between the loaded modules and the directory structure above. Once this is set, in the terminal run<br />
<br />
make -f Makefile.custom PARALLEL=openmpi<br />
<br />
This will generate a file named <code>libSimPartitionWrapper-openmpi.a</code>. Then, run<br />
<br />
chmod +x libSimPartitionWrapper-openmpi.a.<br />
<br />
Once this is completed, copy this newly generated partition wrapper to <code>../../lib/x64_rhel7_gcc48/</code>. Unfortunately, the instructions from this point forward will be less explicit as the best way to learn the process is to view example scripts and adapt these to fit your needs. From this point forward, it is assumed that a directory named <code>SCOREC-core</code> was created and the source code from GitHub was properly cloned in this directory. <br />
<br />
====Generating the Scripts to Compile Chef====<br />
<br />
In order to run Chef, two scripts must be generated. The naming conventions of the scripts are typically <code>doConfigure.sh</code> and <code>env_simmtrix_version</code>. Below, an example <code>doConfigure.sh</code> script is shown. This script primarily executes the necessary CMake commands for compilation. It also runs the <code>env_simmtrix_version</code> script. In the example below, it calls <code>env_14.0-190626</code>. Note that both of these scripts are located in <code>/projects/mabl7046/SCOREC-core/build_14.0-190626</code>, or the directory where Chef is to be compiled. Note that the line <code>-DMESHES="/projects/mabl7046/pumi-meshes"</code> was copied from a script that implemented successfully on another machine. I recommend looking at scripts on the Viz nodes that worked for the version of Chef you are compiling and copying over the directory analogous to pumi-meshes to summit to implement your script.<br />
<br />
<code>doConfigure.sh</code>:<br />
#!/bin/bash -l<br />
. /projects/mabl7046/SCOREC-core/build_14.0-190626/env_14.0-190626<br />
#unload default modules<br />
module purge<br />
#load what we need<br />
module load gcc/6.1.0<br />
module load openmpi/2.0.1<br />
module load cmake/3.14.1<br />
### For Chef<br />
cmake -DCMAKE_C_COMPILER=mpicc \<br />
-DCMAKE_CXX_COMPILER=mpicxx \<br />
-DSCOREC_CXX_WARNINGS=ON \<br />
-DSCOREC_CXX_OPTIMIZE=ON \<br />
-DSCOREC_CXX_SYMBOLS=ON \<br />
-DPCU_COMPRESS=ON \<br />
-DENABLE_ZOLTAN=ON \<br />
-DENABLE_SIMMETRIX=ON \<br />
-DSIM_MPI="openmpi" \<br />
-DSIM_PARASOLID=ON \<br />
-DMDS_SET_MAX=1024 \<br />
-DMDS_ID_TYPE=long \<br />
-DIS_TESTING=OFF \<br />
-DMESHES="/projects/mabl7046/pumi-meshes" \<br />
-DCMAKE_INSTALL_PREFIX=$PWD/install \<br />
../core<br />
#-DMDS_ID_TYPE=int or long<br />
sleep 3<br />
make -j32<br />
make -j32<br />
<br />
Below, the script <code>env_14.0-190626</code> is given. As stated in the comments, this is to set the environment for <code>CMake.SCOREC</code>. In order to make this script work, the <code>SIM_LICENSE_FILE</code> (denoted UCBoulder below) needed to be obtained. The libraries for <code>Zoltan</code> and <code>parmetis</code> also needed to be collected. The <code>SIM_LICENSE_FILE</code> was copied over from Cooley although, I am sure that this can be obtained from the Viz nodes as well. To obtain the libraries for <code>Zoltan</code> and <code>parmetis</code> on Summit, run:<br />
<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/zoltan .<br />
cp -r /projects/ASEN5119/SCOREC-core/deps/parmetis .<br />
<br />
from the directory where you wish these to be. All this does is move these from a directory Ken created for his Boundary Layers course to a directory that is more convenient for personal use. <br />
<br />
<code>env_14.0-190626</code>:<br />
### For CMake.SCOREC<br />
export buildRoot=/projects/mabl7046/SCOREC-core/<br />
export simModVer=$buildRoot/deps/Simmetrix/14.0-190626beta/<br />
export SIM_LICENSE_FILE=$buildRoot/deps/Simmetrix/UCBoulder<br />
export CMAKE_PREFIX_PATH=$simModVer<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/lib/x64_rhel7_gcc48/psKrnl<br />
#MIGHT NEED THIS export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/projects/tools/Simmetrix.develop/simModSuite/PartitionWrapper/lib<br />
### For Zoltan and parmetis<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/zoltan/3.83-gnu49-ompi210/<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$buildRoot/deps/parmetis/4.0.3-gnu492-ompi210<br />
# the following is to give the path to PartitionWrappers that have not been installed in the Simmetrix library<br />
export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$simModVer/code/PartitionWrapper/lib<br />
<br />
====Final Notes====<br />
Once the scripts are set up, simply run <code>./doConfigure.sh</code> to compile the code. Please be patient with the process as it is highly unlikely that it will compile successfully the first time you try. Be sure to pay close attention to your directory structure when setting your scripts up and be cognizant of the dependencies between programs.<br />
<br />
[[Category: Chef]]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Exporting_Parasolid_from_SolidWorks&diff=1185Exporting Parasolid from SolidWorks2020-09-21T18:54:50Z<p>Mabl7046: </p>
<hr />
<div>Save out your Model as a parasolid from [[SolidWorks]]. Note that you will want the geometry as close to ready for meshing as possible, as performing model "surgery" in simmodeler is not always straight forward. The outputted file will have the format <code><file_name>.x_t</code>. Next, you'll want to change the extension from <code>.x_t</code> to <code>.xmt_txt</code>. To do this, run <code>mv <file_name>.x_t <file_name>.xmt_txt</code> from your terminal. From here, you are ready for the ''convert'' step, which is documented [https://fluid.colorado.edu/tutorials/Convert2Sim_Tutorial.mp4 here]. Once this is complete, you are ready to use [[Getting Started with Simmodeler| simmodeler]]. Note, if you do not have a parasolid model of your own, please go to the directory <code> /projects/tutorials/On_Ramp_parasolid</code> and use <code> On_ramp_example.x_t</code>.</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Exporting_Parasolid_from_SolidWorks&diff=1184Exporting Parasolid from SolidWorks2020-09-21T18:53:38Z<p>Mabl7046: </p>
<hr />
<div>Save out your Model as a parasolid from [[SolidWorks]]. Note that you will want the geometry as close to ready for meshing as possible, as performing model "surgery" in simmodeler is not always straight forward. The outputted file will have the format <code><file_name>.x_t</code>. Next, you'll want to change the extension from <code>.x_t</code> to <code>.xmt_txt</code>. To do this, run <code>mv <file_name>.x_t <file_name>.xmt_txt</code> from your terminal. From here, you are ready for the ''convert'' step, which is documented [https://fluid.colorado.edu/tutorials/Convert2Sim_Tutorial.mp4 here]. Once this is complete, you are ready to use [[Getting Started with Simmodeler| simmodeler]]. Note, if you do not have a parasolid model of your own, please go to the directory <code> /projects/tutorials/On_Ramp_parasolid</code></div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Exporting_Parasolid_from_SolidWorks&diff=1183Exporting Parasolid from SolidWorks2020-09-21T18:53:21Z<p>Mabl7046: </p>
<hr />
<div>Save out your Model as a parasolid from [[SolidWorks]]. Note that you will want the geometry as close to ready for meshing as possible, as performing model "surgery" in simmodeler is not always straight forward. The outputted file will have the format <code><file_name>.x_t</code>. Next, you'll want to change the extension from <code>.x_t</code> to <code>.xmt_txt</code>. To do this, run <code>mv <file_name>.x_t <file_name>.xmt_txt</code> from your terminal. From here, you are ready for the ''convert'' step, which is documented [https://fluid.colorado.edu/tutorials/Convert2Sim_Tutorial.mp4 here]. Once this is complete, you are ready to use [[Getting Started with Simmodeler| simmodeler]]. Note, if you do not have a parasolid model of your own, please go to the directory <code> /projects/tutorials/On_Ramp_parasolid <\code></div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Post-Process&diff=1099Post-Process2020-09-14T19:36:31Z<p>Mabl7046: /* Visualization File */</p>
<hr />
<div><br />
== Visualization File ==<br />
In the directory where the case was run, you will need a meta-data file with a <code> .phts</code> file extension. An example of this file with a detailed explanation of what is inside of the file, is outlined [https://fluid.colorado.edu/tutorials/ParaviewWithMark_meta_data_description.mp4 here].<br />
<br />
<br />
==Visualizing Fields and Computing Quantities==<br />
<br />
A tutorial on how to navigate the GUI to visualize solution fields as well as compute other solution fields is given [https://fluid.colorado.edu/tutorials/ParaviewWithMark_viz_fields.mp4 here].</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Post-Process&diff=1098Post-Process2020-09-14T19:09:54Z<p>Mabl7046: </p>
<hr />
<div><br />
== Visualization File ==<br />
In the directory where the case was run, you will need a meta-data file with a <code> .phts</code> file extension. An example of this file with a detailed explanation of what is inside of the file, is outlined [https://fluid.colorado.edu/tutorials/ParaviewWithMark_meta_data_description.mp4 here].</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Post-Process&diff=1095Post-Process2020-09-14T18:49:23Z<p>Mabl7046: </p>
<hr />
<div><br />
== Visualization File ==<br />
In the directory where the case was run, you will need a meta-data file with a <code> .phts</code> file extension. An example of this file with a detailed explanation of what is inside of the file, is outlined here.</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Post-Process&diff=1094Post-Process2020-09-14T18:49:01Z<p>Mabl7046: </p>
<hr />
<div><br />
== Visualization File ==<br />
In the directory where the case was run, you will need a meta-data file with a <code> .phts</code> file extension. An example of this file with a detailed explanation of what is inside of the file is outlined here.</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Post-Process&diff=1093Post-Process2020-09-14T18:48:35Z<p>Mabl7046: </p>
<hr />
<div>In the directory where the case was run, you will need a meta-data file with a <code> .phts</code> file extension. An example of this file with a detailed explanation of what is inside of the file is outlined here.</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Post-Process&diff=1092Post-Process2020-09-14T18:48:18Z<p>Mabl7046: </p>
<hr />
<div>In the directory where the case was run, you will need a meta-data file with a <code> .phts </code> file extension. An example of this file with a detailed explanation of what is inside of the file is outlined here.</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Post-Process&diff=1091Post-Process2020-09-14T18:47:24Z<p>Mabl7046: </p>
<hr />
<div>In the directory where the case was run, you will need a meta-data file with a <code> .phts <code> file extension. An example of this file with a detailed explanation of what is inside of the file is outlined here.</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Post-Process&diff=1090Post-Process2020-09-14T18:47:06Z<p>Mabl7046: </p>
<hr />
<div>In the directory where the case was run, you will need a meta-data file with a <code> .phts <\code> file extension. An example of this file with a detailed explanation of what is inside of the file is outlined here.</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Getting_Started_with_Simmodeler&diff=1070Getting Started with Simmodeler2020-09-10T19:29:40Z<p>Mabl7046: /* Mesh Refinement Zones */</p>
<hr />
<div>==Launching the Software ==<br />
Once your environment is properly set, as shown in the [https://fluid.colorado.edu/tutorials/Convert2Sim_Tutorial.mp4 convert step video], run: <code> vglrun /projects/tools/SimmetrixTest/SimModeler7.0-190626/simmodeler</code> in your terminal to launch simmodeler. Note that 7.0-190626 specifies the version of simmodeler you are launching.<br />
<br />
==Accessing the User Manual==<br />
When launching simmodeler, there is a blue question mark at the top right of the GUI. Click it and then click "launch manual" to open the user manual associated with the version of simmodeler you are using. This gives detailed descriptions of the various attributes and how they are defined to generate the desired mesh.<br />
<br />
==Surface Meshing==<br />
<br />
===2D and 1D Boundary Layers===<br />
<br />
To generate a proper surface mesh, it is important that both 2D and 1D boundary layers are implemented. Note that a 2D Boundary layer is defined on a surface and a 1D Boundary layer is defined on a line. The linked [https://fluid.colorado.edu/tutorials/MeshingWingInRoom_1D_2D_BLs.mp4 video] shows both 2D and 1D boundary layers being applied to an airfoil and the mesh that results from these applied attributes.<br />
<br />
===Mesh Size and Face Extrusions===<br />
<br />
Two more useful attributes when generating proper surface meshes are defining Mesh Sizes and Face Extrusions on your desired surfaces. Face Extrusions are useful when adding refinement over curved surfaces. This process is well covered in this [https://fluid.colorado.edu/tutorials/MeshingWingInRoom_MeshSize_FaceExt.mp4 video].<br />
<br />
<br />
==Volume Meshing==<br />
<br />
===3D Boundary Layers===<br />
One of the most important aspects of volume mesh development is generating proper 3D boundary layers. This process is well outlined [https://fluid.colorado.edu/tutorials/RajDemo.mp4 here] from around 8:30 to 16:00. Note that all mesh attributes are set up under the "Meshing" tab.<br />
<br />
===Mesh Refinement Zones===<br />
Mesh refinement zones are useful for increasing the grid density within certain volumes of your simulation domain. The linked [https://fluid.colorado.edu/tutorials/Mesh_refinement_zone_tutorial.mp4 mesh refinement tutorial] will briefly walk you through how these are implemented.<br />
<br />
==Saving Out the Mesh==<br />
Once you are satisfied with your mesh refinement, you are ready to generate and save out the mesh. In the meshing tab, you will want to click ''Generate Mesh''. The default settings will suffice for proper mesh generation. If your grid is large, this step can take some time. Once the grid is finished generating, you will want to save out this file as you will need it later.<br />
<br />
==Applying Boundary and Initial Conditions==<br />
A nice description of each of the common BCs used in both the Compressible and Incompressible builds of PHASTA is provided [https://fluid.colorado.edu/wiki/index.php/SimModeler here]. The [https://fluid.colorado.edu/tutorials/BC_tutorial.mp4 video] linked in this section shows how the BCs are applied for an incompressible case. Note that the case needs to be called ''geom'' as is done in the tutorial video. Once the BCs are successfully implemented, you have saved out a model file with these BCs(.smd), and have generated your grid (.sms file), your are ready to prepare the grid for Chef. To get started on this step, click [https://fluid.colorado.edu/wiki/index.php/Prepping_the_Grid_for_Chef here]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Getting_Started_with_Simmodeler&diff=1069Getting Started with Simmodeler2020-09-10T18:39:08Z<p>Mabl7046: </p>
<hr />
<div>==Launching the Software ==<br />
Once your environment is properly set, as shown in the [https://fluid.colorado.edu/tutorials/Convert2Sim_Tutorial.mp4 convert step video], run: <code> vglrun /projects/tools/SimmetrixTest/SimModeler7.0-190626/simmodeler</code> in your terminal to launch simmodeler. Note that 7.0-190626 specifies the version of simmodeler you are launching.<br />
<br />
==Accessing the User Manual==<br />
When launching simmodeler, there is a blue question mark at the top right of the GUI. Click it and then click "launch manual" to open the user manual associated with the version of simmodeler you are using. This gives detailed descriptions of the various attributes and how they are defined to generate the desired mesh.<br />
<br />
==Surface Meshing==<br />
<br />
===2D and 1D Boundary Layers===<br />
<br />
To generate a proper surface mesh, it is important that both 2D and 1D boundary layers are implemented. Note that a 2D Boundary layer is defined on a surface and a 1D Boundary layer is defined on a line. The linked [https://fluid.colorado.edu/tutorials/MeshingWingInRoom_1D_2D_BLs.mp4 video] shows both 2D and 1D boundary layers being applied to an airfoil and the mesh that results from these applied attributes.<br />
<br />
===Mesh Size and Face Extrusions===<br />
<br />
Two more useful attributes when generating proper surface meshes are defining Mesh Sizes and Face Extrusions on your desired surfaces. Face Extrusions are useful when adding refinement over curved surfaces. This process is well covered in this [https://fluid.colorado.edu/tutorials/MeshingWingInRoom_MeshSize_FaceExt.mp4 video].<br />
<br />
<br />
==Volume Meshing==<br />
<br />
===3D Boundary Layers===<br />
One of the most important aspects of volume mesh development is generating proper 3D boundary layers. This process is well outlined [https://fluid.colorado.edu/tutorials/RajDemo.mp4 here] from around 8:30 to 16:00. Note that all mesh attributes are set up under the "Meshing" tab.<br />
<br />
===Mesh Refinement Zones===<br />
Mesh refinement zones are useful for increasing the grid density within certain volumes of your simulation domain. The linked ''Mesh Refinement Tutorial'' will briefly walk you through how these are implemented.<br />
<br />
<br />
==Saving Out the Mesh==<br />
Once you are satisfied with your mesh refinement, you are ready to generate and save out the mesh. In the meshing tab, you will want to click ''Generate Mesh''. The default settings will suffice for proper mesh generation. If your grid is large, this step can take some time. Once the grid is finished generating, you will want to save out this file as you will need it later.<br />
<br />
==Applying Boundary and Initial Conditions==<br />
A nice description of each of the common BCs used in both the Compressible and Incompressible builds of PHASTA is provided [https://fluid.colorado.edu/wiki/index.php/SimModeler here]. The [https://fluid.colorado.edu/tutorials/BC_tutorial.mp4 video] linked in this section shows how the BCs are applied for an incompressible case. Note that the case needs to be called ''geom'' as is done in the tutorial video. Once the BCs are successfully implemented, you have saved out a model file with these BCs(.smd), and have generated your grid (.sms file), your are ready to prepare the grid for Chef. To get started on this step, click [https://fluid.colorado.edu/wiki/index.php/Prepping_the_Grid_for_Chef here]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Getting_Started_with_Simmodeler&diff=1068Getting Started with Simmodeler2020-09-10T18:38:03Z<p>Mabl7046: /* Applying Mesh Attributes */</p>
<hr />
<div>==Launching the Software ==<br />
Once your environment is properly set, as shown in the [https://fluid.colorado.edu/tutorials/Convert2Sim_Tutorial.mp4 convert step video], run: <code> vglrun /projects/tools/SimmetrixTest/SimModeler7.0-190626/simmodeler</code> in your terminal to launch simmodeler. Note that 7.0-190626 specifies the version of simmodeler you are launching.<br />
<br />
==Accessing the User Manual==<br />
When launching simmodeler, there is a blue question mark at the top right of the GUI. Click it and then click "launch manual" to open the user manual associated with the version of simmodeler you are using. This gives detailed descriptions of the various attributes and how they are defined to generate the desired mesh.<br />
<br />
<br />
==Volume Meshing==<br />
<br />
===3D Boundary Layers===<br />
One of the most important aspects of volume mesh development is generating proper 3D boundary layers. This process is well outlined [https://fluid.colorado.edu/tutorials/RajDemo.mp4 here] from around 8:30 to 16:00. Note that all mesh attributes are set up under the "Meshing" tab.<br />
<br />
===Mesh Refinement Zones===<br />
Mesh refinement zones are useful for increasing the grid density within certain volumes of your simulation domain. The linked ''Mesh Refinement Tutorial'' will briefly walk you through how these are implemented.<br />
<br />
==Surface Meshing==<br />
<br />
===2D and 1D Boundary Layers===<br />
<br />
To generate a proper surface mesh, it is important that both 2D and 1D boundary layers are implemented. Note that a 2D Boundary layer is defined on a surface and a 1D Boundary layer is defined on a line. The linked [https://fluid.colorado.edu/tutorials/MeshingWingInRoom_1D_2D_BLs.mp4 video] shows both 2D and 1D boundary layers being applied to an airfoil and the mesh that results from these applied attributes.<br />
<br />
===Mesh Size and Face Extrusions===<br />
<br />
Two more useful attributes when generating proper surface meshes are defining Mesh Sizes and Face Extrusions on your desired surfaces. Face Extrusions are useful when adding refinement over curved surfaces. This process is well covered in this [https://fluid.colorado.edu/tutorials/MeshingWingInRoom_MeshSize_FaceExt.mp4 video].<br />
<br />
==Saving Out the Mesh==<br />
Once you are satisfied with your mesh refinement, you are ready to generate and save out the mesh. In the meshing tab, you will want to click ''Generate Mesh''. The default settings will suffice for proper mesh generation. If your grid is large, this step can take some time. Once the grid is finished generating, you will want to save out this file as you will need it later.<br />
<br />
==Applying Boundary and Initial Conditions==<br />
A nice description of each of the common BCs used in both the Compressible and Incompressible builds of PHASTA is provided [https://fluid.colorado.edu/wiki/index.php/SimModeler here]. The [https://fluid.colorado.edu/tutorials/BC_tutorial.mp4 video] linked in this section shows how the BCs are applied for an incompressible case. Note that the case needs to be called ''geom'' as is done in the tutorial video. Once the BCs are successfully implemented, you have saved out a model file with these BCs(.smd), and have generated your grid (.sms file), your are ready to prepare the grid for Chef. To get started on this step, click [https://fluid.colorado.edu/wiki/index.php/Prepping_the_Grid_for_Chef here]</div>Mabl7046https://fluid.colorado.edu/wiki/index.php?title=Getting_Started_with_Simmodeler&diff=1067Getting Started with Simmodeler2020-09-10T18:37:04Z<p>Mabl7046: /* Applying Boundary and Initial Conditions */</p>
<hr />
<div>==Launching the Software ==<br />
Once your environment is properly set, as shown in the [https://fluid.colorado.edu/tutorials/Convert2Sim_Tutorial.mp4 convert step video], run: <code> vglrun /projects/tools/SimmetrixTest/SimModeler7.0-190626/simmodeler</code> in your terminal to launch simmodeler. Note that 7.0-190626 specifies the version of simmodeler you are launching.<br />
<br />
==Accessing the User Manual==<br />
When launching simmodeler, there is a blue question mark at the top right of the GUI. Click it and then click "launch manual" to open the user manual associated with the version of simmodeler you are using. This gives detailed descriptions of the various attributes and how they are defined to generate the desired mesh.<br />
<br />
==Applying Mesh Attributes==<br />
<br />
===Volume Meshing===<br />
<br />
====3D Boundary Layers====<br />
One of the most important aspects of volume mesh development is generating proper 3D boundary layers. This process is well outlined [https://fluid.colorado.edu/tutorials/RajDemo.mp4 here] from around 8:30 to 16:00. Note that all mesh attributes are set up under the "Meshing" tab.<br />
<br />
====Mesh Refinement Zones====<br />
Mesh refinement zones are useful for increasing the grid density within certain volumes of your simulation domain. The linked ''Mesh Refinement Tutorial'' will briefly walk you through how these are implemented.<br />
<br />
===Surface Meshing===<br />
<br />
====2D and 1D Boundary Layers====<br />
<br />
To generate a proper surface mesh, it is important that both 2D and 1D boundary layers are implemented. Note that a 2D Boundary layer is defined on a surface and a 1D Boundary layer is defined on a line. The linked [https://fluid.colorado.edu/tutorials/MeshingWingInRoom_1D_2D_BLs.mp4 video] shows both 2D and 1D boundary layers being applied to an airfoil and the mesh that results from these applied attributes.<br />
<br />
====Mesh Size and Face Extrusions====<br />
<br />
Two more useful attributes when generating proper surface meshes are defining Mesh Sizes and Face Extrusions on your desired surfaces. Face Extrusions are useful when adding refinement over curved surfaces. This process is well covered in this [https://fluid.colorado.edu/tutorials/MeshingWingInRoom_MeshSize_FaceExt.mp4 video].<br />
<br />
==Saving Out the Mesh==<br />
Once you are satisfied with your mesh refinement, you are ready to generate and save out the mesh. In the meshing tab, you will want to click ''Generate Mesh''. The default settings will suffice for proper mesh generation. If your grid is large, this step can take some time. Once the grid is finished generating, you will want to save out this file as you will need it later.<br />
<br />
==Applying Boundary and Initial Conditions==<br />
A nice description of each of the common BCs used in both the Compressible and Incompressible builds of PHASTA is provided [https://fluid.colorado.edu/wiki/index.php/SimModeler here]. The [https://fluid.colorado.edu/tutorials/BC_tutorial.mp4 video] linked in this section shows how the BCs are applied for an incompressible case. Note that the case needs to be called ''geom'' as is done in the tutorial video. Once the BCs are successfully implemented, you have saved out a model file with these BCs(.smd), and have generated your grid (.sms file), your are ready to prepare the grid for Chef. To get started on this step, click [https://fluid.colorado.edu/wiki/index.php/Prepping_the_Grid_for_Chef here]</div>Mabl7046