PHASTA Wiki - User contributions [en]

The Julia Phasta Branch

2015-05-24T05:16:15Z

Nmati: Created page with "== Overview == The goal of this project is to port PHASTA from a combination of C, C++, and Fortran over to Julia. == Status == The project is presently in the initial phase of ..."

== Overview ==
The goal of this project is to port PHASTA from a combination of C, C++, and Fortran over to Julia.

== Status ==
The project is presently in the initial phase of planning and proof of concept. Ben Matthews has reworked his F90 version of PHASTA to build as a shared library with just enough Julia to replace main.cc and at least partial bindings for PhastaIO.

The source is presently available on the Viz nodes in

/users/matthb2/phasta-jl/

Once the project has been formalized more, it will be pushed to GitHub.

== Compiling ==

To build with the GNU toolchain:

cmake CC=gcc CXX=g++ FC=gfortran -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS="-fPIC" -DCMAKE_CXX_FLAGS="-fPIC" -DCMAKE_Fortran_FLAGS="-fPIC" ../phasta

Depending on the hardware you're running on, using -fpic instead of -fPIC may result in smaller and faster code... or it may result in linker errors (http://stackoverflow.com/questions/3544035/what-is-the-difference-between-fpic-and-fpic-gcc-parameters).

== Bugs and Things to do ==

- Finish IO bindings to output files.

- Generate test environment.

PHASTA/Wish List

2014-06-09T22:06:34Z

Nmati: /* Phasta */

This page is intended to be a log of useful features to add to various tools such as Phasta and NSpre. Odds are that no one will ever actually implement anything listed on this page, but if you somehow find yourself with a little extra time, it's always here.

== Phasta ==

*Standardize the Sync IO library to work as is across Phasta and Paraview.
*Get rid of the need to know a priori how many fields will need to be written when using Sync IO
*Write interface to allow Phasta to read and write both Sync IO and Posix
*Fix bug in Sync IO to allow serial IO.
*Modify common.h (and the rest of the code) to allow implicit none.
*Convert all Fortran to a separate language (such as C or Julia)
*Cross Platform (Hey, I can dream)

== NSpre ==

*Error checking to make sure that the size of the mesh contained in geom.sms is equal to the size of the mesh associated with restart.*.0.
*Ability to interpolate directly from a partitioned mesh.

PHASTA/Wish List

2014-06-09T05:35:39Z

Nmati: /* Phasta */

This page is intended to be a log of useful features to add to various tools such as Phasta and NSpre. Odds are that no one will ever actually implement anything listed on this page, but if you somehow find yourself with a little extra time, it's always here.

== Phasta ==

*Standardize the Sync IO library to work as is across Phasta and Paraview.
*Get rid of the need to know a priori how many fields will need to be written when using Sync IO
*Write interface to allow Phasta to read and write both Sync IO and Posix
*Modify common.h (and the rest of the code) to allow implicit none.
*Convert all Fortran to a separate language (such as C or Julia)
*Cross Platform (Hey, I can dream)

== NSpre ==

*Error checking to make sure that the size of the mesh contained in geom.sms is equal to the size of the mesh associated with restart.*.0.
*Ability to interpolate directly from a partitioned mesh.

PHASTA/Wish List

2014-06-05T21:12:31Z

Nmati: /* Phasta */

This page is intended to be a log of useful features to add to various tools such as Phasta and NSpre. Odds are that no one will ever actually implement anything listed on this page, but if you somehow find yourself with a little extra time, it's always here.

== Phasta ==
*Convert all Fortran to a separate language (such as C or Julia)
*Cross Platform (Hey, I can dream)
*Standardize the Sync IO library to work as is across Phasta and Paraview.
*Get rid of the need to know a priori how many fields will need to be written when using Sync IO
*Write interface to allow Phasta to read and write both Sync IO and Posix

== NSpre ==

*Error checking to make sure that the size of the mesh contained in geom.sms is equal to the size of the mesh associated with restart.*.0.
*Ability to interpolate directly from a partitioned mesh.

PHASTA/Wish List

2014-06-05T21:11:48Z

Nmati: /* Phasta */

This page is intended to be a log of useful features to add to various tools such as Phasta and NSpre. Odds are that no one will ever actually implement anything listed on this page, but if you somehow find yourself with a little extra time, it's always here.

== Phasta ==
*Convert all Fortran to a separate language (such as C or Julia)
*Cross Platform (Hey, I can dream)
*Standardize the Sync IO library to work as is across Phasta and Paraview.
*Get rid of the need to know a priori how many fields will need to be written when using Sync IO
*Write interface to use allow Phasta to read and write both Sync IO and Posix

== NSpre ==

*Error checking to make sure that the size of the mesh contained in geom.sms is equal to the size of the mesh associated with restart.*.0.
*Ability to interpolate directly from a partitioned mesh.

BLMesher

2014-05-15T00:03:01Z

Nmati: Added a pitfalls section

[[Category:Software]]
How to create the mesh '''using script'''

-----------------------------------------------
== Start ==
* To begin, we need a geometry model. It can be created using commercial softwares such as Solid Work and saved as *.x_t
* You need the BLMesher code which is available on svn:
svn co https://redmine.scorec.rpi.edu/svn/phasta/BLMesher
* If you have read only access to phasta project on redmine, then use:
svn co https://redmine.scorec.rpi.edu/anonsvn/phasta/BLMesher

==Files needed ==
Create a folder and copy all these files into it.
* Geometry model file (geom.xmt_txt or geom.x_t)
* Mesh generation attribution file (Attributes.inp)
* exe file (Run.sh)

File Attributes.inp is the script that defines the mesh generation characteristics for different entities of the model.

Run.sh is an exe file including commands as below:
PATH=/users/chitak/develop/Meshing/BLMesher
$PATH/bin/x86_64_linux/BLMesher-0 geom.xmt_txt geom.sms 1 0.1 BLAttr.inp
It defines the proper path for mesh generator. It also defines that geom.xmt_txt is the model file and the mesh must be created using the attributes defined in Attributes.inp and the mesh data must be written into geom.sms

In the second line of the Run.sh file, the value before attributes.inp (in this case, 0.1) is the size of the boxes that are created before the the final mesh generation. (In fact, BLMesher tries to divide the whole domain into small boxes and then divide these boxes to create the mesh).
Lets call the characteristic size of the domain, d, and the size of the boxes E.

You must choose E as below and use it in Run.sh:
<math> E=\frac{d}{2^{(m+1)}} </math> or <math> E=\frac{d}{2^m} </math>
m is an integer.

Other flags like optimization and smoothing can also be given in this line. Use -h option with the executable to view the complete list of the options and their meaning. Note that the order of these flags is extremely important. Other than the executable, there are 11 other command line inputs which can be given. These can be given in Run.sh with the executable.

== Edit the script ==
* The first line is the version number (for future use). For eg.: version 1
* Use "#" to comment a line or disable it.
* To create attributes for each model entity, two lines in the following format are being used.
<entity dimension> <entity tag> <size type> <attribute type> <extra>
<value or expression for mesh size on this entity>
* Note that a blank line between these two lines is not allowed.

.

== Create the mesh ==
* After preparing the script, execute the file Run.sh. It creates the mesh and write the data to geom.sms (as you defined in Run.sh).
* Note that after executing the Run.sh, you must use command "top" to check the memory usage. If you find out that memory usage is huge and is increasing, you must kill the job before the machine crashes

.

== Visualize the mesh ==
To see the generated mesh, you can use simapps:
/usr/local/simapps/<simapps version>/simapps ThreeDViewer &

.

== Define the mesh characteristics in attribute file ==
The parameters in the first line, respectively are:
- Entity dimension: 2 for 2-D cases and 3 for 3-D cases
- Entity tag: You can find the entity tag using simapps
- Size type on entity: 1 for absolute mesh size and 2 for relative mesh size
- Attribute type on entity:
0 just imposes the size on entity. '''<extra> field''' is NULL
1 for entity with boundary layers. '''<extra> field''' is explained below.
2 for periodic entity: In this case, '''<extra> field''' is followed with slave entity tag
3 for refinement source. Specify entity dimension as -1 in this case. '''<extra> field''' is explained below.

'''<extra> field:'''

For Boundary layer:
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==0, layers with fixed heigths), (c) firstLayerHeight, (d) totalHeight, (e) nLayers, (f) blMixed, (g) blBlends, (h) blPropagate and (i) edgeBLFaceTag (only if 2D BL on edge)
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==2, to vary height linearly between two end/bounding entities), (c) varyDirection, (d) endEntTag1 , (e) firstLayerHeight1, (f) totalHeight1, (g) endEntTag2, (h) firstLayerHeight2, (i) totalHeight2, (j) nLayers, (k) blMixed, (l) blBlends, (m) blPropagate and (n) edgeBLFaceTag (only if 2D BL on edge)

For refinement:
is followed with (a) ref. source type (1-cube, 2-cylinder etc.), (b) source info. as Simmetrix APIs (like radius, length, center and normal in case of cylinder, and center, wdir, hdir and ddir in case of cube/parallelepiped)

* Note if entity dimension is -1, (in case of refinement) do not specify the entity tag and size type.

.

== Example 1: Uniform mesh ==
Simple uniform mesh on region with tag 205
3 205 1 0
2e-4

The above lines can be divided as below:
(3) (205) (1) (0)
(2e-4)

(3): Entity dimension. It's a 3-D region.
(205): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL
(2e-4): Mesh size (This is in the second line)
Note: The second line (Mesh size) can be a value or an expression such as:
0.0125+0.1*(1.0-exp(-3.0*sqrt(($x-0.0)^2+($y-0.0)^2+($z-0.5)^2)))

.

== Example 2: Refinement in a cylindrical region ==
-1 3 1 1.5e-3 1 2 0.3 0 0 0 1
2.5e-4

The above lines can be divided as below:
(-1) (3) (1) (1.5e-3) (1) (2 0.3 0) (0 0 1)
(2.5e-4)

(-1): Entity dimension, for refinement cases
(3): Attribute type. in this case, refinement.
(1): For refinement in a cylindrical region
(1.5e-3 ): Radius
(1): Length of the Cylinder (Half)
(2 0.3 0): The center of the circle
(0 0 1): Axis
(2.5e-4): mesh size (This is in the second line)

.

== Example 3: Refinement in a box region ==
-1 3 2 6e-3 5e-3 0.0 1.5e-3 0.0 0.0 0.0 5.0e-4 0.0 0.0 0.0 5.0e-4
2.5e-4

The above lines can be divided as below:
(-1) (3) (2) (6e-3 5e-3 0.0) (1.5e-3 0.0 0.0) (0.0 5.0e-4 0.0) (0.0 0.0 5.0e-4)
(2.5e-4)

(-1): Entity dimension. -1 only for refinement cases.
(3): Attribute type. in this case, refinement.
(2): For refinement in a box region
(6e-3 5e-3 0.0): The center of the box
(1.5e-3 0.0 0.0): x-Half length
(0.0 5.0e-4 0.0): y-Half length
(0.0 0.0 5.0e-4): z-Half length
(2.5e-4): mesh size (This is in the second line)

.

== Example 4: Refine the mesh along 3 lines on face with tag 5 ==
3 5 1 0
(0.5e-03) +0.1*(1.0-exp(-2.0*sqrt(($x-1.9)^2+($y-0.36)^2)))*(1.0-exp(-10.0*sqrt(($x-1.77)^2+($y-0.42)^2)))*(1.0-exp(-6.0*sqrt(($x-1.8)^2+($y-0.43)^2)))
The first line can be divided as below:
(3) (5) (1) (0)

(3): Entity dimension, 3-D
(5): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL

This is an example of an expression that will make the mesh fine in three lines. e.g., x=1.9 y=0.36 on model entity number 5.

.

== Example 5: Periodic mesh ==

If periodic BC is used at two faces, the mesh must be identical in both of them.

In this case, faces 1 and 81 are periodic

2 1 1 2 81
2.1e-4

The above lines can be divided as below:
(2) (1) (1) (2) (81)
(2.1e-4)

(2): Entity dimension, 2-D. it's a face.
(1): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(2): Attribute type on entity. 2 for periodic entity. <extra> field is followed with a slave entity tag
(81): Slave entity tag
(2.1e-4):mesh size (This is in the second line)

.

== Example 6: Boundary layer mesh , constant thickness ==
On face with tag 173
2 173 1 1 0 0 0.4e-4 3.e-4 5 0 0 0
1.61e-4

The above lines can be divided as below:
(2) (173) (1) (1) (0) (0) (0.4e-4) (3.e-4) (5) (0) (0) (0)
(1.61e-4)

(2): Entity dimension, 2-D. it's a face.
(173): Face tag
(1): Size type on entity. 1 for absolute mesh size, 2 for relative
(1): Attribute type on entity. A value of 1 selects the boundary layer meshing option.
(0): Boundary layer orientation (FaceSide/useDir)
(0): NumEndEnts. 0 for layers with fixed heights
(0.4e-4): First layer height
(3.e-4): Total height of boundary layer
(5): Number of layers
(0): Boundary layer Mixed topology
- 0 for tetrahedra only
- 1 for a wedge / hex dominant BL
(0): Boundary layer blending.
- 0 for no BL blending
- 1 to enable BL blending
(0): Anisotropic Boundary Layer size gradation / propagation
- 0 disable size gradation
- 1 enable size gradation
(1.61e-4): mesh size on the surface (This value is in the second line)

If you are specifying a 2D BL on a model edge, then at the end of the line, you have to give a target face tag, to which face you want that BL attribute applied.

For more details, see the the appropriate documentation such as /usr/local/simmetrix/simmodsuite/8.0-121129/html/MeshSimAdv/group__BLAttrib.html#BLParamChart for attribute type and /usr/local/simmetrix/simmodsuite/8.0-121129/html/MeshSimAdv/group__BLAttrib.html#BLAnisoOption for Anisotropic Size Gradation.

.

== Example 7: Boundary layer mesh, ramped thickness ==
On face with tag 27
2 27 1 1 0 2 0 22 1.e-3 2.e-2 20 2.e-3 10.e-2 5 1 0 0
0.1

The above lines can be divided as below:
(2) (27) (1) (1) (0) (2) (0) (22) (1.e-3) (2.e-2) (20) (2.e-3) (10.e-2) (5) (1) (0) (0)
(0.1)

(2): Entity dimension, 2-D. it's a face.
(27): Face tag
(1): Size type on entity. 1 for absolute mesh size
(1): Attribute type on entity. 1 for entity with boundary layers.
(0): Boundary layer orientation (FaceSide/useDir)
(2): For Layers with linearly varying height (NumEndEnts)
(0): Direction of variation (pos. x-dir.)
(22): Edge tag at pos. 1
(1.e-3): First layer height at pos. 1
(2.e-2): Total height of all layers at pos. 1
(20): Edge tag at pos. 2
(2.e-3): First layer height at pos. 2
(10.e-2): Total height of all layers at pos. 2
(5): Number of layers
(1): Boundary layer Mixed topology (1 for triangles and quads)
(0): Boundary layer blending. 0 for no BL blending
(0): Boundary Layer propagation. 0 for no propogation
(0.1): mesh size on the surface (This value is in the second line)

== Example 8: Global BL attributes ==

These can be set globally as follows. Only 1 attribute can be set at a time.

-1 7 attribute_type
value

The above lines can be divided as below:
(-1) (7) (attribute_type)
(value)

(-1): Entity dimension. -1 for setting global attributes
(7): for setting BL global attribute
(attribute_type): type of BL attribute you want to set. It can be one of the following:
1: smoothing distance
2: layer edge aspect ratio
3: exposed aspect ratio (opposite of aspect ratio, look at the documentation MS_minExposedAspectRatio for more info)
10: Global gradation rate (not for BLs)
(value): value for the above attribute

== Example 9: Refinement Along an Edge ==

For uniform refinement along an edge with tag 333
1 333 1 0
2e-4

The above lines can be divided as below:
(1) (333) (1) (0)
(2e-4)

