SimModeler

2014-04-22T00:05:42Z

Mkm06: /* Creating new files */

[[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 boundary conditions and initial 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.

Getting Started with PHASTA

2014-04-21T21:09:17Z

Mkm06: /* Setting up a problem */

Getting Started with PHASTA

2014-04-15T06:31:48Z

Mkm06:

Getting Started with PHASTA

2014-04-11T23:08:46Z

Mkm06:

2013-08-21T21:45:43Z

2012-08-22T18:26:24Z

Mkm06:

SimModeler

2012-08-08T19:15:31Z

Mkm06:

SimModeler

2012-08-08T18:45:45Z

Mkm06:

[[Category:Software]]

== Introduction ==
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

SimModeler

2012-08-08T18:16:34Z

Mkm06: Created page with "== Introduction == 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 Si..."

== Introduction ==
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).

Debugging

2011-08-24T20:09:44Z

Mkm06: /* General */

== '''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

2011-08-24T20:08:50Z

Mkm06: /* General */

== '''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 their 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

VNC

2011-08-23T03:54:23Z

Mkm06: /* Windows */

VNC is a tool which projects a GUI session over the network. If may be useful if you want to use GUI tools remotely when X forwarding performs poorly.

'''Warning: This is still being tested and should NOT be considered stable (portal0 may be rebooted without warning)'''
'''Warning: The vnc password is transmitted in clear text over the network and should not be considered secure'''

Portal0 is designated to host VNC sessions.

You can start a session as follows:

ssh jumpgate-phasta.colorado.edu
ssh portal0
source /etc/profile
start_vnc.sh

And follow the directions

(You may want to remember your password and port number so that you can reuse your session)

When you are done, end your session by
source /etc/profile
stop_vnc.sh

== OpenGL ==

Portal0 is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)

Simply wrap your OpenGL program with the "vglrun" command
vlgrun glxgears

If you have access to another VirtualGL server you can connect to it first (Portal0 doesn't have a particularly fast graphics processor)
vglconnect server
vglrun glxgears

Note that VGL uses a number of threads. If you have trouble with vglrun crashing with a message about Thread::Start() make sure you haven't set your stack size too large (remove any ulimit -s or ulimit -n calls from your shell start scripts)

== Clients ==

Portal0 uses TurboVNC from the VirtualGL project, available from http://www.virtualgl.org/Downloads/TurboVNC

Other VNC viewers will also work, such as TightVNC and RealVNC

== View Only Mode ==

To share your desktop with another user in view only mode set a view only password
by running
vncpasswd

Have the other user connect in the same way you would but have them set their viewer to be in view only mode and use your view only password. Typically this is done as follows:
vncviewer -viewonly

== Windows ==
The PuTTY SSH client can handle ssh tunneling on Windows based machines. You can download it here: http://www.chiark.greenend.org.uk/~sgtatham/putty/

When you open putty, enter jumpgate-phasta.colorado.edu as in the Host Name box. Then click the + button next to SSH on the left pane (to expand the SSH tree node). Choose the Tunnels page. The start_vnc.sh script should tell you to run "ssh -L????:portal0:???? jumpgate-phasta.colorado.edu" on your machine. Enter the number between the -L and the first colon in the "Source port" box. Enter the rest in the Destination box (starting with portal0) and '''click the add button'''. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.

Example:

The script says:
ssh -L5905:portal0:5900 jumpgate-phasta.colorado.edu
enter 5905 in the Source port box
enter portal0:5900 in the destination box.

Try using this viewer utility
http://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_x86_viewer.zip

== Web Based Viewer ==

If you can't or don't want to install a VNC viewer you can use a Java based one. You will need a JVM and a Java browser plugin. You will also need the port that the start_vnc script assigned you to be free on your local computer

Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to

ssh -L5905:portal0:5902 jumpgate-phasta.colorado.edu you should
ssh -L5902:portal0:5902 -L5802:portal0:5802 jumpgate-phasta.colorado.edu
Then point your browser to http://localhost:5802 and log in with the password specified by the script when prompted. (Replace 2 with the value specified by the script)

== Changing the Size (Resolution) of an Existing Session ==

You can usually use the "xrandr" tool to change the resolution of a running vnc session. First you'll need to know your session's display number (this should be the last digit or two of the port number). For example, if your VNC session is running on port 5902, then your screen number should be :2. For this example, we'll use screen 2.

Once you know your screen number, you can see the list of supported modes as follows:
xrandr -display :2

Once you pick the one you want (generally the same size or smaller than the native resolution of your client), you can choose it by running a command like
xrandr -s 1400x1050 -display :2

(this example will set the resolution to 1400 pixels by 1050 pixels)

You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs).

== Troubleshooting ==

If you have used vncserver (It doesn't matter which version) on a SCOREC machine before, you will need to clear your vnc settings for the script to work. You can do this by running rm -rf ~/.vnc

stop_vnc.sh may display some errors; this is normal.

If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu

If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)

VirtualGL has trouble with some threaded programs. If your OpenGL program exhibits segmentation faults or other issues, this could be the problem. Check back for the solution later.

If the given password is rejected you can run stop_vnc.sh and restart to get a new one. Occasionally the random password generator may generate passwords which VNC doesn't like.

If VirtualGL complains about not being able to get a 24bit FB config either vglconnect to another VirtualGL enabled server or complain to Benjamin.A.Matthews@Colorado.edu

If your VNC connection is very slow, you might want to try changing the compression and encoding options. See your vncviewer's documentation or try this
vncviewer -encodings tight -quality 6 -compresslevel 6
If you have trouble with text distortion try adding
-nojpeg