(1): Entity dimension. It's a 1-D line.
(333): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity.
(2e-4): Mesh size (This is in the second line)

== Pitfalls ==

-Some versions of BLMesher will die if tabs are present in the attribute file. The error message is quite unhelpful and will look something like:
ERROR : attribute info. [attribute number : 9] - NOT compatible [model entity of dim.:0 NOT found with tag:1]

NGC

2014-03-30T07:39:32Z

Nmati:

[[Category:Projects]]
The NGC project is a continuation of at least one other project sponsored by Northrup Grumman Corporation studying active flow control in ducts with various geometries that tend to induce large adverse pressure gradients and massive separation in the flow. The present project concerns high subsonic flow in a square channel which is subjected to a aggressive diffuser. Flow control is performed with unsteady tangential blowing near the upstream side of the diffuser. The previous project was an aggressive S-duct which used similar tangential blowing to keep the flow attached.

The CFD at CU has been conducted in conjunction with experiments at RPI for several years. In that time, the primary student working on the CFD has changed from Yi Chen to Kyle Woolwine to Nicholas Mati. It is the intent of this page to provide some continuity for future transitions with brief documentation of present work. It is also hoped that maintaining this page will increase communication with Prof. Jansen, and help keep track of simulation cases as they proliferate.

-----------------------------------------------

=S-Duct=
This page was created after Yi stopped working on the project. For more information, read Yi Chen's thesis.

=Diffuser=

==Series 10==
===Series 10.1===
===Series 10.2===
===Series 10.3===
The only difference between series 10.2 and 10.3 is the splitting of a surface in the blower near the lip into three separate surfaces. This allowed the mesh height on the lower blower wall to be manually cut down near the lip which fixed an issue from 10.2 where the mesher was not trimming the boundary layer correctly in a refinement box for some reason.

-Interpolating from the 10.1 solution to the M3 mesh, high z-velocity oscillations clipping at +-250 m/s continued in the blower. This solution was abandoned.

-Interpolating from the 11.2 solution to the M3 mesh, the blower started off with nearly zero velocity. Some inflow was initially observed in the blower, but no substantial z-oscillations were observed. However, backflow was present in the 11.2 solution which resulted in temperature clipping high at the bottom of the diffuser with at most 2 orders of magnitude of convergence in the nonlinear residual. Dropping the upper limit from 400 K to 340 K to 320 K resulted in only minor benefit and the solution was abandoned.

-Starting from near zero velocity initial conditions on the M3 mesh broke phasta. There was a version compatibility issue with the smd which resulted in all flow fields being zero. While debugging, the geometry was remeshed.

-Starting from near zero velocity initial conditions on the M4 mesh resulted in similar flow separation and temperature clipping. Elevated viscosity of 10 nu, 100 nu, and 1000 nu was tried in the diffuser, but this resulted in only minor improvement.

-M5 actually recycled the mesh from M4. The main difference was with boundary conditions on the diffuser slip walls. The turbulence wall designation was removed and scalar 1 = 0 was changed to scalar 1 flux = 0. Slip boundary conditions were finally observed, although back flow was still present at the outlet which caused the solution to diverge.

-M6 again recycled the mesh from M4, but swapped the homogeneous natural temperature and scalar BCs at the outlet for essential BCs. This created a large gradient on elements touching the outlet, but the velocity was generally high enough to prevent substantial changes further upstream.

It was also observed that the wall temperature was still being set to 317 K, despite requesting a zero heat flux BC in the GUI. A quick grep through the code yielded a hack in gendat.f that Yi and introduced which set the temperature, all three components of velocity, and scalar 1 whenever a wall was designated as a turbulence wall. I [Nicholas] commented most of the offending code, but kept the scalar 1 = 0 BC. At least for the SA turbulence model, scalar 1 = 0 and turbulence wall should always accompany one another, although this might still cause issues if someone tries to use the k-w model.

Roughly 2000 time steps of RANS were run with the new boundary conditions. Small amounts of backflow were present, but the solution generally appeared to be fine in the diffuser. High z-velocity oscillations were again observed in the blower and were likely responsible for the divergence of the solution. Another 1000 steps were run with DDES, but again, the solution appeared to diverge near the blower, even when the blower was turned off.

-Under the hypothesis that the large gradient in mesh size between the bottom of the blower and the fillet was responsible for introducing the high z-velocities, the blower was refined by a factor of between 2 and 4 to produce the M7 case.

==Series 12==

The Series 12 case is a hybrid between the series 8 and 10 cases; the same blower geometry is derived from series 10 but the diffuser is removed as in series 8.

===Series 12.0===

NGC

2014-03-30T07:36:14Z

Nmati: /* Series 10.3 */

NGC

2014-03-29T08:47:19Z

Nmati: /* Series 10.3 */

NGC

2014-03-24T06:31:32Z

Nmati:

NGC

2014-03-24T06:28:56Z

Nmati: Created page with "Category:Projects =The Northrop Grumman Diffuser Project= The NGC project is a continuation of at least one other project sponsored by Northrup Grumman Corporation studying ..."

[[Category:Projects]]
=The Northrop Grumman Diffuser Project=

The NGC project is a continuation of at least one other project sponsored by Northrup Grumman Corporation studying active flow control in ducts with various geometries that tend to induce large adverse pressure gradients and massive separation in the flow. The present project concerns high subsonic flow in a square channel which is subjected to a aggressive diffuser. Flow control is performed with unsteady tangential blowing near the upstream side of the diffuser. The previous project was an aggressive S-duct which used similar tangential blowing to keep the flow attached.

The CFD at CU has been conducted in conjunction with experiments at RPI for several years. In that time, the primary student working on the CFD has changed from Yi Chen to Kyle Woolwine to Nicholas Mati. It is the intent of this page to provide some continuity for future transitions with brief documentation of present work. It is also hoped that maintaining this page will increase communication with Prof. Jansen, and help keep track of simulation cases as they proliferate.

-----------------------------------------------

=S-Duct=
This page was created after Yi stopped working on the project. For more information, read Yi Chen's thesis.

=Diffuser=

==Series 10==
===Series 10.1===
===Series 10.2===
===Series 10.3===
The only difference between series 10.2 and 10.3 is the splitting of a surface in the blower near the lip into three separate surfaces. This allowed the mesh height on the lower blower wall to be manually cut down near the lip. This fixed an issue from 10.2 where the mesher was not trimming the boundary layer correctly in a refinement box for some reason.

-Interpolating from the 10.1 solution to the M3 mesh, high z-velocity oscillations clipping at +-250 m/s continued in the blower. This solution was abandoned.

-Interpolating from the 11.2 solution to the M3 mesh, the blower started off with nearly zero velocity. Some inflow was initially observed in the blower, but no substantial z-oscillations were observed. However, backflow was present in the 11.2 solution which resulted in temperature clipping high at the bottom of the diffuser with at most 2 orders of magnitude of convergence in the nonlinear residual. Dropping the upper limit from 400 K to 340 K to 320 K resulted in only minor benefit and the solution was abandoned.

-Starting from near zero velocity initial conditions on the M3 mesh broke phasta. There was a version compatibility issue with the smd which resulted in all flow fields being zero. While debugging, the geometry was remeshed.

-Starting from near zero velocity initial conditions on the M4 mesh resulted in similar flow separation and temperature clipping. Elevated viscosity of 10 nu, 100 nu, and 1000 nu was tried in the diffuser, but this resulted in only minor improvement.

BLMesher

2014-03-18T04:41:49Z

Nmati: /* Example 6: Boundary layer mesh , constant thickness */ Corrected error in attribute type introduced in last edit.

BLMesher

2014-03-17T23:20:25Z

Nmati: /* Example 8: Global BL attributes */ Added global gradation rate

[[Category:Software]]
How to create the mesh '''using script'''

-----------------------------------------------
== Start ==
* To begin, we need a geometry model. It can be created using commercial softwares such as Solid Work and saved as *.x_t
* You need the BLMesher code which is available on svn:
svn co https://redmine.scorec.rpi.edu/svn/phasta/BLMesher
* If you have read only access to phasta project on redmine, then use:
svn co https://redmine.scorec.rpi.edu/anonsvn/phasta/BLMesher

==Files needed ==
Create a folder and copy all these files into it.
* Geometry model file (geom.xmt_txt or geom.x_t)
* Mesh generation attribution file (Attributes.inp)
* exe file (Run.sh)

File Attributes.inp is the script that defines the mesh generation characteristics for different entities of the model.

Run.sh is an exe file including commands as below:
PATH=/users/chitak/develop/Meshing/BLMesher
$PATH/bin/x86_64_linux/BLMesher-0 geom.xmt_txt geom.sms 1 0.1 BLAttr.inp
It defines the proper path for mesh generator. It also defines that geom.xmt_txt is the model file and the mesh must be created using the attributes defined in Attributes.inp and the mesh data must be written into geom.sms

In the second line of the Run.sh file, the value before attributes.inp (in this case, 0.1) is the size of the boxes that are created before the the final mesh generation. (In fact, BLMesher tries to divide the whole domain into small boxes and then divide these boxes to create the mesh).
Lets call the characteristic size of the domain, d, and the size of the boxes E.

You must choose E as below and use it in Run.sh:
<math> E=\frac{d}{2^{(m+1)}} </math> or <math> E=\frac{d}{2^m} </math>
m is an integer.

Other flags like optimization and smoothing can also be given in this line. Use -h option with the executable to view the complete list of the options and their meaning. Note that the order of these flags is extremely important. Other than the executable, there are 11 other command line inputs which can be given. These can be given in Run.sh with the executable.

== Edit the script ==
* The first line is the version number (for future use). For eg.: version 1
* Use "#" to comment a line or disable it.
* To create attributes for each model entity, two lines in the following format are being used.
<entity dimension> <entity tag> <size type> <attribute type> <extra>
<value or expression for mesh size on this entity>
* Note that a blank line between these two lines is not allowed.

.

== Create the mesh ==
* After preparing the script, execute the file Run.sh. It creates the mesh and write the data to geom.sms (as you defined in Run.sh).
* Note that after executing the Run.sh, you must use command "top" to check the memory usage. If you find out that memory usage is huge and is increasing, you must kill the job before the machine crashes

.

== Visualize the mesh ==
To see the generated mesh, you can use simapps:
/usr/local/simapps/<simapps version>/simapps ThreeDViewer &

.

== Define the mesh characteristics in attribute file ==
The parameters in the first line, respectively are:
- Entity dimension: 2 for 2-D cases and 3 for 3-D cases
- Entity tag: You can find the entity tag using simapps
- Size type on entity: 1 for absolute mesh size and 2 for relative mesh size
- Attribute type on entity:
0 just imposes the size on entity. '''<extra> field''' is NULL
1 for entity with boundary layers. '''<extra> field''' is explained below.
2 for periodic entity: In this case, '''<extra> field''' is followed with slave entity tag
3 for refinement source. Specify entity dimension as -1 in this case. '''<extra> field''' is explained below.

'''<extra> field:'''

For Boundary layer:
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==0, layers with fixed heigths), (c) firstLayerHeight, (d) totalHeight, (e) nLayers, (f) blMixed, (g) blBlends, (h) blPropagate and (i) edgeBLFaceTag (only if 2D BL on edge)
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==2, to vary height linearly between two end/bounding entities), (c) varyDirection, (d) endEntTag1 , (e) firstLayerHeight1, (f) totalHeight1, (g) endEntTag2, (h) firstLayerHeight2, (i) totalHeight2, (j) nLayers, (k) blMixed, (l) blBlends, (m) blPropagate and (n) edgeBLFaceTag (only if 2D BL on edge)

For refinement:
is followed with (a) ref. source type (1-cube, 2-cylinder etc.), (b) source info. as Simmetrix APIs (like radius, length, center and normal in case of cylinder, and center, wdir, hdir and ddir in case of cube/parallelepiped)

* Note if entity dimension is -1, (in case of refinement) do not specify the entity tag and size type.

.

== Example 1: Uniform mesh ==
Simple uniform mesh on region with tag 205
3 205 1 0
2e-4

The above lines can be divided as below:
(3) (205) (1) (0)
(2e-4)

(3): Entity dimension. It's a 3-D region.
(205): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL
(2e-4): Mesh size (This is in the second line)
Note: The second line (Mesh size) can be a value or an expression such as:
0.0125+0.1*(1.0-exp(-3.0*sqrt(($x-0.0)^2+($y-0.0)^2+($z-0.5)^2)))

.

== Example 2: Refinement in a cylindrical region ==
-1 3 1 1.5e-3 1 2 0.3 0 0 0 1
2.5e-4

The above lines can be divided as below:
(-1) (3) (1) (1.5e-3) (1) (2 0.3 0) (0 0 1)
(2.5e-4)

(-1): Entity dimension, for refinement cases
(3): Attribute type. in this case, refinement.
(1): For refinement in a cylindrical region
(1.5e-3 ): Radius
(1): Length of the Cylinder (Half)
(2 0.3 0): The center of the circle
(0 0 1): Axis
(2.5e-4): mesh size (This is in the second line)

.

== Example 3: Refinement in a box region ==
-1 3 2 6e-3 5e-3 0.0 1.5e-3 0.0 0.0 0.0 5.0e-4 0.0 0.0 0.0 5.0e-4
2.5e-4

The above lines can be divided as below:
(-1) (3) (2) (6e-3 5e-3 0.0) (1.5e-3 0.0 0.0) (0.0 5.0e-4 0.0) (0.0 0.0 5.0e-4)
(2.5e-4)

(-1): Entity dimension. -1 only for refinement cases.
(3): Attribute type. in this case, refinement.
(2): For refinement in a box region
(6e-3 5e-3 0.0): The center of the box
(1.5e-3 0.0 0.0): x-Half length
(0.0 5.0e-4 0.0): y-Half length
(0.0 0.0 5.0e-4): z-Half length
(2.5e-4): mesh size (This is in the second line)

.

== Example 4: Refine the mesh along 3 lines on face with tag 5 ==
3 5 1 0
(0.5e-03) +0.1*(1.0-exp(-2.0*sqrt(($x-1.9)^2+($y-0.36)^2)))*(1.0-exp(-10.0*sqrt(($x-1.77)^2+($y-0.42)^2)))*(1.0-exp(-6.0*sqrt(($x-1.8)^2+($y-0.43)^2)))
The first line can be divided as below:
(3) (5) (1) (0)

(3): Entity dimension, 3-D
(5): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL

This is an example of an expression that will make the mesh fine in three lines. e.g., x=1.9 y=0.36 on model entity number 5.

.

== Example 5: Periodic mesh ==

If periodic BC is used at two faces, the mesh must be identical in both of them.

In this case, faces 1 and 81 are periodic

2 1 1 2 81
2.1e-4

The above lines can be divided as below:
(2) (1) (1) (2) (81)
(2.1e-4)

(2): Entity dimension, 2-D. it's a face.
(1): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(2): Attribute type on entity. 2 for periodic entity. <extra> field is followed with a slave entity tag
(81): Slave entity tag
(2.1e-4):mesh size (This is in the second line)

.

== Example 6: Boundary layer mesh , constant thickness ==
On face with tag 173
2 173 1 1 0 0 0.4e-4 3.e-4 5 0 0 0
1.61e-4

The above lines can be divided as below:
(2) (173) (1) (1) (0) (0) (0.4e-4) (3.e-4) (5) (0) (0) (0)
(1.61e-4)

(2): Entity dimension, 2-D. it's a face.
(173): Face tag
(1): Size type on entity. 1 for absolute mesh size, 2 for relative
(1): Attribute type on entity. As of simmodsuite 8.0-121129, Simmetrix supports four options for the boundary layer gradation type.
- 1 for boundary layer with geometric growth.
- 2 for boundary layer with growth relative to the mesh size (1)
- 3 for user-specified thickness (not supported by BLMesher)
- 4 for for boundary layer with growth relative to mesh size (2) (not supported by BLMesher)
(0): Boundary layer orientation (FaceSide/useDir)
(0): NumEndEnts. 0 for layers with fixed heights
(0.4e-4): First layer height
(3.e-4): Total height of boundary layer
(5): Number of layers
(0): Boundary layer Mixed topology
- 0 for tetrahedra only
- 1 for a wedge / hex dominant BL
(0): Boundary layer blending.
- 0 for no BL blending
- 1 to enable BL blending
(0): Anisotropic Boundary Layer size gradation / propagation
- 0 disable size gradation
- 1 enable size gradation
(1.61e-4): mesh size on the surface (This value is in the second line)

If you are specifying a 2D BL on a model edge, then at the end of the line, you have to give a target face tag, to which face you want that BL attribute applied.

For more details, see the the appropriate documentation such as /usr/local/simmetrix/simmodsuite/8.0-121129/html/MeshSimAdv/group__BLAttrib.html#BLParamChart for attribute type and /usr/local/simmetrix/simmodsuite/8.0-121129/html/MeshSimAdv/group__BLAttrib.html#BLAnisoOption for Anisotropic Size Gradation.

.

== Example 7: Boundary layer mesh, ramped thickness ==
On face with tag 27
2 27 1 1 0 2 0 22 1.e-3 2.e-2 20 2.e-3 10.e-2 5 1 0 0
0.1

The above lines can be divided as below:
(2) (27) (1) (1) (0) (2) (0) (22) (1.e-3) (2.e-2) (20) (2.e-3) (10.e-2) (5) (1) (0) (0)
(0.1)

(2): Entity dimension, 2-D. it's a face.
(27): Face tag
(1): Size type on entity. 1 for absolute mesh size
(1): Attribute type on entity. 1 for entity with boundary layers.
(0): Boundary layer orientation (FaceSide/useDir)
(2): For Layers with linearly varying height (NumEndEnts)
(0): Direction of variation (pos. x-dir.)
(22): Edge tag at pos. 1
(1.e-3): First layer height at pos. 1
(2.e-2): Total height of all layers at pos. 1
(20): Edge tag at pos. 2
(2.e-3): First layer height at pos. 2
(10.e-2): Total height of all layers at pos. 2
(5): Number of layers
(1): Boundary layer Mixed topology (1 for triangles and quads)
(0): Boundary layer blending. 0 for no BL blending
(0): Boundary Layer propagation. 0 for no propogation
(0.1): mesh size on the surface (This value is in the second line)

== Example 8: Global BL attributes ==

These can be set globally as follows. Only 1 attribute can be set at a time.

-1 7 attribute_type
value

The above lines can be divided as below:
(-1) (7) (attribute_type)
(value)

(-1): Entity dimension. -1 for setting global attributes
(7): for setting BL global attribute
(attribute_type): type of BL attribute you want to set. It can be one of the following:
1: smoothing distance
2: layer edge aspect ratio
3: exposed aspect ratio (opposite of aspect ratio, look at the documentation MS_minExposedAspectRatio for more info)
10: Global gradation rate (not for BLs)
(value): value for the above attribute

== Example 9: Refinement Along an Edge ==

For uniform refinement along an edge with tag 333
1 333 1 0
2e-4

The above lines can be divided as below:
(1) (333) (1) (0)
(2e-4)

(1): Entity dimension. It's a 1-D line.
(333): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity.
(2e-4): Mesh size (This is in the second line)

BLMesher

2014-03-17T23:16:00Z

Nmati: /* Example 6: Boundary layer mesh , constant thickness */ Added other values that parameters can take on.

[[Category:Software]]
How to create the mesh '''using script'''

-----------------------------------------------
== Start ==
* To begin, we need a geometry model. It can be created using commercial softwares such as Solid Work and saved as *.x_t
* You need the BLMesher code which is available on svn:
svn co https://redmine.scorec.rpi.edu/svn/phasta/BLMesher
* If you have read only access to phasta project on redmine, then use:
svn co https://redmine.scorec.rpi.edu/anonsvn/phasta/BLMesher

==Files needed ==
Create a folder and copy all these files into it.
* Geometry model file (geom.xmt_txt or geom.x_t)
* Mesh generation attribution file (Attributes.inp)
* exe file (Run.sh)

File Attributes.inp is the script that defines the mesh generation characteristics for different entities of the model.

Run.sh is an exe file including commands as below:
PATH=/users/chitak/develop/Meshing/BLMesher
$PATH/bin/x86_64_linux/BLMesher-0 geom.xmt_txt geom.sms 1 0.1 BLAttr.inp
It defines the proper path for mesh generator. It also defines that geom.xmt_txt is the model file and the mesh must be created using the attributes defined in Attributes.inp and the mesh data must be written into geom.sms

In the second line of the Run.sh file, the value before attributes.inp (in this case, 0.1) is the size of the boxes that are created before the the final mesh generation. (In fact, BLMesher tries to divide the whole domain into small boxes and then divide these boxes to create the mesh).
Lets call the characteristic size of the domain, d, and the size of the boxes E.

You must choose E as below and use it in Run.sh:
<math> E=\frac{d}{2^{(m+1)}} </math> or <math> E=\frac{d}{2^m} </math>
m is an integer.

Other flags like optimization and smoothing can also be given in this line. Use -h option with the executable to view the complete list of the options and their meaning. Note that the order of these flags is extremely important. Other than the executable, there are 11 other command line inputs which can be given. These can be given in Run.sh with the executable.

== Edit the script ==
* The first line is the version number (for future use). For eg.: version 1
* Use "#" to comment a line or disable it.
* To create attributes for each model entity, two lines in the following format are being used.
<entity dimension> <entity tag> <size type> <attribute type> <extra>
<value or expression for mesh size on this entity>
* Note that a blank line between these two lines is not allowed.

.

== Create the mesh ==
* After preparing the script, execute the file Run.sh. It creates the mesh and write the data to geom.sms (as you defined in Run.sh).
* Note that after executing the Run.sh, you must use command "top" to check the memory usage. If you find out that memory usage is huge and is increasing, you must kill the job before the machine crashes

.

== Visualize the mesh ==
To see the generated mesh, you can use simapps:
/usr/local/simapps/<simapps version>/simapps ThreeDViewer &

.

== Define the mesh characteristics in attribute file ==
The parameters in the first line, respectively are:
- Entity dimension: 2 for 2-D cases and 3 for 3-D cases
- Entity tag: You can find the entity tag using simapps
- Size type on entity: 1 for absolute mesh size and 2 for relative mesh size
- Attribute type on entity:
0 just imposes the size on entity. '''<extra> field''' is NULL
1 for entity with boundary layers. '''<extra> field''' is explained below.
2 for periodic entity: In this case, '''<extra> field''' is followed with slave entity tag
3 for refinement source. Specify entity dimension as -1 in this case. '''<extra> field''' is explained below.

'''<extra> field:'''

For Boundary layer:
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==0, layers with fixed heigths), (c) firstLayerHeight, (d) totalHeight, (e) nLayers, (f) blMixed, (g) blBlends, (h) blPropagate and (i) edgeBLFaceTag (only if 2D BL on edge)
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==2, to vary height linearly between two end/bounding entities), (c) varyDirection, (d) endEntTag1 , (e) firstLayerHeight1, (f) totalHeight1, (g) endEntTag2, (h) firstLayerHeight2, (i) totalHeight2, (j) nLayers, (k) blMixed, (l) blBlends, (m) blPropagate and (n) edgeBLFaceTag (only if 2D BL on edge)

For refinement:
is followed with (a) ref. source type (1-cube, 2-cylinder etc.), (b) source info. as Simmetrix APIs (like radius, length, center and normal in case of cylinder, and center, wdir, hdir and ddir in case of cube/parallelepiped)

* Note if entity dimension is -1, (in case of refinement) do not specify the entity tag and size type.

.

== Example 1: Uniform mesh ==
Simple uniform mesh on region with tag 205
3 205 1 0
2e-4

The above lines can be divided as below:
(3) (205) (1) (0)
(2e-4)

(3): Entity dimension. It's a 3-D region.
(205): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL
(2e-4): Mesh size (This is in the second line)
Note: The second line (Mesh size) can be a value or an expression such as:
0.0125+0.1*(1.0-exp(-3.0*sqrt(($x-0.0)^2+($y-0.0)^2+($z-0.5)^2)))

.

== Example 2: Refinement in a cylindrical region ==
-1 3 1 1.5e-3 1 2 0.3 0 0 0 1
2.5e-4

The above lines can be divided as below:
(-1) (3) (1) (1.5e-3) (1) (2 0.3 0) (0 0 1)
(2.5e-4)

(-1): Entity dimension, for refinement cases
(3): Attribute type. in this case, refinement.
(1): For refinement in a cylindrical region
(1.5e-3 ): Radius
(1): Length of the Cylinder (Half)
(2 0.3 0): The center of the circle
(0 0 1): Axis
(2.5e-4): mesh size (This is in the second line)

.

== Example 3: Refinement in a box region ==
-1 3 2 6e-3 5e-3 0.0 1.5e-3 0.0 0.0 0.0 5.0e-4 0.0 0.0 0.0 5.0e-4
2.5e-4

The above lines can be divided as below:
(-1) (3) (2) (6e-3 5e-3 0.0) (1.5e-3 0.0 0.0) (0.0 5.0e-4 0.0) (0.0 0.0 5.0e-4)
(2.5e-4)

(-1): Entity dimension. -1 only for refinement cases.
(3): Attribute type. in this case, refinement.
(2): For refinement in a box region
(6e-3 5e-3 0.0): The center of the box
(1.5e-3 0.0 0.0): x-Half length
(0.0 5.0e-4 0.0): y-Half length
(0.0 0.0 5.0e-4): z-Half length
(2.5e-4): mesh size (This is in the second line)

.

== Example 4: Refine the mesh along 3 lines on face with tag 5 ==
3 5 1 0
(0.5e-03) +0.1*(1.0-exp(-2.0*sqrt(($x-1.9)^2+($y-0.36)^2)))*(1.0-exp(-10.0*sqrt(($x-1.77)^2+($y-0.42)^2)))*(1.0-exp(-6.0*sqrt(($x-1.8)^2+($y-0.43)^2)))
The first line can be divided as below:
(3) (5) (1) (0)

(3): Entity dimension, 3-D
(5): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL

This is an example of an expression that will make the mesh fine in three lines. e.g., x=1.9 y=0.36 on model entity number 5.

.

== Example 5: Periodic mesh ==

If periodic BC is used at two faces, the mesh must be identical in both of them.

In this case, faces 1 and 81 are periodic

2 1 1 2 81
2.1e-4

The above lines can be divided as below:
(2) (1) (1) (2) (81)
(2.1e-4)

(2): Entity dimension, 2-D. it's a face.
(1): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(2): Attribute type on entity. 2 for periodic entity. <extra> field is followed with a slave entity tag
(81): Slave entity tag
(2.1e-4):mesh size (This is in the second line)

.

== Example 6: Boundary layer mesh , constant thickness ==
On face with tag 173
2 173 1 1 0 0 0.4e-4 3.e-4 5 0 0 0
1.61e-4

The above lines can be divided as below:
(2) (173) (1) (1) (0) (0) (0.4e-4) (3.e-4) (5) (0) (0) (0)
(1.61e-4)

(2): Entity dimension, 2-D. it's a face.
(173): Face tag
(1): Size type on entity. 1 for absolute mesh size, 2 for relative
(1): Attribute type on entity. As of simmodsuite 8.0-121129, Simmetrix supports four options for the boundary layer gradation type.
- 1 for boundary layer with geometric growth.
- 2 for boundary layer with growth relative to the mesh size (1)
- 3 for user-specified thickness (not supported by BLMesher)
- 4 for for boundary layer with growth relative to mesh size (2) (not supported by BLMesher)
(0): Boundary layer orientation (FaceSide/useDir)
(0): NumEndEnts. 0 for layers with fixed heights
(0.4e-4): First layer height
(3.e-4): Total height of boundary layer
(5): Number of layers
(0): Boundary layer Mixed topology
- 0 for tetrahedra only
- 1 for a wedge / hex dominant BL
(0): Boundary layer blending.
- 0 for no BL blending
- 1 to enable BL blending
(0): Anisotropic Boundary Layer size gradation / propagation
- 0 disable size gradation
- 1 enable size gradation
(1.61e-4): mesh size on the surface (This value is in the second line)

If you are specifying a 2D BL on a model edge, then at the end of the line, you have to give a target face tag, to which face you want that BL attribute applied.

For more details, see the the appropriate documentation such as /usr/local/simmetrix/simmodsuite/8.0-121129/html/MeshSimAdv/group__BLAttrib.html#BLParamChart for attribute type and /usr/local/simmetrix/simmodsuite/8.0-121129/html/MeshSimAdv/group__BLAttrib.html#BLAnisoOption for Anisotropic Size Gradation.

.

== Example 7: Boundary layer mesh, ramped thickness ==
On face with tag 27
2 27 1 1 0 2 0 22 1.e-3 2.e-2 20 2.e-3 10.e-2 5 1 0 0
0.1

The above lines can be divided as below:
(2) (27) (1) (1) (0) (2) (0) (22) (1.e-3) (2.e-2) (20) (2.e-3) (10.e-2) (5) (1) (0) (0)
(0.1)

(2): Entity dimension, 2-D. it's a face.
(27): Face tag
(1): Size type on entity. 1 for absolute mesh size
(1): Attribute type on entity. 1 for entity with boundary layers.
(0): Boundary layer orientation (FaceSide/useDir)
(2): For Layers with linearly varying height (NumEndEnts)
(0): Direction of variation (pos. x-dir.)
(22): Edge tag at pos. 1
(1.e-3): First layer height at pos. 1
(2.e-2): Total height of all layers at pos. 1
(20): Edge tag at pos. 2
(2.e-3): First layer height at pos. 2
(10.e-2): Total height of all layers at pos. 2
(5): Number of layers
(1): Boundary layer Mixed topology (1 for triangles and quads)
(0): Boundary layer blending. 0 for no BL blending
(0): Boundary Layer propagation. 0 for no propogation
(0.1): mesh size on the surface (This value is in the second line)

== Example 8: Global BL attributes ==

These can be set globally as follows. Only 1 attribute can be set at a time.

-1 7 attribute_type
value

The above lines can be divided as below:
(-1) (7) (attribute_type)
(value)

(-1): Entity dimension. -1 for setting global attributes
(7): for setting BL global attribute
(attribute_type): type of BL attribute you want to set. It can be one of the following:
1: smoothing distance
2: layer edge aspect ratio
3: exposed aspect ratio (opposite of aspect ratio, look at the documentation MS_minExposedAspectRatio for more info)
(value): value for the above attribute

== Example 9: Refinement Along an Edge ==

For uniform refinement along an edge with tag 333
1 333 1 0
2e-4

The above lines can be divided as below:
(1) (333) (1) (0)
(2e-4)

(1): Entity dimension. It's a 1-D line.
(333): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity.
(2e-4): Mesh size (This is in the second line)

PHASTA/Probe points

2014-02-28T21:38:28Z

Nmati: /* Location in Phasta */ Removed some unfinished text

Phasta is capable of outputting solution field variables such as velocity, pressure, eddy viscosity, and temperature (if applicable) at specified locations in the fluid domain.

== Using Probe Points ==

To enable probe points, the file xyzts.dat and the folder varts/ must both be present in the n-procs_case directory that is being used by Phasta. The file xyzts.dat should contain a one line, space delineated header with the following numeric data (based of of the version in /users/mattb2/phasta-tocmake/...)

*number of probes
*frequency (i.e. the number of steps between sampling)
*tolerance (unused)
*iterate (unused)
*varcod (unused)

The lines following the header should contain x, y, z data specifying the location of the probe points. As an example, a valid xyzts.dat file for an incompressible run would look something like:

4 1 1.0e-6 1 5
0.2 -0.02 -0.01
0.2 -0.02 0.01
0.3 -0.02 -0.01
0.3 -0.02 0.01

...although a header of 4 1 1 1 1 should be equally as valid.

For multiple cases which use the same probe locations, it is often convenient to keep xyzts.dat in a lower level directory and soft link to it. That is, the setup process becomes
cd n-procs_case
mkdir varts
ln -s ../../xyzts.dat .

Note: in most versions of Phasta, the varts.*.sn files are created prior to the calculation of the first time step, but are actually written to ''after'' finishing the last time step. This means that if a run is interrupted (e.g. by not requesting enough time in a queue), no useful data will be generated.

== Location in Phasta ==

In the compressible version of Phasta, xyzts.dat is read exclusively in
phSolver/compressible/itrdrv.f.

Remote Desktop

2013-10-22T19:57:15Z

Nmati:

if you want to work with solidworks or NX remotely, you need to access the windows machines. For that open an ssh connection by:

ssh -L3389:phasta-pc:3389 username@jumpgate-phasta.colorado.edu

Then start remote desktop connection application/program from your laptop/PC. Put "localhost" in the Computer name and then press okay. Username is your username of the system, password is your main password (not VNC) and Domain is PHASTA.

Alternatively, it is possible to connect to a windows machines from within a VNC session. In a terminal, type

rdesktop -g [x resolution]x[y resolution] -x lan phasta-pc

where "x resolution" and "y resolution" correspond to the desired window size. For example, rdesktop -g 1600x980 -x lan phasta-pc will yield a 1600x980 window.

PHASTA/Compiling PHASTA With CMake

2013-10-11T22:35:56Z

Nmati: Added Clang to list.

There is an unofficial, but popular version of the PHASTA solver which uses a [[http://cmake.org CMake]] based build system. Generally, an out-of-source build is used, meaning that you have a separate directory for your executables and intermediate files.

Assuming you have your desired compiler and a current version of CMake (2.8.5 or newer) in your path, you must first create and change into an empty directory to store your build

mkdir build
cd build

You can then run cmake to create your makefile

If you're using the Intel compiler suite:

CC=icc CXX=icpc FC=ifort ccmake ../phasta

If you're using the PGI compiler suite:

CC=pgcc CXX=pgCC FC=pgfortran ccmake ../phasta

If you're using the GNU toolchain:

CC=gcc CXX=g++ FC=gfortran ccmake ../phasta

If you're using the Clang toolchain for C and C++:

CC=clang CXX=clang++ FC=gfortran ccmake ../phasta

This will open a "GUI" of sorts. You can use the arrow keys to navigate. Press enter to edit the highlighted field, and then enter again to save your change. Press the "c" key to compute the options. Press "g" to write out the makefile and quit. You'll need to press "c" several times, and fill in any desired options before you can generate your makefile.

You may want to set the "CMAKE_BUILD_TYPE" field to either "Release" or "Debug" to get an optimized build or a debugable build respectively.

Once you've completed this process, you can simply run "make" to build the code. The executable will be in the "bin" sub-directory of your build directory.
make

== Tips ==

on the viz nodes, run "soft add +cmake" to get an appropriate version of CMake.

on Janus, run "module load cmake" to get an appropriate version of CMake

If you run into trouble, it may be useful to see how the compiler is being invoked. You can do this by running:

make VERBOSE=1

(after having already run cmake)

To add additional compiler flags, use the CMAKE_C_FLAGS, CMAKE_CXX_FLAGS and CMAKE_Fortran_FLAGS fields when you configure

The build options are in a (somewhat) human readable format in a file called "CMakeCache.txt" in the root of your build directory - this can be very useful if you need to figure out which options were used for a particular build.

If you add a new file, you need to tell CMake that the source has changed (this is not usually necessary if you've simply edited an existing source file). You can do this as follows (from your build directory):
touch CMakeCache.txt

CMake uses the MPI wrappers to find your MPI install by default - mpicc and mpif90 must be in your PATH prior to running ccmake

If you'd like to use CMake in a non-interactive fashion, you can use "cmake" instead of "ccmake" and specify and options on the command line by prepending them with "-D". For example:

cmake -DCMAKE_BUILD_TYPE=Release -DPHASTA_INCOMPRESSIBLE=ON -DACUSOLVE_LIB=$HOME/libles.a ../phasta
make

The incompressible solver is disabled by default. You'll need to set the PHASTA_INCOMPRESSIBLE option to "ON" and specify the full path to the Acusolve library when prompted.

A fairly generic version of PHASTA, which includes this build system, can be found on the viz nodes in /users/matthb2/phasta-tocmake/phasta

CMake supports generating scripts for other build tools, for example Xcode, Eclipse and Ninja. See the "cmake" manpage for more information.

Some compilers which can perform inter-procedural analysis have a hard time with PHASTA. See the [[Compilers]] page for information on disabling this optimization if linking takes too long

== Cross Compiling with CMake ==

CMake can cross compile PHASTA, for example on a BlueGene or Cray system. To do this, you simply need to provide an appropriate toolchain file specifying the path to the cross compilers and then build as normal.

ccmake -DCMAKE_TOOLCHAIN_FILE=some_file.cmake ../phasta

There are some toolchain files for systems that we commonly use available [[https://github.com/matthb2/CMakeToolchainFiles here]] (note that the BlueGene/Q toolchain files provided here expect a [[https://github.com/matthb2/CMake/tree/bgq patched version]] of CMake -- see below)

Kitware has some documentation on cross compiling with CMake [[http://www.cmake.org/Wiki/CMake_Cross_Compiling here]].

== Cross Compiling on IBM's BlueGene/Q ==

Currently, CMake doesn't officially have explicit support for BlueGene/Q (BlueGene/P is supported). While you should be able to use a toolchain file expecting one of the generic system types, we've modified the BG/P platform files for /Q, based on the setup used on [[http://alcf.anl.gov ALCF's]] systems (should work with most /Q systems). To use them, you need to add two files [[https://raw.github.com/matthb2/CMake/bgq/Modules/Platform/BlueGeneQ-base.cmake 1]] [[https://raw.github.com/matthb2/CMake/bgq/Modules/Platform/BlueGeneQ-static.cmake 2]] to your CMake install. For a normal install, these files should be placed in $prefix/share/cmake-2.8/Modules/Platform/

If you prefer, you can just directly install the "bgq" branch of [[https://github.com/matthb2/CMake/tree/bgq this repository]]

git clone https://github.com/matthb2/CMake.git
git checkout -b bgq origin/bgq
cd CMake
./configure --prefix=/some/path
make
make install
export PATH=/some/path:$PATH

You can then proceed as above, using [[https://raw.github.com/matthb2/CMakeToolchainFiles/master/BlueGene/Q/BGQ-XLMPI-toolchain.cmake this toolchain file]

Currently, the system software is changing very quickly. If you need a build of the proprietary library used for PHASTA's incompressible solver, please ask Ben or Michel (and tell them which Bluegene driver version you have)

== With gprof ==

(gnu compilers)

CC=gcc CXX=g++ FC=gfortran ccmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS="-pg" -DCMAKE_CXX_FLAGS="-pg" -DCMAKE_Fortran_FLAGS="-pg" ../phasta

BLMesher

2013-08-07T01:07:07Z

Nmati: /* Example 9: Refinement Along an edge */

[[Category:Software]]
How to create the mesh '''using script'''

-----------------------------------------------
== Start ==
* To begin, we need a geometry model. It can be created using commercial softwares such as Solid Work and saved as *.x_t
* You need the BLMesher code which is available on svn:
svn co https://redmine.scorec.rpi.edu/svn/phasta/BLMesher
* If you have read only access to phasta project on redmine, then use:
svn co https://redmine.scorec.rpi.edu/anonsvn/phasta/BLMesher

==Files needed ==
Create a folder and copy all these files into it.
* Geometry model file (geom.xmt_txt or geom.x_t)
* Mesh generation attribution file (Attributes.inp)
* exe file (Run.sh)

File Attributes.inp is the script that defines the mesh generation characteristics for different entities of the model.

Run.sh is an exe file including commands as below:
PATH=/users/chitak/develop/Meshing/BLMesher
$PATH/bin/x86_64_linux/BLMesher-0 geom.xmt_txt geom.sms 1 0.1 BLAttr.inp
It defines the proper path for mesh generator. It also defines that geom.xmt_txt is the model file and the mesh must be created using the attributes defined in Attributes.inp and the mesh data must be written into geom.sms

In the second line of the Run.sh file, the value before attributes.inp (in this case, 0.1) is the size of the boxes that are created before the the final mesh generation. (In fact, BLMesher tries to divide the whole domain into small boxes and then divide these boxes to create the mesh).
Lets call the characteristic size of the domain, d, and the size of the boxes E.

You must choose E as below and use it in Run.sh:
<math> E=\frac{d}{2^{(m+1)}} </math> or <math> E=\frac{d}{2^m} </math>
m is an integer.

Other flags like optimization and smoothing can also be given in this line. Use -h option with the executable to view the complete list of the options and their meaning. Note that the order of these flags is extremely important. Other than the executable, there are 11 other command line inputs which can be given. These can be given in Run.sh with the executable.

== Edit the script ==
* The first line is the version number (for future use). For eg.: version 1
* Use "#" to comment a line or disable it.
* To create attributes for each model entity, two lines in the following format are being used.
<entity dimension> <entity tag> <size type> <attribute type> <extra>
<value or expression for mesh size on this entity>
* Note that a blank line between these two lines is not allowed.

.

== Create the mesh ==
* After preparing the script, execute the file Run.sh. It creates the mesh and write the data to geom.sms (as you defined in Run.sh).
* Note that after executing the Run.sh, you must use command "top" to check the memory usage. If you find out that memory usage is huge and is increasing, you must kill the job before the machine crashes

.

== Visualize the mesh ==
To see the generated mesh, you can use simapps:
/usr/local/simapps/<simapps version>/simapps ThreeDViewer &

.

== Define the mesh characteristics in attribute file ==
The parameters in the first line, respectively are:
- Entity dimension: 2 for 2-D cases and 3 for 3-D cases
- Entity tag: You can find the entity tag using simapps
- Size type on entity: 1 for absolute mesh size and 2 for relative mesh size
- Attribute type on entity:
0 just imposes the size on entity. '''<extra> field''' is NULL
1 for entity with boundary layers. '''<extra> field''' is explained below.
2 for periodic entity: In this case, '''<extra> field''' is followed with slave entity tag
3 for refinement source. Specify entity dimension as -1 in this case. '''<extra> field''' is explained below.

'''<extra> field:'''

For Boundary layer:
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==0, layers with fixed heigths), (c) firstLayerHeight, (d) totalHeight, (e) nLayers, (f) blMixed, (g) blBlends, (h) blPropagate and (i) edgeBLFaceTag (only if 2D BL on edge)
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==2, to vary height linearly between two end/bounding entities), (c) varyDirection, (d) endEntTag1 , (e) firstLayerHeight1, (f) totalHeight1, (g) endEntTag2, (h) firstLayerHeight2, (i) totalHeight2, (j) nLayers, (k) blMixed, (l) blBlends, (m) blPropagate and (n) edgeBLFaceTag (only if 2D BL on edge)

For refinement:
is followed with (a) ref. source type (1-cube, 2-cylinder etc.), (b) source info. as Simmetrix APIs (like radius, length, center and normal in case of cylinder, and center, wdir, hdir and ddir in case of cube/parallelepiped)

* Note if entity dimension is -1, (in case of refinement) do not specify the entity tag and size type.

.

== Example 1: Uniform mesh ==
Simple uniform mesh on region with tag 205
3 205 1 0
2e-4

The above lines can be divided as below:
(3) (205) (1) (0)
(2e-4)

(3): Entity dimension. It's a 3-D region.
(205): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL
(2e-4): Mesh size (This is in the second line)
Note: The second line (Mesh size) can be a value or an expression such as:
0.0125+0.1*(1.0-exp(-3.0*sqrt(($x-0.0)^2+($y-0.0)^2+($z-0.5)^2)))

.

== Example 2: Refinement in a cylindrical region ==
-1 3 1 1.5e-3 1 2 0.3 0 0 0 1
2.5e-4

The above lines can be divided as below:
(-1) (3) (1) (1.5e-3) (1) (2 0.3 0) (0 0 1)
(2.5e-4)

(-1): Entity dimension, for refinement cases
(3): Attribute type. in this case, refinement.
(1): For refinement in a cylindrical region
(1.5e-3 ): Radius
(1): Length of the Cylinder (Half)
(2 0.3 0): The center of the circle
(0 0 1): Axis
(2.5e-4): mesh size (This is in the second line)

.

== Example 3: Refinement in a box region ==
-1 3 2 6e-3 5e-3 0.0 1.5e-3 0.0 0.0 0.0 5.0e-4 0.0 0.0 0.0 5.0e-4
2.5e-4

The above lines can be divided as below:
(-1) (3) (2) (6e-3 5e-3 0.0) (1.5e-3 0.0 0.0) (0.0 5.0e-4 0.0) (0.0 0.0 5.0e-4)
(2.5e-4)

(-1): Entity dimension. -1 only for refinement cases.
(3): Attribute type. in this case, refinement.
(2): For refinement in a box region
(6e-3 5e-3 0.0): The center of the box
(1.5e-3 0.0 0.0): x-Half length
(0.0 5.0e-4 0.0): y-Half length
(0.0 0.0 5.0e-4): z-Half length
(2.5e-4): mesh size (This is in the second line)

.

== Example 4: Refine the mesh along 3 lines on face with tag 5 ==
3 5 1 0
(0.5e-03) +0.1*(1.0-exp(-2.0*sqrt(($x-1.9)^2+($y-0.36)^2)))*(1.0-exp(-10.0*sqrt(($x-1.77)^2+($y-0.42)^2)))*(1.0-exp(-6.0*sqrt(($x-1.8)^2+($y-0.43)^2)))
The first line can be divided as below:
(3) (5) (1) (0)

(3): Entity dimension, 3-D
(5): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL

This is an example of an expression that will make the mesh fine in three lines. e.g., x=1.9 y=0.36 on model entity number 5.

.

== Example 5: Periodic mesh ==

If periodic BC is used at two faces, the mesh must be identical in both of them.

In this case, faces 1 and 81 are periodic

2 1 1 2 81
2.1e-4

The above lines can be divided as below:
(2) (1) (1) (2) (81)
(2.1e-4)

(2): Entity dimension, 2-D. it's a face.
(1): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(2): Attribute type on entity. 2 for periodic entity. <extra> field is followed with a slave entity tag
(81): Slave entity tag
(2.1e-4):mesh size (This is in the second line)

.

== Example 6: Boundary layer mesh , constant thickness ==
On face with tag 173
2 173 1 1 0 0 0.4e-4 3.e-4 5 0 0 0
1.61e-4

The above lines can be divided as below:
(2) (173) (1) (1) (0) (0) (0.4e-4) (3.e-4) (5) (0) (0) (0)
(1.61e-4)

(2): Entity dimension, 2-D. it's a face.
(173): Face tag
(1): Size type on entity. 1 for absolute mesh size
(1): Attribute type on entity. 1 for entity with boundary layers.
(0): Boundary layer orientation (FaceSide/useDir)
(0): NumEndEnts. 0 for layers with fixed heights
(0.4e-4): First layer height
(3.e-4): Total height of boundary layer
(5): Number of layers
(0): Boundary layer Mixed topology (1 for triangles and quads)
(0): Boundary layer blending. 0 for no BL blending
(0): Boundary Layer propagation
(1.61e-4): mesh size on the surface (This value is in the second line)

If you are specifying a 2D BL on a model edge, then at the end of the line, you have to give a target face tag, to which face you want that BL attribute applied.

.

== Example 7: Boundary layer mesh, ramped thickness ==
On face with tag 27
2 27 1 1 0 2 0 22 1.e-3 2.e-2 20 2.e-3 10.e-2 5 1 0 0
0.1

The above lines can be divided as below:
(2) (27) (1) (1) (0) (2) (0) (22) (1.e-3) (2.e-2) (20) (2.e-3) (10.e-2) (5) (1) (0) (0)
(0.1)

(2): Entity dimension, 2-D. it's a face.
(27): Face tag
(1): Size type on entity. 1 for absolute mesh size
(1): Attribute type on entity. 1 for entity with boundary layers.
(0): Boundary layer orientation (FaceSide/useDir)
(2): For Layers with linearly varying height (NumEndEnts)
(0): Direction of variation (pos. x-dir.)
(22): Edge tag at pos. 1
(1.e-3): First layer height at pos. 1
(2.e-2): Total height of all layers at pos. 1
(20): Edge tag at pos. 2
(2.e-3): First layer height at pos. 2
(10.e-2): Total height of all layers at pos. 2
(5): Number of layers
(1): Boundary layer Mixed topology (1 for triangles and quads)
(0): Boundary layer blending. 0 for no BL blending
(0): Boundary Layer propagation. 0 for no propogation
(0.1): mesh size on the surface (This value is in the second line)

== Example 8: Global BL attributes ==

These can be set globally as follows. Only 1 attribute can be set at a time.

-1 7 attribute_type
value

The above lines can be divided as below:
(-1) (7) (attribute_type)
(value)

(-1): Entity dimension. -1 for setting global attributes
(7): for setting BL global attribute
(attribute_type): type of BL attribute you want to set. It can be one of the following:
1: smoothing distance
2: layer edge aspect ratio
3: exposed aspect ratio (opposite of aspect ratio, look at the documentation MS_minExposedAspectRatio for more info)
(value): value for the above attribute

== Example 9: Refinement Along an Edge ==

For uniform refinement along an edge with tag 333
1 333 1 0
2e-4

The above lines can be divided as below:
(1) (333) (1) (0)
(2e-4)

(1): Entity dimension. It's a 1-D line.
(333): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity.
(2e-4): Mesh size (This is in the second line)

BLMesher

2013-08-07T01:06:40Z

Nmati: /* Example 8: Global BL attributes */

[[Category:Software]]
How to create the mesh '''using script'''

-----------------------------------------------
== Start ==
* To begin, we need a geometry model. It can be created using commercial softwares such as Solid Work and saved as *.x_t
* You need the BLMesher code which is available on svn:
svn co https://redmine.scorec.rpi.edu/svn/phasta/BLMesher
* If you have read only access to phasta project on redmine, then use:
svn co https://redmine.scorec.rpi.edu/anonsvn/phasta/BLMesher

==Files needed ==
Create a folder and copy all these files into it.
* Geometry model file (geom.xmt_txt or geom.x_t)
* Mesh generation attribution file (Attributes.inp)
* exe file (Run.sh)

File Attributes.inp is the script that defines the mesh generation characteristics for different entities of the model.

Run.sh is an exe file including commands as below:
PATH=/users/chitak/develop/Meshing/BLMesher
$PATH/bin/x86_64_linux/BLMesher-0 geom.xmt_txt geom.sms 1 0.1 BLAttr.inp
It defines the proper path for mesh generator. It also defines that geom.xmt_txt is the model file and the mesh must be created using the attributes defined in Attributes.inp and the mesh data must be written into geom.sms

In the second line of the Run.sh file, the value before attributes.inp (in this case, 0.1) is the size of the boxes that are created before the the final mesh generation. (In fact, BLMesher tries to divide the whole domain into small boxes and then divide these boxes to create the mesh).
Lets call the characteristic size of the domain, d, and the size of the boxes E.

You must choose E as below and use it in Run.sh:
<math> E=\frac{d}{2^{(m+1)}} </math> or <math> E=\frac{d}{2^m} </math>
m is an integer.

Other flags like optimization and smoothing can also be given in this line. Use -h option with the executable to view the complete list of the options and their meaning. Note that the order of these flags is extremely important. Other than the executable, there are 11 other command line inputs which can be given. These can be given in Run.sh with the executable.

== Edit the script ==
* The first line is the version number (for future use). For eg.: version 1
* Use "#" to comment a line or disable it.
* To create attributes for each model entity, two lines in the following format are being used.
<entity dimension> <entity tag> <size type> <attribute type> <extra>
<value or expression for mesh size on this entity>
* Note that a blank line between these two lines is not allowed.

.

== Create the mesh ==
* After preparing the script, execute the file Run.sh. It creates the mesh and write the data to geom.sms (as you defined in Run.sh).
* Note that after executing the Run.sh, you must use command "top" to check the memory usage. If you find out that memory usage is huge and is increasing, you must kill the job before the machine crashes

.

== Visualize the mesh ==
To see the generated mesh, you can use simapps:
/usr/local/simapps/<simapps version>/simapps ThreeDViewer &

.

== Define the mesh characteristics in attribute file ==
The parameters in the first line, respectively are:
- Entity dimension: 2 for 2-D cases and 3 for 3-D cases
- Entity tag: You can find the entity tag using simapps
- Size type on entity: 1 for absolute mesh size and 2 for relative mesh size
- Attribute type on entity:
0 just imposes the size on entity. '''<extra> field''' is NULL
1 for entity with boundary layers. '''<extra> field''' is explained below.
2 for periodic entity: In this case, '''<extra> field''' is followed with slave entity tag
3 for refinement source. Specify entity dimension as -1 in this case. '''<extra> field''' is explained below.

'''<extra> field:'''

For Boundary layer:
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==0, layers with fixed heigths), (c) firstLayerHeight, (d) totalHeight, (e) nLayers, (f) blMixed, (g) blBlends, (h) blPropagate and (i) edgeBLFaceTag (only if 2D BL on edge)
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==2, to vary height linearly between two end/bounding entities), (c) varyDirection, (d) endEntTag1 , (e) firstLayerHeight1, (f) totalHeight1, (g) endEntTag2, (h) firstLayerHeight2, (i) totalHeight2, (j) nLayers, (k) blMixed, (l) blBlends, (m) blPropagate and (n) edgeBLFaceTag (only if 2D BL on edge)

For refinement:
is followed with (a) ref. source type (1-cube, 2-cylinder etc.), (b) source info. as Simmetrix APIs (like radius, length, center and normal in case of cylinder, and center, wdir, hdir and ddir in case of cube/parallelepiped)

* Note if entity dimension is -1, (in case of refinement) do not specify the entity tag and size type.

.

== Example 1: Uniform mesh ==
Simple uniform mesh on region with tag 205
3 205 1 0
2e-4

The above lines can be divided as below:
(3) (205) (1) (0)
(2e-4)

(3): Entity dimension. It's a 3-D region.
(205): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL
(2e-4): Mesh size (This is in the second line)
Note: The second line (Mesh size) can be a value or an expression such as:
0.0125+0.1*(1.0-exp(-3.0*sqrt(($x-0.0)^2+($y-0.0)^2+($z-0.5)^2)))

.

== Example 2: Refinement in a cylindrical region ==
-1 3 1 1.5e-3 1 2 0.3 0 0 0 1
2.5e-4

The above lines can be divided as below:
(-1) (3) (1) (1.5e-3) (1) (2 0.3 0) (0 0 1)
(2.5e-4)

(-1): Entity dimension, for refinement cases
(3): Attribute type. in this case, refinement.
(1): For refinement in a cylindrical region
(1.5e-3 ): Radius
(1): Length of the Cylinder (Half)
(2 0.3 0): The center of the circle
(0 0 1): Axis
(2.5e-4): mesh size (This is in the second line)

.

== Example 3: Refinement in a box region ==
-1 3 2 6e-3 5e-3 0.0 1.5e-3 0.0 0.0 0.0 5.0e-4 0.0 0.0 0.0 5.0e-4
2.5e-4

The above lines can be divided as below:
(-1) (3) (2) (6e-3 5e-3 0.0) (1.5e-3 0.0 0.0) (0.0 5.0e-4 0.0) (0.0 0.0 5.0e-4)
(2.5e-4)

(-1): Entity dimension. -1 only for refinement cases.
(3): Attribute type. in this case, refinement.
(2): For refinement in a box region
(6e-3 5e-3 0.0): The center of the box
(1.5e-3 0.0 0.0): x-Half length
(0.0 5.0e-4 0.0): y-Half length
(0.0 0.0 5.0e-4): z-Half length
(2.5e-4): mesh size (This is in the second line)

.

== Example 4: Refine the mesh along 3 lines on face with tag 5 ==
3 5 1 0
(0.5e-03) +0.1*(1.0-exp(-2.0*sqrt(($x-1.9)^2+($y-0.36)^2)))*(1.0-exp(-10.0*sqrt(($x-1.77)^2+($y-0.42)^2)))*(1.0-exp(-6.0*sqrt(($x-1.8)^2+($y-0.43)^2)))
The first line can be divided as below:
(3) (5) (1) (0)

(3): Entity dimension, 3-D
(5): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL

This is an example of an expression that will make the mesh fine in three lines. e.g., x=1.9 y=0.36 on model entity number 5.

.

== Example 5: Periodic mesh ==

If periodic BC is used at two faces, the mesh must be identical in both of them.

In this case, faces 1 and 81 are periodic

2 1 1 2 81
2.1e-4

The above lines can be divided as below:
(2) (1) (1) (2) (81)
(2.1e-4)

(2): Entity dimension, 2-D. it's a face.
(1): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(2): Attribute type on entity. 2 for periodic entity. <extra> field is followed with a slave entity tag
(81): Slave entity tag
(2.1e-4):mesh size (This is in the second line)

.

== Example 6: Boundary layer mesh , constant thickness ==
On face with tag 173
2 173 1 1 0 0 0.4e-4 3.e-4 5 0 0 0
1.61e-4

The above lines can be divided as below:
(2) (173) (1) (1) (0) (0) (0.4e-4) (3.e-4) (5) (0) (0) (0)
(1.61e-4)

(2): Entity dimension, 2-D. it's a face.
(173): Face tag
(1): Size type on entity. 1 for absolute mesh size
(1): Attribute type on entity. 1 for entity with boundary layers.
(0): Boundary layer orientation (FaceSide/useDir)
(0): NumEndEnts. 0 for layers with fixed heights
(0.4e-4): First layer height
(3.e-4): Total height of boundary layer
(5): Number of layers
(0): Boundary layer Mixed topology (1 for triangles and quads)
(0): Boundary layer blending. 0 for no BL blending
(0): Boundary Layer propagation
(1.61e-4): mesh size on the surface (This value is in the second line)

If you are specifying a 2D BL on a model edge, then at the end of the line, you have to give a target face tag, to which face you want that BL attribute applied.

.

== Example 7: Boundary layer mesh, ramped thickness ==
On face with tag 27
2 27 1 1 0 2 0 22 1.e-3 2.e-2 20 2.e-3 10.e-2 5 1 0 0
0.1

The above lines can be divided as below:
(2) (27) (1) (1) (0) (2) (0) (22) (1.e-3) (2.e-2) (20) (2.e-3) (10.e-2) (5) (1) (0) (0)
(0.1)

(2): Entity dimension, 2-D. it's a face.
(27): Face tag
(1): Size type on entity. 1 for absolute mesh size
(1): Attribute type on entity. 1 for entity with boundary layers.
(0): Boundary layer orientation (FaceSide/useDir)
(2): For Layers with linearly varying height (NumEndEnts)
(0): Direction of variation (pos. x-dir.)
(22): Edge tag at pos. 1
(1.e-3): First layer height at pos. 1
(2.e-2): Total height of all layers at pos. 1
(20): Edge tag at pos. 2
(2.e-3): First layer height at pos. 2
(10.e-2): Total height of all layers at pos. 2
(5): Number of layers
(1): Boundary layer Mixed topology (1 for triangles and quads)
(0): Boundary layer blending. 0 for no BL blending
(0): Boundary Layer propagation. 0 for no propogation
(0.1): mesh size on the surface (This value is in the second line)

== Example 8: Global BL attributes ==

These can be set globally as follows. Only 1 attribute can be set at a time.

-1 7 attribute_type
value

The above lines can be divided as below:
(-1) (7) (attribute_type)
(value)

(-1): Entity dimension. -1 for setting global attributes
(7): for setting BL global attribute
(attribute_type): type of BL attribute you want to set. It can be one of the following:
1: smoothing distance
2: layer edge aspect ratio
3: exposed aspect ratio (opposite of aspect ratio, look at the documentation MS_minExposedAspectRatio for more info)
(value): value for the above attribute

== Example 9: Refinement Along an edge ==

For uniform refinement along an edge with tag 333
1 333 1 0
2e-4

The above lines can be divided as below:
(1) (333) (1) (0)
(2e-4)

(1): Entity dimension. It's a 1-D line.
(333): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity.
(2e-4): Mesh size (This is in the second line)

BLMesher

2013-08-07T01:06:21Z

Nmati: Added an edge refinement example

[[Category:Software]]
How to create the mesh '''using script'''

-----------------------------------------------
== Start ==
* To begin, we need a geometry model. It can be created using commercial softwares such as Solid Work and saved as *.x_t
* You need the BLMesher code which is available on svn:
svn co https://redmine.scorec.rpi.edu/svn/phasta/BLMesher
* If you have read only access to phasta project on redmine, then use:
svn co https://redmine.scorec.rpi.edu/anonsvn/phasta/BLMesher

==Files needed ==
Create a folder and copy all these files into it.
* Geometry model file (geom.xmt_txt or geom.x_t)
* Mesh generation attribution file (Attributes.inp)
* exe file (Run.sh)

File Attributes.inp is the script that defines the mesh generation characteristics for different entities of the model.

Run.sh is an exe file including commands as below:
PATH=/users/chitak/develop/Meshing/BLMesher
$PATH/bin/x86_64_linux/BLMesher-0 geom.xmt_txt geom.sms 1 0.1 BLAttr.inp
It defines the proper path for mesh generator. It also defines that geom.xmt_txt is the model file and the mesh must be created using the attributes defined in Attributes.inp and the mesh data must be written into geom.sms

In the second line of the Run.sh file, the value before attributes.inp (in this case, 0.1) is the size of the boxes that are created before the the final mesh generation. (In fact, BLMesher tries to divide the whole domain into small boxes and then divide these boxes to create the mesh).
Lets call the characteristic size of the domain, d, and the size of the boxes E.

You must choose E as below and use it in Run.sh:
<math> E=\frac{d}{2^{(m+1)}} </math> or <math> E=\frac{d}{2^m} </math>
m is an integer.

Other flags like optimization and smoothing can also be given in this line. Use -h option with the executable to view the complete list of the options and their meaning. Note that the order of these flags is extremely important. Other than the executable, there are 11 other command line inputs which can be given. These can be given in Run.sh with the executable.

== Edit the script ==
* The first line is the version number (for future use). For eg.: version 1
* Use "#" to comment a line or disable it.
* To create attributes for each model entity, two lines in the following format are being used.
<entity dimension> <entity tag> <size type> <attribute type> <extra>
<value or expression for mesh size on this entity>
* Note that a blank line between these two lines is not allowed.

.

== Create the mesh ==
* After preparing the script, execute the file Run.sh. It creates the mesh and write the data to geom.sms (as you defined in Run.sh).
* Note that after executing the Run.sh, you must use command "top" to check the memory usage. If you find out that memory usage is huge and is increasing, you must kill the job before the machine crashes

.

== Visualize the mesh ==
To see the generated mesh, you can use simapps:
/usr/local/simapps/<simapps version>/simapps ThreeDViewer &

.

== Define the mesh characteristics in attribute file ==
The parameters in the first line, respectively are:
- Entity dimension: 2 for 2-D cases and 3 for 3-D cases
- Entity tag: You can find the entity tag using simapps
- Size type on entity: 1 for absolute mesh size and 2 for relative mesh size
- Attribute type on entity:
0 just imposes the size on entity. '''<extra> field''' is NULL
1 for entity with boundary layers. '''<extra> field''' is explained below.
2 for periodic entity: In this case, '''<extra> field''' is followed with slave entity tag
3 for refinement source. Specify entity dimension as -1 in this case. '''<extra> field''' is explained below.

'''<extra> field:'''

For Boundary layer:
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==0, layers with fixed heigths), (c) firstLayerHeight, (d) totalHeight, (e) nLayers, (f) blMixed, (g) blBlends, (h) blPropagate and (i) edgeBLFaceTag (only if 2D BL on edge)
is followed with (a) faceSide/useDir (BL orientation), (b) numEndEnts (==2, to vary height linearly between two end/bounding entities), (c) varyDirection, (d) endEntTag1 , (e) firstLayerHeight1, (f) totalHeight1, (g) endEntTag2, (h) firstLayerHeight2, (i) totalHeight2, (j) nLayers, (k) blMixed, (l) blBlends, (m) blPropagate and (n) edgeBLFaceTag (only if 2D BL on edge)

For refinement:
is followed with (a) ref. source type (1-cube, 2-cylinder etc.), (b) source info. as Simmetrix APIs (like radius, length, center and normal in case of cylinder, and center, wdir, hdir and ddir in case of cube/parallelepiped)

* Note if entity dimension is -1, (in case of refinement) do not specify the entity tag and size type.

.

== Example 1: Uniform mesh ==
Simple uniform mesh on region with tag 205
3 205 1 0
2e-4

The above lines can be divided as below:
(3) (205) (1) (0)
(2e-4)

(3): Entity dimension. It's a 3-D region.
(205): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL
(2e-4): Mesh size (This is in the second line)
Note: The second line (Mesh size) can be a value or an expression such as:
0.0125+0.1*(1.0-exp(-3.0*sqrt(($x-0.0)^2+($y-0.0)^2+($z-0.5)^2)))

.

== Example 2: Refinement in a cylindrical region ==
-1 3 1 1.5e-3 1 2 0.3 0 0 0 1
2.5e-4

The above lines can be divided as below:
(-1) (3) (1) (1.5e-3) (1) (2 0.3 0) (0 0 1)
(2.5e-4)

(-1): Entity dimension, for refinement cases
(3): Attribute type. in this case, refinement.
(1): For refinement in a cylindrical region
(1.5e-3 ): Radius
(1): Length of the Cylinder (Half)
(2 0.3 0): The center of the circle
(0 0 1): Axis
(2.5e-4): mesh size (This is in the second line)

.

== Example 3: Refinement in a box region ==
-1 3 2 6e-3 5e-3 0.0 1.5e-3 0.0 0.0 0.0 5.0e-4 0.0 0.0 0.0 5.0e-4
2.5e-4

The above lines can be divided as below:
(-1) (3) (2) (6e-3 5e-3 0.0) (1.5e-3 0.0 0.0) (0.0 5.0e-4 0.0) (0.0 0.0 5.0e-4)
(2.5e-4)

(-1): Entity dimension. -1 only for refinement cases.
(3): Attribute type. in this case, refinement.
(2): For refinement in a box region
(6e-3 5e-3 0.0): The center of the box
(1.5e-3 0.0 0.0): x-Half length
(0.0 5.0e-4 0.0): y-Half length
(0.0 0.0 5.0e-4): z-Half length
(2.5e-4): mesh size (This is in the second line)

.

== Example 4: Refine the mesh along 3 lines on face with tag 5 ==
3 5 1 0
(0.5e-03) +0.1*(1.0-exp(-2.0*sqrt(($x-1.9)^2+($y-0.36)^2)))*(1.0-exp(-10.0*sqrt(($x-1.77)^2+($y-0.42)^2)))*(1.0-exp(-6.0*sqrt(($x-1.8)^2+($y-0.43)^2)))
The first line can be divided as below:
(3) (5) (1) (0)

(3): Entity dimension, 3-D
(5): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity. <extra> field is NULL

This is an example of an expression that will make the mesh fine in three lines. e.g., x=1.9 y=0.36 on model entity number 5.

.

== Example 5: Periodic mesh ==

If periodic BC is used at two faces, the mesh must be identical in both of them.

In this case, faces 1 and 81 are periodic

2 1 1 2 81
2.1e-4

The above lines can be divided as below:
(2) (1) (1) (2) (81)
(2.1e-4)

(2): Entity dimension, 2-D. it's a face.
(1): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(2): Attribute type on entity. 2 for periodic entity. <extra> field is followed with a slave entity tag
(81): Slave entity tag
(2.1e-4):mesh size (This is in the second line)

.

== Example 6: Boundary layer mesh , constant thickness ==
On face with tag 173
2 173 1 1 0 0 0.4e-4 3.e-4 5 0 0 0
1.61e-4

The above lines can be divided as below:
(2) (173) (1) (1) (0) (0) (0.4e-4) (3.e-4) (5) (0) (0) (0)
(1.61e-4)

(2): Entity dimension, 2-D. it's a face.
(173): Face tag
(1): Size type on entity. 1 for absolute mesh size
(1): Attribute type on entity. 1 for entity with boundary layers.
(0): Boundary layer orientation (FaceSide/useDir)
(0): NumEndEnts. 0 for layers with fixed heights
(0.4e-4): First layer height
(3.e-4): Total height of boundary layer
(5): Number of layers
(0): Boundary layer Mixed topology (1 for triangles and quads)
(0): Boundary layer blending. 0 for no BL blending
(0): Boundary Layer propagation
(1.61e-4): mesh size on the surface (This value is in the second line)

If you are specifying a 2D BL on a model edge, then at the end of the line, you have to give a target face tag, to which face you want that BL attribute applied.

.

== Example 7: Boundary layer mesh, ramped thickness ==
On face with tag 27
2 27 1 1 0 2 0 22 1.e-3 2.e-2 20 2.e-3 10.e-2 5 1 0 0
0.1

The above lines can be divided as below:
(2) (27) (1) (1) (0) (2) (0) (22) (1.e-3) (2.e-2) (20) (2.e-3) (10.e-2) (5) (1) (0) (0)
(0.1)

(2): Entity dimension, 2-D. it's a face.
(27): Face tag
(1): Size type on entity. 1 for absolute mesh size
(1): Attribute type on entity. 1 for entity with boundary layers.
(0): Boundary layer orientation (FaceSide/useDir)
(2): For Layers with linearly varying height (NumEndEnts)
(0): Direction of variation (pos. x-dir.)
(22): Edge tag at pos. 1
(1.e-3): First layer height at pos. 1
(2.e-2): Total height of all layers at pos. 1
(20): Edge tag at pos. 2
(2.e-3): First layer height at pos. 2
(10.e-2): Total height of all layers at pos. 2
(5): Number of layers
(1): Boundary layer Mixed topology (1 for triangles and quads)
(0): Boundary layer blending. 0 for no BL blending
(0): Boundary Layer propagation. 0 for no propogation
(0.1): mesh size on the surface (This value is in the second line)

== Example 8: Global BL attributes ==

These can be set globally as follows. Only 1 attribute can be set at a time.

-1 7 attribute_type
value

The above lines can be divided as below:
(-1) (7) (attribute_type)
(value)

(-1): Entity dimension. -1 for setting global attributes
(7): for setting BL global attribute
(attribute_type): type of BL attribute you want to set. It can be one of the following:
1: smoothing distance
2: layer edge aspect ratio
3: exposed aspect ratio (opposite of aspect ratio, look at the documentation MS_minExposedAspectRatio for more info)
(value): value for the above attribute

.== Example 9: Refinement Along an edge ==

For uniform refinement along an edge with tag 333
1 333 1 0
2e-4

The above lines can be divided as below:
(1) (333) (1) (0)
(2e-4)

(1): Entity dimension. It's a 1-D line.
(333): Entity tag
(1): Size type on entity. 1 for absolute mesh size
(0): Attribute type on entity. 0 just imposes the size on entity.
(2e-4): Mesh size (This is in the second line)

Creating geom.spj

2013-07-24T20:42:34Z

Nmati:

-----------------------------------------------
*create a directory for the .smf and .spj files (mkdir SMF_and_SPJ_files), cd to that directory and start SimulationMaker. There are a number of versions of simulation maker available. One of the oldest is 090321 which can be run with
vglrun /usr/local/simapps/sdk-090321/simapps SimulationMaker
At the time of writing, this version is commonly used, but very deprecated. Instead, try to use just about any other version we have, e.g.
soft add +simappssdk-7.2-120125
simapps SimulationMaker
*In the GUI which comes up
**Set "Default Solver" to Phasta
**Browse to the appropriate geometry file and select it (make sure it is not the SpaceClaim parasolid file; it should be the file you saved from ThreeDViewer - geom.xmt_txt) (Debated - it may be that the parasolid was saved in an unsupported version; try v24.0 instead of v25.0).
**Turn OFF sliver feature suppression
**Click Define Simulation Model Instance
*The attribute list and model will appear in split windows. At the top of the list, double click on the name "problem definition" and set the name to "geom".
*To set attributes, make sure the field with "geom", which you just changed, is selected. Using the model to the right, click on whichever faces you want to give attributes, and go to "Create" at the upper left hand corner to select the appropriate attribute.
*The names of the attributes are arbitrary, but should be something meaningful to the user and whoever else is involved in the project.
*'''Make sure you save the smf file very frequently so that you don't lose your work'''. Do File -> Save.

==For Incompressible Flow==
=== Inflow ===
comp3: The name is arbitrary but should be set to something meaningful (i.e. Inflow). Click on the inflow face (which is the face which makes up the front of the wind tunnel) and go to Create -> comp3. Set vector magnitude to the free-stream velocity you want. Set the vector direction to the direction (i.e. if the free-stream velocity moves strictly along the x-axis, the direction would be [1 0 0]). Even if the vector magnitude is 0, '''the direction CANNOT be [0 0 0]'''. This will cause Phasta to crash. It must have at least one non-zero component. In this case, just set it to [1 0 0].

scalar_1: Click on the inflow face and go to Create -> scalar_1. Set the field "Type: scalar_1" to 1.8e-7. This is the eddy viscosity at the inlet. (Debated: Spalart Almaras EV BCs typically use a value on the order of molecular viscosity which, in turn, is typically approximately 1.8e-5 for air at room temperature)
=== Outflow ===
natural pressure: Set "Type: natural pressure" to 0.

scalar_1 flux: Set this to 0.

traction vector: Set this to [0 0 0]

=== TopBottomWalls ===
*These are the walls of the wind tunnel that bound the model from above and below. The terms "above" and "below" are arbitrary, but we typically define them so that their normal points along the z-axis. However, this is not necessary.
scalar_1 flux: Set this to 0.

traction vector: Set this to [0 0 0].

comp1: The vector magnitude should be 0. The direction depends on which direction the normal of the wall points. If it is along the z-axis, then this will be [0 0 1]. If it is along the y-axis, this will be [0 1 0]. This attribute signifies a no-penetration condition through the tunnel walls.

=== SideWalls ===
*These are also arbitrary. But if you already defined the TopBottomWalls, then you already know which walls they are.
scalar_1 flux: Set this to 0

traction vector: Set this to [0 0 0]

comp1: Set vector magnitude to 0. The direction should be set to whichever direction the normal of the walls point.

=== Initial Conditions ===
Initial Velocity: In the model window, go to Selection -> Select Model. In the attribute window, go to Create -> initial velocity. Set this to [1e-8 0 0]

Initial Pressure: Set to 0

Initial Scalar_1: Set to 1.8e-7

=== No-Slip Walls ===
comp3: Set the no-slip walls with comp3. The name should be something meaningful (i.e. NoSlip_comp3). For Boeing, the the only walls that do not get no-slip are the tunnel walls. Therefore, what you should do is go to Selection -> "Select All Model Faces" and then create a comp3. The vector magnitude is 0, and the '''direction must be non-zero''' (i.e. [1 0 0] is fine but [0 0 0] is not). Click Apply and Close. Re-open that attribute, find each of the 6 tunnel walls and click on "Model Associations" at the top of the Attribute Editor and delete them. The faces should be in numerical order in the list. Apply and Close.

=== Setting Eddy Viscosity on the Wall ===
scalar_1: For the Boeing model, the only walls that don't get this attribute are the tunnel walls. Set this attribute to 0.

=== Computing Distance to the Wall for the Turbulence Model ===
turbulence wall: For the Boeing model, the only faces that do not receive this attribute are the tunnel walls '''and the jet diaphragms'''.

=== Identifying Specific Surfaces with an ID Number===
*This must be done for the jet diaphragms in order to turn them on and off. The jets are traditionally ordered from tip to root. So if there are 12 jets, label the jet closest to the tip 1, and the jet closest to the root 12. Click on the surface, go to Create -> Surf ID. Set the value of the ID in Type: Surf ID.

*This also must be done in order for phasta to compute the aerodynamic force for sets of surfaces. If you want to know C_L for the rudder and stabilizer for example, give all the stabilizer surfaces an ID of 13, and all the rudder surfaces an ID of 14. The value of the ID is arbitrary, but must be different from other surf ID's.

=== Creating geom.spj ===
*When all the attributes are completed, save the smf file one last time. At the top menu, to the right of "Meshing Process", click on Attributes -> Export Attributes. Save it in the same place as geom.smf and save it as geom.spj.

PHASTA/Wish List

2013-07-02T00:18:55Z

Nmati:

PHASTA/Wish List

2013-07-02T00:18:03Z

Nmati: Created page with "This page is intended to be a log of useful features to add to various tools such as Phasta and NSpre. Odds are that no one will ever actually implement anything listed on this ..."

Janus Cheat Sheet

2013-06-25T00:11:48Z

Nmati: /* Allocation Status */

== Login ==
ssh your_identikey_user@login.rc.colorado.edu
[pin][token]

== Running Jobs ==
Environment Setup:
use Torque
use Moab
use Git
use .openmpi-1.4.3_intel-12.0_ib
use Graphviz
use Subversion

Viewing the list of dotkit modules (software) that you have loaded
echo $_dk_inuse
available nodes/cores:

pbsnodes -a
showbf
Jobscript Template:

#!/bin/bash
#PBS -N name_of_job
#PBS -l walltime=0:20:00
#PBS -l nodes=1:ppn=12
. /curc/tools/utils/dkinit
reuse .openmpi-1.4.3_intel-12.0_ib

mpirun /path/to/executable

Submission:

qsub -q janus-debug jobscript.sh

Status

checkjob job_id
showq -u $USER

Cancel:

qdel job_id

Large Memory, Interactive:

qsub -I -l nodes=1:ppn=32,walltime=1:00:00 -q himem

Interactive, for debugging (with totalviewer)

ssh -Y "user_id"@janus.rc.colorado.edu

qsub -I -X -l nodes=1:ppn=12,walltime=1:00:00 -q janus-debug

Non Default allocation:

qsub -A UCBXXXXXXX job.sh

or in the job script:
#PBS -A UCBXXXXXXX

== Debugging PHASTA ==
If you are getting hanging codes or crashing codes, compile with the pgi compilers and try the following flags on C, C++ and Fortran:

-Ktrap=fp -Mbounds -Kieee

For PHASTA with cmake, you need to:

CC=pgcc CXX=pgCC FC=pgfortran ccmake ../phasta

Then, add the compilation flags above to the following variables:

CMAKE_CXX_FLAGS and CMAKE_C_FLAGS and CMAKE_Fortran_FLAGS variables

Basically this will make your code crash where you get floating point exceptions, go out of bounds with arrays, or have ieee exceptions. Then if you type

set catchDebugger=1

and then

mpirun <exec>

it will launch debug windows which when you release them will stop at the point of your "foul" which REALLY helps.
More info: http://www.pgroup.com/userforum/viewtopic.php?t=1898&postdays=0&postorder=asc&start=0&sid=719a9d9871bf16add8565a398ba548f3

== Allocation Status ==
module load utils/Crc-allocations
check_allocation
module load Moab
showstats -u $USER

==[[GridFTP]]==
export MYPROXY_SERVER_DN=$MYPROXY_SERVER_DN"/C=US/O=Globus Consortium/OU=Globus Connect Service/CN=842a610a-4de7-11e1-9674-123138151443"
myproxy-logon -T -b -s gridftp-00.rc.colorado.edu -v -l bema1643

globus-url-copy -v -r -cd -rst -rst-retries 0 -fast -vb -p 64 -stripe -tcp-bs 4M -g2 -ss '/C=US/O=Globus Consortium/OU=Globus Connect Service/CN=842a610a-4de7-11e1-9674-123138151443' gsiftp://gridftp-00.rc.colorado.edu/lustre/janus_scratch/bema1643/test.img sshftp://matthb2@jumpgate-phasta.colorado.edu/scratch/matthb2/foo/

globus-url-copy -v -r -cd -rst -rst-retries 0 -fast -vb -p 64 -stripe -tcp-bs 4M -g2 -ds '/C=US/O=Globus Consortium/OU=Globus Connect Service/CN=842a610a-4de7-11e1-9674-123138151443' sshftp://matthb2@jumpgate-phasta.colorado.edu/scratch/mrasquin/416M/ gsiftp://gridftp-00.rc.colorado.edu/lustre/janus_scratch/bema1643/

(note: -ss to specify that the source server has a non-standard DN, -ds for the destination)

==Queues/Policy==
https://www.rc.colorado.edu/crcdocs/queues
https://www.rc.colorado.edu/policies/janus-jobs

PHASTA/Probe points

2013-06-21T09:04:01Z

Nmati: /* Location in Phasta */

PHASTA/Probe points

2013-06-21T08:44:41Z

Nmati: /* Using Probe Points */

Phasta is capable of outputting solution field variables such as velocity, pressure, eddy viscosity, and temperature (if applicable) at specified locations in the fluid domain.

== Using Probe Points ==

To enable probe points, the file xyzts.dat and the folder varts/ must both be present in the n-procs_case directory that is being used by Phasta. The file xyzts.dat should contain a one line, space delineated header with the following numeric data (based of of the version in /users/mattb2/phasta-tocmake/...)

*number of probes
*frequency (i.e. the number of steps between sampling)
*tolerance (unused)
*iterate (unused)
*varcod (unused)

The lines following the header should contain x, y, z data specifying the location of the probe points. As an example, a valid xyzts.dat file for an incompressible run would look something like:

4 1 1.0e-6 1 5
0.2 -0.02 -0.01
0.2 -0.02 0.01
0.3 -0.02 -0.01
0.3 -0.02 0.01

...although a header of 4 1 1 1 1 should be equally as valid.

For multiple cases which use the same probe locations, it is often convenient to keep xyzts.dat in a lower level directory and soft link to it. That is, the setup process becomes
cd n-procs_case
mkdir varts
ln -s ../../xyzts.dat .

Note: in most versions of Phasta, the varts.*.sn files are created prior to the calculation of the first time step, but are actually written to ''after'' finishing the last time step. This means that if a run is interrupted (e.g. by not requesting enough time in a queue), no useful data will be generated.

== Location in Phasta ==

In the compressible version of Phasta, xyzts.dat appears to be read exclusively in
phSolver/compressible/itrdrv.f.

At least in the NGC version of the code (as of 2013-06-13), the fifth input is unused

Being Written

SimModeler

2013-06-21T08:33:31Z

Nmati:

[[Category:Software]]

SimModeler is a model creation program from Simmetrix. It takes the mesh and geometric model and creates the input files for PHASTA.

== Running ==
To run SimModeler, first connect via VNC, then use vglconnect to connect to one of the compute machines:

vglconnect -s viz001

Add the desired version of SimModeler to your environment (the below example will get the "default" version):

soft add +simmodeler

and lunch the GUI:

vglrun simmodeler

== Converting old files ==
This is a guide for converting old files (parasolid and .spj) to the new format (.smd).

After connecting to one of the compute machines, add the suite of tools for SimModeler to your environment:

soft add +simmodsuite

From your case, make a new directory and copy your parasolid (.x_t or .xmt_txt), and .spj file into it. Rename the parasolid file to geom.xmt_txt and the .spj file to geom.spj, if they aren't already named that way. Then from the directory just created (now holds geom.xmt_txt and geom.spj) run:

~matthb2/simmodelerconvert/testConvert

Your directory now contains two new files: model.smd and model.x_t

== Creating new files ==

Loading in geometry is about as intuitive as is possibly can be. Go to File -> Import Geometry, browse to the appropriate model, and select Open. Once open, it is possible to both mesh the model and to create boundary conditions for it. Because BLMesher is presently the primary meshing tool, it is only necessary to use SimModeler to create boundary conditions. Go to Analysis -> Select Solver, and select phasta. After selecting phasta, the Analysis Attributes option under Analysis becomes valid. Clicking it brings up the corresponding window. From this new window, it is possible to apply all the usual boundary conditions by clicking the small button next to the drop down menu [add picture].

== Boundary conditions ==

Commonly boundary conditions include:

*comp3 - Specifies a 3D velocity vector
*comp1 - Specifies a 3D vector in which the velocity is constrained. Velocity normal to this vector is not directly affected. This is useful for creating slip walls and mimicking free stream regions.
*temperature - Sets the temperature of the wall. This is only needed for compressible cases.
*scalar_1 - Sets the scalar_1 / eddy viscosity to apply at a wall. For the Spalart Allmaras models, scalar_1 should be zero at physical walls where a boundary layer develops and 3 to 5 times the molecular viscosity at free stream boundaries (http://turbmodels.larc.nasa.gov/spalart.html)
*surf ID - Associates a number with one or more faces. This can then be read by Phasta and used to apply more complicated boundary conditions in software.
*natural pressure - Apply a mean pressure over a surface. The pressure at any particular point is still allowed to vary (someone verify).
*traction vector - ??. The zero vector is typically applied at outlet.
*heat flux - Specifies the rate at which heat is injected / removed (not sure which one) into / from the fluid domain. The value is almost always set to zero to create a perfectly insulated boundary.
*scalar_1 flux - set the flux of scalar_1 / eddy viscosity into / out of the domain (not sure which one). This is typically only used at outlets where high values of eddy viscosity have been convected downstream of turbulent walls. The value is almost always set to zero.
*turbulence wall - Indicates that a surface is to be included in the calculation of d2wall files (verify) which are then used by the Spalart Allmaras turbulence model to generate more physical turbulent kinetic energy production / dissipation budgets.

SimModeler

2013-06-21T08:00:04Z

Nmati: /* Creating new files */

Debugging

2013-06-21T07:32:29Z

Nmati: /* Debugging Seg Faults */

[[Category:Software Engineering]]
== '''Introduction''' ==

Debugging can be a very difficult skill to learn. It requires patience, persistence and determination but it can certainly be aided by skills and tips gained from hard earned experience.

The goal of this wiki is to organize our groups experience with debugging in general and specific tips for debugging our software.

== '''General''' ==

There are broadly three types of bugs that we encounter: 1) wrong results, 2) segmentation fault, and 3) trapped unexpected behavior. These are ordered in decreasing difficulty as will be clear shortly.

''Wrong results:'' A lack of convergence or slow divergence of a problems that is expected or known to work with the given inputs is not uncommon for code development but it is far and away the hardest bug to find. The most effective strategy here is usually to compare against a working code that does not exhibit this behavior and be sure that all of the "deviations" from the known working code are expected.

''Segmentation fault:'' Here, there is typically a corruption of memory such as an array going out of bounds, Many of the debuggers mentioned below will stop at the location of the segmentation fault but be aware that this is not necessarily the location of the bug. In many cases, memory corruption occurred in a non-fatal way at some early stage of the code and the place the code reports the segmentation fault is were the "dead body" is found and you must look at the corrupted array and look backward to see where it was modified which may lead to other arrays that were incorrectly modified etc. This is especially true with indirect addressing arrays and memory pointers. You should expect the compiling in debug mode will "move" the problem to a different location and, sadly in some situations, completely hide the problem (e.g., runs through successfully). This is because when a code is compiled in debug mode, extra "padding" is put into the code to track the variables and you may be corrupting only this padding and not vital code. '''''[http://fluid.colorado.edu/wiki/index.php/Valgrind Valgrind]''''' (someone provide a wiki tutorial on its use please) can be very effective in finding this type of bug. This type of fault can also occur when you run out of memory for the machine you are running on. Please use '''''top''''' while your job is running to check for this type of failure.

''Trapped unexpected behavior:'' Here checks were placed in the code to stop or report some information when execution led to an unexpected result (e.g., a negative volume computation or a residual that is not a number). In general we like to put these kind of things in our code to make debugging easier but there is always a tradeoff between the time it takes to instrument the code, the effect the checks have on performance, and the benefit to debugging. One compromise that is often employed is to put these checks inside of a compiler flag so that they are compiled in ONLY when running in debug mode. '''MAJOR TIP: When a code crashes ALWAYS recompile it in debug mode and rerun it as you may then get more information about where the bug is (e.g., go from Seg Fault to Trapped unexpected behavior).'''

== '''Choice of Debugger''' ==

The first choice is what tool to debug with. Your weapons range from graphical debuggers like '''''totalview''''' and '''''idb''''', to command line debuggers like '''''gdb''''', to print statements. Different bugs/codes are handled best by different tools.
Launching and effectively getting help and/or running graphical debuggers are covered in separate wikis linked to the names in the list. Here we only give a general overview of some experience (grow it!!) with each.

''Graphical debuggers'' are best for marching through the code. They can really help a new user learn the flow of the code and see various arrays being changed. Any code that you want to have mastery of is worth spending time marching through the code in this way. Graphical debuggers are also effective at determining the location of bugs.

''Command line debuggers'' link to gdb....some comments on when they are effective

''Print statements'' When you don't have effective access to the two above, inserting print statements can be an effective way of finding a bug. It is more effective the more you know about your bug (e.g., when you know pretty close to where in the code the problem is and what variable is going bad). Included in this category is writing out entire fields in a format that our post-processors can read so that you can look at the whole field in something like '''''paraview''''' that may give you a clue as to where the problem of the category "Wrong results" might be occurring.

== '''Debugging Strategies''' ==

''Recursive bisection:'' When you know where the code fails (or is producing wrong results) but don't have much of a clue where and why, this can be a good strategy. What you need is some measure of correctness of some variable you can watch. Your strategy here is to first define the location in the code where it is believed to be correct and a second location where it is believed to be wrong. Then you bisect the code and check the middle location and determine if it is correct or wrong and then replace either the first or second location based on your answer (replace correct or wrong). Keep applying this recursively and eventually you have a small section of code to find your bug in (e.g., one line). This works extremely well for some bugs but it does have a few difficult assumptions that don't always hold true: 1) you know what is correct and wrong, 2) you know how to bisect your code (this can be hard before you actually know the code you are working with pretty well), 3) you are able to track a single variable through a function stack (not always possible) and/or know the code well enough to switch targets (and adjust measure of correctness).

''March (and compare):'' Marching in a debugger is tedious and many think it is boring but if you get your mind in the right place you can learn a lot about the code while you are marching (tell yourself you are not wasting time finding a bug but using the debugger to better learn the code). As above, this strategy is more effective the better you know how to differentiate a correct result from and incorrect result on each "line" of the code, something that experience improves. This is where "compare" is a powerful tool for beginners (and everyone else). Your ideal scenario is that you have a version of the code saved that was working when you started your development. Before you start, make that working source code directory not writable ( chmod u-w * ). You then make two directories with your inputs and launch two versions of the debugger in each of these directories, one with the correct executable and one with the broken executable. You then march through the code looking for differences. Of course if you meet the requirements of Recursive bisection you can apply it to both codes and combine these strategies but when you don't, marching line by line and comparing results can often be effective (and you will in the process learn the code well AND likely develop the understanding of correctness required to use recursive bisection).

''Specific tips for SCOREC/Simmetrix Meshing and MeshAdapt software and associated databases:''
Because the mesh database is very rich and complex it can often be non-transparent to debugging. To address this issues, functions have been created to help users debug. If your debugging has identified a location and you have successfully trapped the offending vertex, face, or region (typically you are iterating over one of these when some unexpected result occurs and is trapped), then you can call a function to get lots of information about that entity with

V_info(ivert) // gives information about the the vertex ivert
F_info(iface) // gives information about the the face iface
R_info(iregion) // gives information about the the region iregion

These functions can either be compiled into the code and printed from traps that catch the unexpected behavior (and thereby help you understand the geometric location of the problem) or, with many debuggers, they can be called from the current command line to give you more information while stepping through the code.

Once you find the offending geometric location, it is often possible to load the mesh (in cases where the mesher completed but some other program downstream of it fails) in paraview and draw spheres at the location of the vertices, zoom to the vertices, cut the mesh with'' extract cells by region'' filter centered on the bad location and then see what is wrong (perhaps using a few different normal planes to get a clear view). Often refining the mesh near this surface will improve element quality and fix the problem.

ADD TO ME

''Specific tips for PHASTA:''
ADD TO ME

== '''Debugging in parallel with GDB''' ==

A useful command to debug a parallel job running with a low number of processes on the viz nodes at Colorado is the following:

mpirun -np <np> gnome-terminal --disable-factory -e 'gdb <exec name>'

This will open a terminal running gdb for every process of your application. You can then execute in every terminal the usual gdb commands.

In particular, for PHASTA, you can also type in your terminal

set catchDebugger=1
mpirun -np <np> <phasta exec name>

No need in this case to specify any additional arguments to the mpi command. it will launch debug windows automatically for you. Every instance of PHASTA gets trapped in an infinite loop in common/phasta.cc (see routine catchDebugger()). To release PHASTA, you need for every process to pause the execution and then

gdb> set debuggerPresent=1

for every process/terminal.

== Debugging Seg Faults ==
Reading core files generated after a seg fault can be done with GDB using the command

gdb <phasta exec name> <path to core file>

From here, there are a number of options including "disas" which shows the disassembly of the function where the seg fault occurred. Alternatively, it can be rather convenient to view the disassembly in vim or a vim like editor:

objdump -D <phasta exec name> | vim -

Debugging

2013-06-21T07:31:46Z

Nmati: /* Debugging in parallel with GDB */

[[Category:Software Engineering]]
== '''Introduction''' ==

Debugging can be a very difficult skill to learn. It requires patience, persistence and determination but it can certainly be aided by skills and tips gained from hard earned experience.

The goal of this wiki is to organize our groups experience with debugging in general and specific tips for debugging our software.

== '''General''' ==

There are broadly three types of bugs that we encounter: 1) wrong results, 2) segmentation fault, and 3) trapped unexpected behavior. These are ordered in decreasing difficulty as will be clear shortly.

''Wrong results:'' A lack of convergence or slow divergence of a problems that is expected or known to work with the given inputs is not uncommon for code development but it is far and away the hardest bug to find. The most effective strategy here is usually to compare against a working code that does not exhibit this behavior and be sure that all of the "deviations" from the known working code are expected.

''Segmentation fault:'' Here, there is typically a corruption of memory such as an array going out of bounds, Many of the debuggers mentioned below will stop at the location of the segmentation fault but be aware that this is not necessarily the location of the bug. In many cases, memory corruption occurred in a non-fatal way at some early stage of the code and the place the code reports the segmentation fault is were the "dead body" is found and you must look at the corrupted array and look backward to see where it was modified which may lead to other arrays that were incorrectly modified etc. This is especially true with indirect addressing arrays and memory pointers. You should expect the compiling in debug mode will "move" the problem to a different location and, sadly in some situations, completely hide the problem (e.g., runs through successfully). This is because when a code is compiled in debug mode, extra "padding" is put into the code to track the variables and you may be corrupting only this padding and not vital code. '''''[http://fluid.colorado.edu/wiki/index.php/Valgrind Valgrind]''''' (someone provide a wiki tutorial on its use please) can be very effective in finding this type of bug. This type of fault can also occur when you run out of memory for the machine you are running on. Please use '''''top''''' while your job is running to check for this type of failure.

''Trapped unexpected behavior:'' Here checks were placed in the code to stop or report some information when execution led to an unexpected result (e.g., a negative volume computation or a residual that is not a number). In general we like to put these kind of things in our code to make debugging easier but there is always a tradeoff between the time it takes to instrument the code, the effect the checks have on performance, and the benefit to debugging. One compromise that is often employed is to put these checks inside of a compiler flag so that they are compiled in ONLY when running in debug mode. '''MAJOR TIP: When a code crashes ALWAYS recompile it in debug mode and rerun it as you may then get more information about where the bug is (e.g., go from Seg Fault to Trapped unexpected behavior).'''

== '''Choice of Debugger''' ==

The first choice is what tool to debug with. Your weapons range from graphical debuggers like '''''totalview''''' and '''''idb''''', to command line debuggers like '''''gdb''''', to print statements. Different bugs/codes are handled best by different tools.
Launching and effectively getting help and/or running graphical debuggers are covered in separate wikis linked to the names in the list. Here we only give a general overview of some experience (grow it!!) with each.

''Graphical debuggers'' are best for marching through the code. They can really help a new user learn the flow of the code and see various arrays being changed. Any code that you want to have mastery of is worth spending time marching through the code in this way. Graphical debuggers are also effective at determining the location of bugs.

''Command line debuggers'' link to gdb....some comments on when they are effective

''Print statements'' When you don't have effective access to the two above, inserting print statements can be an effective way of finding a bug. It is more effective the more you know about your bug (e.g., when you know pretty close to where in the code the problem is and what variable is going bad). Included in this category is writing out entire fields in a format that our post-processors can read so that you can look at the whole field in something like '''''paraview''''' that may give you a clue as to where the problem of the category "Wrong results" might be occurring.

== '''Debugging Strategies''' ==

''Recursive bisection:'' When you know where the code fails (or is producing wrong results) but don't have much of a clue where and why, this can be a good strategy. What you need is some measure of correctness of some variable you can watch. Your strategy here is to first define the location in the code where it is believed to be correct and a second location where it is believed to be wrong. Then you bisect the code and check the middle location and determine if it is correct or wrong and then replace either the first or second location based on your answer (replace correct or wrong). Keep applying this recursively and eventually you have a small section of code to find your bug in (e.g., one line). This works extremely well for some bugs but it does have a few difficult assumptions that don't always hold true: 1) you know what is correct and wrong, 2) you know how to bisect your code (this can be hard before you actually know the code you are working with pretty well), 3) you are able to track a single variable through a function stack (not always possible) and/or know the code well enough to switch targets (and adjust measure of correctness).

''March (and compare):'' Marching in a debugger is tedious and many think it is boring but if you get your mind in the right place you can learn a lot about the code while you are marching (tell yourself you are not wasting time finding a bug but using the debugger to better learn the code). As above, this strategy is more effective the better you know how to differentiate a correct result from and incorrect result on each "line" of the code, something that experience improves. This is where "compare" is a powerful tool for beginners (and everyone else). Your ideal scenario is that you have a version of the code saved that was working when you started your development. Before you start, make that working source code directory not writable ( chmod u-w * ). You then make two directories with your inputs and launch two versions of the debugger in each of these directories, one with the correct executable and one with the broken executable. You then march through the code looking for differences. Of course if you meet the requirements of Recursive bisection you can apply it to both codes and combine these strategies but when you don't, marching line by line and comparing results can often be effective (and you will in the process learn the code well AND likely develop the understanding of correctness required to use recursive bisection).

''Specific tips for SCOREC/Simmetrix Meshing and MeshAdapt software and associated databases:''
Because the mesh database is very rich and complex it can often be non-transparent to debugging. To address this issues, functions have been created to help users debug. If your debugging has identified a location and you have successfully trapped the offending vertex, face, or region (typically you are iterating over one of these when some unexpected result occurs and is trapped), then you can call a function to get lots of information about that entity with

V_info(ivert) // gives information about the the vertex ivert
F_info(iface) // gives information about the the face iface
R_info(iregion) // gives information about the the region iregion

These functions can either be compiled into the code and printed from traps that catch the unexpected behavior (and thereby help you understand the geometric location of the problem) or, with many debuggers, they can be called from the current command line to give you more information while stepping through the code.

Once you find the offending geometric location, it is often possible to load the mesh (in cases where the mesher completed but some other program downstream of it fails) in paraview and draw spheres at the location of the vertices, zoom to the vertices, cut the mesh with'' extract cells by region'' filter centered on the bad location and then see what is wrong (perhaps using a few different normal planes to get a clear view). Often refining the mesh near this surface will improve element quality and fix the problem.

ADD TO ME

''Specific tips for PHASTA:''
ADD TO ME

== '''Debugging in parallel with GDB''' ==

A useful command to debug a parallel job running with a low number of processes on the viz nodes at Colorado is the following:

mpirun -np <np> gnome-terminal --disable-factory -e 'gdb <exec name>'

This will open a terminal running gdb for every process of your application. You can then execute in every terminal the usual gdb commands.

In particular, for PHASTA, you can also type in your terminal

set catchDebugger=1
mpirun -np <np> <phasta exec name>

No need in this case to specify any additional arguments to the mpi command. it will launch debug windows automatically for you. Every instance of PHASTA gets trapped in an infinite loop in common/phasta.cc (see routine catchDebugger()). To release PHASTA, you need for every process to pause the execution and then

gdb> set debuggerPresent=1

for every process/terminal.

== Debugging Seg Faults ==
Reading core files generated after a seg fault can be done with gdb using the command

gdb <phasta exec name> <path to core file>

From here, there are a number of options including "disas" which shows the disassembly of the function where the seg fault occurred. Alternatively, it can be rather convenient to view the disassembly in vim or a vim like editor:

objdump -D <phasta exec name> | vim -

PHASTA/Probe points

2013-06-21T01:08:15Z

Nmati: /* Location in Phasta */

Phasta is capable of outputting solution field variables such as velocity, pressure, eddy viscosity, and temperature (if applicable) at specified locations in the fluid domain.

== Using Probe Points ==

To enable probe points, the file xyzts.dat and the folder varts/ must both be present in the n-procs_case directory that is being used by Phasta. The file xyzts.dat should contain a one line, space delineated header with the following numeric data

*number of probes
*frequency (i.e. the number of steps between sampling)
*tolerance
*iterate (does not appear to do anything)
*number of field variables (e.g. 5 for incompressible with one equation turbulence model and 6 for compressible with a one equation turbulence model)

The lines following the header should contain x, y, z data specifying the location of the probe points. As an example, a valid xyzts.dat file for an incompressible run would look something like:

4 1 1.0e-6 1 5
0.2 -0.02 -0.01
0.2 -0.02 0.01
0.3 -0.02 -0.01
0.3 -0.02 0.01

For multiple cases which use the same probe locations, it is often convenient to keep xyzts.dat in a lower level directory and soft link to it. That is, the setup process becomes
cd n-procs_case
mkdir varts
ln -s ../../xyzts.dat .

Note: in most versions of Phasta, the varts.*.sn files are created prior to the calculation of the first time step, but are actually written to ''after'' finishing the last time step. This means that if a run is interrupted (e.g. by not requesting enough time in a queue), no useful data will be generated.

== Location in Phasta ==

In the compressible version of Phasta, xyzts.dat appears to be read exclusively in
phSolver/compressible/itrdrv.f.

At least in the NGC version of the code (as of 2013-06-13), the fifth input is unused

Being Written

Janus Cheat Sheet

2013-06-18T22:41:57Z

Nmati: /* Debugging PHASTA */

== Login ==
ssh your_identikey_user@login.rc.colorado.edu
[pin][token]

== Running Jobs ==
Environment Setup:
use Torque
use Moab
use Git
use .openmpi-1.4.3_intel-12.0_ib
use Graphviz
use Subversion

Viewing the list of dotkit modules (software) that you have loaded
echo $_dk_inuse
available nodes/cores:

pbsnodes -a
showbf
Jobscript Template:

#!/bin/bash
#PBS -N name_of_job
#PBS -l walltime=0:20:00
#PBS -l nodes=1:ppn=12
. /curc/tools/utils/dkinit
reuse .openmpi-1.4.3_intel-12.0_ib

mpirun /path/to/executable

Submission:

qsub -q janus-debug jobscript.sh

Status

checkjob job_id
showq -u $USER

Cancel:

qdel job_id

Large Memory, Interactive:

qsub -I -l nodes=1:ppn=32,walltime=1:00:00 -q himem

Interactive, for debugging (with totalviewer)

ssh -Y "user_id"@janus.rc.colorado.edu

qsub -I -X -l nodes=1:ppn=12,walltime=1:00:00 -q janus-debug

Non Default allocation:

qsub -A UCBXXXXXXX job.sh

or in the job script:
#PBS -A UCBXXXXXXX

== Debugging PHASTA ==
If you are getting hanging codes or crashing codes, compile with the pgi compilers and try the following flags on C, C++ and Fortran:

-Ktrap=fp -Mbounds -Kieee

For PHASTA with cmake, you need to:

CC=pgcc CXX=pgCC FC=pgfortran ccmake ../phasta

Then, add the compilation flags above to the following variables:

CMAKE_CXX_FLAGS and CMAKE_C_FLAGS and CMAKE_Fortran_FLAGS variables

Basically this will make your code crash where you get floating point exceptions, go out of bounds with arrays, or have ieee exceptions. Then if you type

set catchDebugger=1

and then

mpirun <exec>

it will launch debug windows which when you release them will stop at the point of your "foul" which REALLY helps.
More info: http://www.pgroup.com/userforum/viewtopic.php?t=1898&postdays=0&postorder=asc&start=0&sid=719a9d9871bf16add8565a398ba548f3

== Allocation Status ==
use Crc-allocations
check_allocation.py
use Moab
showstats -u $USER

==[[GridFTP]]==
export MYPROXY_SERVER_DN=$MYPROXY_SERVER_DN"/C=US/O=Globus Consortium/OU=Globus Connect Service/CN=842a610a-4de7-11e1-9674-123138151443"
myproxy-logon -T -b -s gridftp-00.rc.colorado.edu -v -l bema1643

globus-url-copy -v -r -cd -rst -rst-retries 0 -fast -vb -p 64 -stripe -tcp-bs 4M -g2 -ss '/C=US/O=Globus Consortium/OU=Globus Connect Service/CN=842a610a-4de7-11e1-9674-123138151443' gsiftp://gridftp-00.rc.colorado.edu/lustre/janus_scratch/bema1643/test.img sshftp://matthb2@jumpgate-phasta.colorado.edu/scratch/matthb2/foo/

globus-url-copy -v -r -cd -rst -rst-retries 0 -fast -vb -p 64 -stripe -tcp-bs 4M -g2 -ds '/C=US/O=Globus Consortium/OU=Globus Connect Service/CN=842a610a-4de7-11e1-9674-123138151443' sshftp://matthb2@jumpgate-phasta.colorado.edu/scratch/mrasquin/416M/ gsiftp://gridftp-00.rc.colorado.edu/lustre/janus_scratch/bema1643/

(note: -ss to specify that the source server has a non-standard DN, -ds for the destination)

==Queues/Policy==
https://www.rc.colorado.edu/crcdocs/queues
https://www.rc.colorado.edu/policies/janus-jobs

PHASTA/Probe points

2013-06-13T19:46:56Z

Nmati: /* Using Probe Points */

Phasta is capable of outputting solution field variables such as velocity, pressure, eddy viscosity, and temperature (if applicable) at specified locations in the fluid domain.

== Using Probe Points ==

To enable probe points, the file xyzts.dat and the folder varts/ must both be present in the n-procs_case directory that is being used by Phasta. The file xyzts.dat should contain a one line, space delineated header with the following numeric data

*number of probes
*frequency (i.e. the number of steps between sampling)
*tolerance
*iterate (does not appear to do anything)
*number of field variables (e.g. 5 for incompressible with one equation turbulence model and 6 for compressible with a one equation turbulence model)

The lines following the header should contain x, y, z data specifying the location of the probe points. As an example, a valid xyzts.dat file for an incompressible run would look something like:

4 1 1.0e-6 1 5
0.2 -0.02 -0.01
0.2 -0.02 0.01
0.3 -0.02 -0.01
0.3 -0.02 0.01

For multiple cases which use the same probe locations, it is often convenient to keep xyzts.dat in a lower level directory and soft link to it. That is, the setup process becomes
cd n-procs_case
mkdir varts
ln -s ../../xyzts.dat .

Note: in most versions of Phasta, the varts.*.sn files are created prior to the calculation of the first time step, but are actually written to ''after'' finishing the last time step. This means that if a run is interrupted (e.g. by not requesting enough time in a queue), no useful data will be generated.

== Location in Phasta ==

In the compressible version of Phasta, xyzts.dat appears to be read exclusively in
phSolver/compressible/itrdrv.f.

PHASTA/Probe points

2013-06-13T19:44:08Z

Nmati: /* Location in Phasta */

Phasta is capable of outputting solution field variables such as velocity, pressure, eddy viscosity, and temperature (if applicable) at specified locations in the fluid domain.

== Using Probe Points ==

To enable probe points, the file xyzts.dat and the folder varts/ must both be present in the n-procs_case directory that is being used by Phasta. The file xyzts.dat should contain a one line, space delineated header with the following numeric data

*number of probes
*frequency (i.e. the number of steps between sampling)
*tolerance
*iterate (does not appear to do anything)
*number of field variables (e.g. 5 for incompressible with one equation turbulence model and 6 for compressible with a one equation turbulence model)

The lines following the header should contain x, y, z data specifying the location of the probe points. As an example, a valid xyzts.dat file for an incompressible run would look something like:

4 1 1.0e-6 1 5
0.2 -0.02 -0.01
0.2 -0.02 0.01
0.3 -0.02 -0.01
0.3 -0.02 0.01

Note: in most versions of Phasta, the varts.*.sn files are created prior to the calculation of the first time step, but are actually written to ''after'' finishing the last time step. This means that if a run is interrupted (e.g. by not requesting enough time in a queue), no useful data will be generated.

== Location in Phasta ==

In the compressible version of Phasta, xyzts.dat appears to be read exclusively in
phSolver/compressible/itrdrv.f.

PHASTA/Probe points

2013-06-13T19:43:43Z

Nmati:

Phasta is capable of outputting solution field variables such as velocity, pressure, eddy viscosity, and temperature (if applicable) at specified locations in the fluid domain.

== Using Probe Points ==

To enable probe points, the file xyzts.dat and the folder varts/ must both be present in the n-procs_case directory that is being used by Phasta. The file xyzts.dat should contain a one line, space delineated header with the following numeric data

*number of probes
*frequency (i.e. the number of steps between sampling)
*tolerance
*iterate (does not appear to do anything)
*number of field variables (e.g. 5 for incompressible with one equation turbulence model and 6 for compressible with a one equation turbulence model)

The lines following the header should contain x, y, z data specifying the location of the probe points. As an example, a valid xyzts.dat file for an incompressible run would look something like:

4 1 1.0e-6 1 5
0.2 -0.02 -0.01
0.2 -0.02 0.01
0.3 -0.02 -0.01
0.3 -0.02 0.01

Note: in most versions of Phasta, the varts.*.sn files are created prior to the calculation of the first time step, but are actually written to ''after'' finishing the last time step. This means that if a run is interrupted (e.g. by not requesting enough time in a queue), no useful data will be generated.

== Location in Phasta ==

In the compressible version of Phasta, xyzts.dat appears to be read exclusively in phSolver/compressible/itrdrv.f.

PHASTA/Probe points

2013-06-13T19:39:24Z

Nmati: /* Using Probe Points */

PHASTA/Probe points

2013-06-13T19:34:58Z

Nmati: Created page with "Phasta is capable of outputting solution field variables such as velocity, pressure, eddy viscosity, and temperature (if applicable) at specified locations in the fluid domain. ..."