https://fluid.colorado.edu/wiki/api.php?action=feedcontributions&feedformat=atom&user=KjansenPHASTA Wiki - User contributions [en]2026-04-26T06:49:28ZUser contributionsMediaWiki 1.30.0https://fluid.colorado.edu/wiki/index.php?title=Interpolate_Solution_from_Different_Mesh&diff=2106Interpolate Solution from Different Mesh2025-03-29T17:12:56Z<p>Kjansen: /* Alternative to Using MATLAB for Reformatting */</p>
<hr />
<div>This will be a general page for how to interpolate solutions from different meshes onto a new mesh. <br />
Those meshes are assumed to be of the same domain. <br />
<br />
The generic terms for the two meshes are "source" and "target", where source has the desired solution data and target is the mesh that will be receiving. <br />
<br />
== Laminar, Incompressible, Semi-structured Mesh ==<br />
This section will assume that the source mesh is in a structured ijk form. In the future, this may be expanded to meshes created by MGEN.<br />
<br />
=== Process Overview ===<br />
<br />
# A CSV of the solution must be created. This must be done on a serial running version of ParaView '''and''' must be done after a MergeBlocks filter is done.<br />
# A special solution file is created via <code>Sort2StructuredGrid</code>, which will take in the csv from step 1 and the ordered coordinates of the source file from Matlab. <br />
#* Effectively, it creates a single solution file in the same ordering as the Matlab points. The importance of this is significant as the executable used in the next step depends on some expected ordering. If the ordering is different, a new executable will need to be used/created. <br />
# The interpolation is performed onto the new grid via <code>par3DInterp3</code>, which creates <code>solInterp.<1-nparts></code> files in the <code>solnTarget</code> directory.<br />
# The interpolation is then used by PHASTA by setting <code>Load and set 3D IC: True</code> in the <code>solver.inp</code>. <br />
#*This should only be done for 1 timestep, as it will continue to reset the IC for all proceeding timesteps. The <code>solnTarget</code> directory needs to be symlinked into the <code>-procs_case</code> directory for this to work.<br />
<br />
==== 1. Create CSV ====<br />
<br />
* Created using ParaView<br />
* PV must be running in Serial mode<br />
** Otherwise the CSV will not be in the correct order and possibly have duplicated points<br />
# Load in source dataset<br />
# Apply Mergeblocks filter<br />
# Save dataset as a csv with 12 digits of precision in scientific notation<br />
#* Make sure the csv is in "pressure, u0, u1, u2, x0, x1, x2" format<br />
#* This can be done by only loading the pressure and velocity fields into Paraview (either by editing the <code>.phts</code> or in the data load menu in Paraview).<br />
# Replace the commas with spaces<br />
#* Can use <code>vim</code> or run <code>sed -i 's/,/\ /g' test.csv</code><br />
#* Though the next step looks for a .csv extension, it is a fortran formatted read and actually needs those commas replaced by spaces<br />
# Remove the first line of the csv file<br />
#* Done in vi or sed (<code>sed -i 1,1d test.csv</code>) or tail (<code>tail -n +2 test.csv > trimmedLine1.csv</code>) <br />
#* Needed for the next program<br />
#* Better yet, we should change the next code to read past that header line and then delete this line when that is complete. We should also consider the solution in [https://stackoverflow.com/a/46451049/7564988 this StackOverflow answer] as it shows how to make a data structure that could read the csv lines directly in the next program and avoid ALL this file manipulation with modern fortran (see HighPerformanceMark's answer).<br />
<br />
==== 2. Create Structured Solution File ====<br />
<br />
'''Note:''' These instructions will be for the <code>parallelSortDNSzBinJames</code> executable, which has some highly specific requirements and command inputs. <br />
<br />
This step will take the data from the source solution file and put it in an format/order that will make the interpolation process work much faster.<br />
<br />
# Symlink the source mesh's ordered coordinate file as <code>ordered.crd</code><br />
#* This may come from the files used to create the mesh (ie. for [[Tutorial_Video_Overviews#MatLabMeshAndConvert.mov|matchedNodeElementReader]])<br />
#* ''(Untested)''This may also be created using the coordinates from the solution file<br />
# Rename/symlink csv to be the correct file name (in my specific case, it was <code>dnsSolution1procLongFort.csv</code>)<br />
# Create an interactive job on whatever machine you're needing to run on (ALCF Cooley in this case)<br />
# Load approriate MPI environment variables (<code>soft add +mvapich2</code> for Cooley)<br />
# Run the executable via <code>mpirun -np [nprocs] [executable path] [executable inputs]</code> <br />
#* This will produce <code>source.sln.{1..nprocs}</code> files<br />
# Concatenate <code>source.sln.{1..nprocs}</code> files '''in order''' into single <code>source.sln</code> file<br />
#* The individual <code>source.sln.{1..nprocs}</code> files need to be concatenated into a single <code>solution.sln</code> file, which can be done (in zsh at least) via <code>echo source.sln.{1..[MPIRanks]}| xargs cat > source.sln</code> (or probably equivalent <code>cat source.sln.{1..[MPIRanks]} > source.sln</code>). Note these files '''must''' be concatenated in order of rank, otherwise it will be out of sequence.<br />
<br />
'''Example Command:''' <code>mpirun -np 24 /lus/theta-fs0/projects/PHASTA_aesp/Utilities/Sort2StructuredGrid/parallelSortDNSzBinJames 47822547 47822547 212 0.0291</code><br />
<br />
* The inputs for this command are <code>[nlines of csv] [nlines of ordered.crd] [number of element in z] [z domain width]</code><br />
* '''Note:''' These inputs are specfic to this executable. Changing executable will change which is used<br />
* Also note that the <code>[number of elements in z]</code> is equivalent to <code>nsons</code> - 1 or the number of nodes in z - 1.<br />
<br />
==== 3. Create Interpolated files ====<br />
<br />
This step will create the <code>solInterp.[target nprocs]</code> files used by PHASTA to perform the interpolation.<br />
<br />
# Create <code>Interpolate.../[target nprocs]-procs_case</code> directory in the target's Chef directory and move to that directory<br />
# Symlink the target's POSIX <code>geombc.[target nprocs]</code> files (that were created by Chef) to the <code>[target nprocs]-procs_case</code> directory<br />
#* The <code>geombc.[target nprocs]</code> files should be copied in the exact fashion that they are in the Chef created <code>[target nprocs]-procs_case</code> directory, including if they're "fanned out"<br />
# Create a directory called <code>solnTarget</code><br />
#* This may be corrected in the future, but currently if <code>solnTarget</code> is not present the job will fail<br />
# Symlink the <code>source.sln</code> to the directory and the <code>ordered.crd</code> file as <code>source.crd</code><br />
# Run <code>phInterp</code> via mpirun on an interactive job.<br />
# This creates a series of <code>solInterp.[target nprocs]</code> files in the <code>solnTarget</code> directory<br />
<br />
The file format for <code>solInterp.N</code> is quite simple. Each line corresponds to the node number in the partition and the file itself has 7 columns:<br />
<br />
coord_x coord_y coord_z pressure velocity_x velocity_y velocity_z<br />
<br />
'''Example Command:''' <code>mpirun -np 64 /path/to/phInterp 16 799 281 213 0.452</code><br />
<br />
* The inputs for this command are <code>[target parts per MPIProc] [source nx] [source ny] [source nz] [z Length]</code><br />
* Note that the number of processes given to <code>mpirun</code> times the <code>[target parts per MPIProc]</code> must be equal to the number of target partitions. In this case, the target partition was 1024, so 64*16 = 1024<br />
* The way it works is that each of the 64 MPIProcs is given 16 partitions to interpolate.<br />
<br />
==== 4. Interpolate the solution in PHASTA ====<br />
<br />
This step will take the <code>solInterp.[target nprocs]</code> files and load them as initial conditions.<br />
<br />
# Symlink the <code>solnTarget</code> directory into the <code>[target nprocs]-procs_case</code> directory. <br />
# Add/uncomment <code>Load and set 3D IC: True</code> in the <code>solver.inp</code> <br />
# Run PHASTA for a few timesteps and write out <code>restart-dat.[target nprocs]</code> files<br />
# Remove/comment out the <code>Load and set 3D IC: True</code> line from the <code>solver.inp</code><br />
# The new restart files have the interpolated solution<br />
#* Note that if you forget to remove the <code>Load and set 3D IC: True</code> statement from <code>solver.inp</code>, PHASTA will overwrite the existing solution in the restart files<br />
<br />
== Turbulent, Compressible, Unstructured Mesh ==<br />
<br />
Currently, the only version of PHASTA that is set up to handle this type of solution transfer is the <code>conrad54418/connor_primitive</code> branch (as of 6/22/22). Creating the <code>solInterp.1</code> file can be automated via a script or done manually (see below).<br />
<br />
=== Process Overview (scripted) ===<br />
<br />
Scripts have been made for use with the compressible, but not turbulent, version of the code. An example folder with the scripts included can be found at <code>/project/tutorials/ParaviewSolutionTransfer</code>. The three scripts needed are called interpolateSol.py, pvCSV2customSLN_Nproc_prim.m, and parRunAll.sh. The only script of those three you need to run is parRunAll.sh, which can be found in <code>targetFolder/solutionInterp</code>. You then need to run PHASTA via the runPhasta.sh script, which will produce a restart.1.1 file that contains the transferred solution on the new mesh. The manual section below provides insight about what the scripts are doing.<br />
<br />
=== Process Overview (manual) ===<br />
<br />
# Load existing solution into ParaView. Use the 'MergeBlocks' filter to convert to serial case.<br />
# Load the target case .pht file into ParaView<br />
# Use the 'Resample from dataset' filter and select the source (new mesh file) and target (MergeBlocks) blocks accordingly<br />
# Save the output as a .csv file. Write a single time step and select scientific notation to 12 decimals. NOTE: sometimes ParaView will make an error and write zeros where it can't quite find the closest point when doing the solution transfer. In this case, the .csv file needs to be manually edited to replace the zeros for pressure and temperature with realistic values.<br />
# The .csv file can now be reformatted and renamed with MATLAB to match the expected form of solInterp.1.<br />
# Advance PHASTA one step in serial, then convert to desired number of processors using Chef.<br />
<br />
==== Alternative to Using MATLAB for Reformatting ====<br />
<br />
For those wanting to skip the MATLAB step, <code>awk</code> can also do the necessary column manipulation.<br />
<br />
Copy your file (in case you goof up):<br />
cp PVinterp0.csv test.dat<br />
Remove the header line:<br />
sed -i 1,1d test.dat<br />
Replace the commas with spaces:<br />
sed -i 's/,/\ /g' test.dat<br />
Rearrange the columns to be what solInterp.1 wants. It is probably a good idea to do a <code>head -1 PVinterp0.csv</code> to be sure as you might have more or less fields than I did but use that header to find the column numbers (starting from 1, not 0) to write x, y, z, p, u, v, w, T, sclr. NOTE: Even with the same data files, different versions of PV will produce different ordering so '''CHECK'''.<br />
<br />
For primitive code turbulent:<br />
awk '{print $9,$10,$11,$3,$5,$6,$7,$4,$2}' test.dat > solInterp.1<br />
for entropy code laminar:<br />
awk '{print $12,$13,$14,$1,$2,$3,$4,$5,$8,$9,$10,$7,$6}' test.dat > solInterp.1<br />
for entropy code with eddy viscosity:<br />
awk '{print $13,$14,$15,$2,$3,$4,$5,$6,$9,$10,$11,$8,$7,$1}' test.dat > solInterp.1<br />
and don’t forget to put this into a directory called solnTarget (which is inside 1-procs_case) and also to turn on the flag in solver.inp <code>Load and set 3D IC: True</code> for the 1 step that Joe mentioned. Finally, if you are worried about that one step messing up your solution recent versions of the code can take<br />
iexec : 0<br />
or<br />
Number of Timesteps: 0<br />
to not take any actual steps. Note however that only very recent version of the code have the iexec conditional moved AFTER the loading of the interpolated solution but it should be pretty easy to figure out where to move that conditional. Alternatively, the second option also skips over the time stepping and writes the solution AFTER applying the boundary conditions which can be useful to see as well to confirm you have the intended BC’s set (iexec :0 won’t detect this)</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=The_On_Ramp&diff=1178The On Ramp2020-09-17T20:53:20Z<p>Kjansen: </p>
<hr />
<div>Welcome to the '''PHASTA On Ramp'''! This page is meant to organize information for getting up to speed with the overall PHASTA workflow, as well as help you up your game as a PHASTA developer.<br />
<br />
== Level 0 ==<br />
Ready to get your feet wet? Maybe you need to brush up on some fundamental skills. Level 0 provides tutorials and information on basic developer skills you will need to work with PHASTA.<br />
* [[PHASTA_Group_Machines|Logging in]]<br />
* [[VNC|Setting up your VNC]]<br />
* [[UNIX|Getting started with Linux]]<br />
* [[Git | Getting Git]]<br />
* [[Vim|Getting comfortable with Vim]]<br />
* Getting started with CMake<br />
* New to Fortran?<br />
* Working with C++.<br />
* [[Making A New Wiki | Editing this Wiki]]<br />
<br />
== Level 1 ==<br />
<br />
[[File:Picture5.png]]<br />
<br />
<br />
So you think you know how to <code>grep</code> for keywords and <code>mkdir</code> some folders? Now you're probably ready to jump into PHASTA. <br />
* [[Level 1 Model/Mesh| Model/Mesh Workflow]]<br />
* [[Level 1 Partition| Partition Workflow]]<br />
* [[Level 1 Solve| Solve Workflow]]<br />
* [[Level 1 Post-Process| Post-Process Workflow]]<br />
<br />
== Level 2 ==<br />
Now that you've plotted some "Colorful Fluid Dynamics" (CFD) you're probably interested in digging into the guts of PHASTA, and getting it running on some more interesting hardware.<br />
* [[Compiling PHASTA With CMake|Building PHASTA from scratch]] (this page is out of date)<br />
* Available linear algebra packages in PHASTA<br />
* [https://github.com/SCOREC/core/wiki/General-Build-instructions#Manual_Install Building Chef and other SCOREC core tools]<br />
<br />
== Level 3 ==<br />
ParaView isn't cutting it for your research? Now its time to start writing your own analysis code. How to do custom pre and post processing is described here, along with more complex ways of using PHASTA for interesting CFD simulations<br />
* phastaIO, the structure of geombc and restart files<br />
* MATLAB-based Analysis<br />
* STG<br />
* [[VTKpytools| Python + VTK using vtkpytools]]<br />
<br />
== Level 4 ==<br />
You're probably close to defending at this point, so before you go get that sweet industry job, you should drop some of your lofty knowledge here!</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=PHASTA_Group_Machines&diff=937PHASTA Group Machines2020-09-08T14:54:49Z<p>Kjansen: </p>
<hr />
<div>This page documents the local machines owned by the group, logging in, and two factor authentication.<br />
<br />
== Logging In ==<br />
<br />
The entry point for the group machines is <code>jumpgate</code>, which is access publicly via <code>jumpgate-phasta.colorado.edu</code>. To access the system via command line, simply run <code>ssh USERNAME@jumpgate-phasta.colorado.edu</code> if running Linux or Mac, or use PuTTY for Windows. <br />
<br />
For Linux or Mac terminals, the login process will look like the following:<br />
<br />
➜ ssh USERNAME@jumpgate-phasta.colorado.edu <br />
Password: <br />
Verification code:<br />
<br />
where the <code>Password:</code> and <code>Verification code:</code> are prompts for you to enter in your password and 2FA pass code. Note this request for a verification code will not start occurring until after you setup 2fa as noted below.<br />
<br />
Very little can/should be done on <code>jumpgate</code>. The most common use is to establish a tunnel for a VNC session. The second usage that must be done to set that up is connecting to <code>portal1</code>. This is done via <code>ssh portal1</code> while on <code>jumpgate</code>.<br />
<br />
=== Setting Up Two-Factor Authentication ===<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication (2FA). Existing users will have one week to switch over to this process. New users are expected to do this within 24 hours. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough)) or using PuTTY. All commands to be run are in <code>''italics''</code>.<br />
<br />
''ssh USERNAME@jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
Before moving forward, it is recommended that you start a second terminal connection to <code>jumpgate</code> by repeating the ssh command above. If at any point you want/need to reset, simply run <code>''rm -rf ~/.google_authenticator''</code> in that second ssh session.<br />
<br />
In your <code>jumpgate</code> terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all).<br />
<br />
Now open another terminal and log on to <code>jumpgate</code> with ssh just as we did before. Now, in addition to prompting for your ''password'', it will also prompt for a "Verification code:". In your authenticator app, find the auto-generated 6 digit code and enter it. If you've logged on successfully, then you are done. Otherwise, attempt to troubleshoot or reset the process with the fore mentioned <code>rm</code> command.<br />
<br />
=== VNC ===<br />
Most members of the group interact with these machines via a VNC, which provides an GUI interface. Setting up the VNC server is documented on the [[VNC]] page.<br />
<br />
== Machines ==<br />
<br />
=== <code>jumpgate</code> ===<br />
This is the machine that allows you to "jump" to the other machines in the local network via <code>ssh</code>. It is simply the public-facing machine and should only be used as such.<br />
<br />
=== <code>portal1</code> ===<br />
This is where most of the non-computationally intensive tasks are done, such as text editing, moving files, etc. Effectively, if it takes longer than 5 seconds to run, you should probably think about running it on one of the <code>viz*</code> nodes.<br />
<br />
=== <code>viz003</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([https://fluid.colorado.edu/wiki/index.php/Janus_Cheat_Sheet Summit],[[NAS]], [[ALCF]], etc.)<br />
<br />
=== <code>viz002</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([Summit],[[NAS]], [[ALCF]], etc.)</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=PHASTA_Group_Machines&diff=936PHASTA Group Machines2020-09-08T14:54:05Z<p>Kjansen: </p>
<hr />
<div>This page documents the local machines owned by the group, logging in, and two factor authentication.<br />
<br />
== Logging In ==<br />
<br />
The entry point for the group machines is <code>jumpgate</code>, which is access publicly via <code>jumpgate-phasta.colorado.edu</code>. To access the system via command line, simply run <code>ssh USERNAME@jumpgate-phasta.colorado.edu</code> if running Linux or Mac, or use PuTTY for Windows. <br />
<br />
For Linux or Mac terminals, the login process will look like the following:<br />
<br />
➜ ssh USERNAME@jumpgate-phasta.colorado.edu <br />
Password: <br />
Verification code:<br />
<br />
where the <code>Password:</code> and <code>Verification code:</code> are prompts for you to enter in your password and 2FA pass code. Note this request for a verification code will not start occurring until after you setup 2fa as noted below.<br />
<br />
Very little can/should be done on <code>jumpgate</code>. The most common use is to establish a tunnel for a VNC session. The second usage that must be done to set that up is connecting to <code>portal1</code>. This is done via <code>ssh portal1</code> while on <code>jumpgate</code>.<br />
<br />
=== Setting Up Two-Factor Authentication ===<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication (2FA). Existing users will have one week to switch over to this process. New users are expected to do this within 24 hours. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough)) or using PuTTY. All commands to be run are in <code>''italics''</code>.<br />
<br />
''ssh USERNAME@jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
Before moving forward, it is recommended that you start a second terminal connection to <code>jumpgate</code> by repeating the ssh command above. If at any point you want/need to reset, simply run <code>''rm -rf ~/.google_authenticator''</code> in that second ssh session.<br />
<br />
In your <code>jumpgate</code> terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all).<br />
<br />
Now open another terminal and log on to <code>jumpgate</code> with ssh just as we did before. Now, in addition to prompting for your ''password'', it will also prompt for a "Verification code:". In your authenticator app, find the auto-generated 6 digit code and enter it. If you've logged on successfully, then you are done. Otherwise, attempt to troubleshoot or reset the process with the fore mentioned <code>rm</code> command.<br />
<br />
=== VNC ===<br />
Most members of the group interact with these machines via a VNC, which provides an GUI interface. Setting up the VNC server is documented on the [[VNC]] page.<br />
<br />
== Machines ==<br />
<br />
=== <code>jumpgate</code> ===<br />
This is the machine that allows you to "jump" to the other machines in the local network via <code>ssh</code>. It is simply the public-facing machine and should only be used as such.<br />
<br />
=== <code>portal1</code> ===<br />
This is where most of the non-computationally intensive tasks are done, such as text editing, moving files, etc. Effectively, if it takes longer than 5 seconds to run, you should probably think about running it on one of the <code>viz*</code> nodes.<br />
<br />
=== <code>viz003</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([Summit][https://fluid.colorado.edu/wiki/index.php/Janus_Cheat_Sheet Summit],[[NAS]], [[ALCF]], etc.)<br />
<br />
=== <code>viz002</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([Summit],[[NAS]], [[ALCF]], etc.)</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=PHASTA_Group_Machines&diff=935PHASTA Group Machines2020-09-08T14:48:52Z<p>Kjansen: </p>
<hr />
<div>This page documents the local machines owned by the group, logging in, and two factor authentication.<br />
<br />
== Logging In ==<br />
<br />
The entry point for the group machines is <code>jumpgate</code>, which is access publicly via <code>jumpgate-phasta.colorado.edu</code>. To access the system via command line, simply run <code>ssh USERNAME@jumpgate-phasta.colorado.edu</code> if running Linux or Mac, or use PuTTY for Windows. <br />
<br />
For Linux or Mac terminals, the login process will look like the following:<br />
<br />
➜ ssh USERNAME@jumpgate-phasta.colorado.edu <br />
Password: <br />
Verification code:<br />
<br />
where the <code>Password:</code> and <code>Verification code:</code> are prompts for you to enter in your password and 2FA pass code. Note this request for a verification code will not start occurring until after you setup 2fa as noted below.<br />
<br />
Very little can/should be done on <code>jumpgate</code>. The most common use is to establish a tunnel for a VNC session. The second usage that must be done to set that up is connecting to <code>portal1</code>. This is done via <code>ssh portal1</code> while on <code>jumpgate</code>.<br />
<br />
=== Setting Up Two-Factor Authentication ===<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication (2FA). Existing users will have one week to switch over to this process. New users are expected to do this within 24 hours. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough)) or using PuTTY. All commands to be run are in <code>''italics''</code>.<br />
<br />
''ssh USERNAME@jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
Before moving forward, it is recommended that you start a second terminal connection to <code>jumpgate</code> by repeating the ssh command above. If at any point you want/need to reset, simply run <code>''rm -rf ~/.google_authenticator''</code> in that second ssh session.<br />
<br />
In your <code>jumpgate</code> terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all).<br />
<br />
Now open another terminal and log on to <code>jumpgate</code> with ssh just as we did before. Now, in addition to prompting for your ''password'', it will also prompt for a "Verification code:". In your authenticator app, find the auto-generated 6 digit code and enter it. If you've logged on successfully, then you are done. Otherwise, attempt to troubleshoot or reset the process with the fore mentioned <code>rm</code> command.<br />
<br />
=== VNC ===<br />
Most members of the group interact with these machines via a VNC, which provides an GUI interface. Setting up the VNC server is documented on the [[VNC]] page.<br />
<br />
== Machines ==<br />
<br />
=== <code>jumpgate</code> ===<br />
This is the machine that allows you to "jump" to the other machines in the local network via <code>ssh</code>. It is simply the public-facing machine and should only be used as such.<br />
<br />
=== <code>portal1</code> ===<br />
This is where most of the non-computationally intensive tasks are done, such as text editing, moving files, etc. Effectively, if it takes longer than 5 seconds to run, you should probably think about running it on one of the <code>viz*</code> nodes.<br />
<br />
=== <code>viz003</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([[Summit]],[[NAS]], [[ALCF]], etc.)<br />
<br />
=== <code>viz002</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([Summit],[[NAS]], [[ALCF]], etc.)</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=PHASTA_Group_Machines&diff=934PHASTA Group Machines2020-09-08T14:42:35Z<p>Kjansen: </p>
<hr />
<div>This page documents the local machines owned by the group, logging in, and two factor authentication.<br />
<br />
== Logging In ==<br />
<br />
The entry point for the group machines is <code>jumpgate</code>, which is access publicly via <code>jumpgate-phasta.colorado.edu</code>. To access the system via command line, simply run <code>ssh USERNAME@jumpgate-phasta.colorado.edu</code> if running Linux or Mac, or use PuTTY for Windows. <br />
<br />
For Linux or Mac terminals, the login process will look like the following:<br />
<br />
➜ ssh USERNAME@jumpgate-phasta.colorado.edu <br />
Password: <br />
Verification code:<br />
<br />
where the <code>Password:</code> and <code>Verification code:</code> are prompts for you to enter in your password and 2FA pass code. Note this request for a verification code will not start occurring until after you setup 2fa as noted below.<br />
<br />
Very little can/should be done on <code>jumpgate</code>. The most common use is to establish a tunnel for a VNC session. The second usage that must be done to set that up is connecting to <code>portal1</code>. This is done via <code>ssh portal1</code> while on <code>jumpgate</code>.<br />
<br />
=== Setting Up Two-Factor Authentication ===<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication (2FA). Existing users will have one week to switch over to this process. New users are expected to do this within 24 hours. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough)) or using PuTTY. All commands to be run are in <code>''italics''</code>.<br />
<br />
''ssh USERNAME@jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
Before moving forward, it is recommended that you start a second terminal connection to <code>jumpgate</code> by repeating the ssh command above. If at any point you want/need to reset, simply run <code>''rm -rf ~/.google_authenticator''</code> in that second ssh session.<br />
<br />
In your <code>jumpgate</code> terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all).<br />
<br />
Now open another terminal and log on to <code>jumpgate</code> with ssh just as we did before. Now, in addition to prompting for your ''password'', it will also prompt for a "Verification code:". In your authenticator app, find the auto-generated 6 digit code and enter it. If you've logged on successfully, then you are done. Otherwise, attempt to troubleshoot or reset the process with the fore mentioned <code>rm</code> command.<br />
<br />
=== VNC ===<br />
Most members of the group interact with these machines via a VNC, which provides an GUI interface. Setting up the VNC server is documented on the [[VNC]] page.<br />
<br />
== Machines ==<br />
<br />
=== <code>jumpgate</code> ===<br />
This is the machine that allows you to "jump" to the other machines in the local network via <code>ssh</code>. It is simply the public-facing machine and should only be used as such.<br />
<br />
=== <code>portal1</code> ===<br />
This is where most of the non-computationally intensive tasks are done, such as text editing, moving files, etc. Effectively, if it takes longer than 5 seconds to run, you should probably think about running it on one of the <code>viz*</code> nodes.<br />
<br />
=== <code>viz003</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([[Summit]],[[NAS]], [[ALCF]], etc.)<br />
<br />
=== <code>viz002</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([[Summit]],[[NAS]], [[ALCF]], etc.)</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=PHASTA_Group_Machines&diff=933PHASTA Group Machines2020-09-08T14:04:09Z<p>Kjansen: </p>
<hr />
<div>This page documents the local machines owned by the group, logging in, and two factor authentication.<br />
<br />
== Logging In ==<br />
<br />
The entry point for the group machines is <code>jumpgate</code>, which is access publicly via <code>jumpgate-phasta.colorado.edu</code>. To access the system via command line, simply run <code>ssh USERNAME@jumpgate-phasta.colorado.edu</code> if running Linux or Mac, or use PuTTY for Windows. <br />
<br />
For Linux or Mac terminals, the login process will look like the following:<br />
<br />
➜ ssh USERNAME@jumpgate-phasta.colorado.edu <br />
Password: <br />
Verification code:<br />
<br />
where the <code>Password:</code> and <code>Verification code:</code> are prompts for you to enter in your password and 2FA pass code. Note this request for a verification code will not start occurring until after you setup 2fa as noted below.<br />
<br />
Very little can/should be done on <code>jumpgate</code>. The most common use is to establish a tunnel for a VNC session. The second usage that must be done to set that up is connecting to <code>portal1</code>. This is done via <code>ssh portal1</code> while on <code>jumpgate</code>.<br />
<br />
=== Setting Up Two-Factor Authentication ===<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication (2FA). Existing users will have one week to switch over to this process. New users are expected to do this within 24 hours. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough)) or using PuTTY. All commands to be run are in <code>''italics''</code>.<br />
<br />
''ssh USERNAME@jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
Before moving forward, it is recommended that you start a second terminal connection to <code>jumpgate</code> by repeating the ssh command above. If at any point you want/need to reset, simply run <code>''rm -rf ~/.google_authenticator''</code> in that second ssh session.<br />
<br />
In your <code>jumpgate</code> terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all).<br />
<br />
Now open another terminal and log on to <code>jumpgate</code> with ssh just as we did before. Now, in addition to prompting for your ''password'', it will also prompt for a "Verification code:". In your authenticator app, find the auto-generated 6 digit code and enter it. If you've logged on successfully, then you are done. Otherwise, attempt to troubleshoot or reset the process with the fore mentioned <code>rm</code> command.<br />
<br />
=== VNC ===<br />
Most members of the group interact with these machines via a VNC, which provides an GUI interface. Setting up the VNC server is documented on the [[VNC]] page.<br />
<br />
== Machines ==<br />
<br />
=== <code>jumpgate</code> ===<br />
This is the machine that allows you to "jump" to the other machines in the local network via <code>ssh</code>. It is simply the public-facing machine and should only be used as such.<br />
<br />
=== <code>portal1</code> ===<br />
This is where most of the non-computationally intensive tasks are done, such as text editing, moving files, etc. Effectively, if it takes longer than 5 seconds to run, you should probably think about running it on one of the <code>viz*</code> nodes.<br />
<br />
=== <code>viz003</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([[NAS]], [[ALCF]], etc.)<br />
<br />
=== <code>viz002</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([[NAS]], [[ALCF]], etc.)</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=PHASTA_Group_Machines&diff=932PHASTA Group Machines2020-09-08T14:02:39Z<p>Kjansen: </p>
<hr />
<div>This page documents the local machines owned by the group, logging in, and two factor authentication.<br />
<br />
== Logging In ==<br />
<br />
The entry point for the group machines is <code>jumpgate</code>, which is access publicly via <code>jumpgate-phasta.colorado.edu</code>. To access the system via command line, simply run <code>ssh USERNAME@jumpgate-phasta.colorado.edu</code> if running Linux or Mac, or use PuTTY for Windows. <br />
<br />
For Linux or Mac terminals, the login process will look like the following:<br />
<br />
➜ ssh USERNAME@jumpgate-phasta.colorado.edu <br />
Password: <br />
Verification code:<br />
<br />
where the <code>Password:</code> and <code>Verification code:</code> are prompts for you to enter in your password and 2FA pass code.<br />
<br />
Very little can/should be done on <code>jumpgate</code>. The most common use is to establish a tunnel for a VNC session. The second usage that must be done to set that up is connecting to <code>portal1</code>. This is done via <code>ssh portal1</code> while on <code>jumpgate</code>.<br />
<br />
=== Setting Up Two-Factor Authentication ===<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication (2FA). Existing users will have one week to switch over to this process. New users are expected to do this within 24 hours. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough)) or using PuTTY. All commands to be run are in <code>''italics''</code>.<br />
<br />
''ssh USERNAME@jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
Before moving forward, it is recommended that you start a second terminal connection to <code>jumpgate</code> by repeating the ssh command above. If at any point you want/need to reset, simply run <code>''rm -rf ~/.google_authenticator''</code> in that second ssh session.<br />
<br />
In your <code>jumpgate</code> terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all).<br />
<br />
Now open another terminal and log on to <code>jumpgate</code> with ssh just as we did before. Now, in addition to prompting for your ''password'', it will also prompt for a "Verification code:". In your authenticator app, find the auto-generated 6 digit code and enter it. If you've logged on successfully, then you are done. Otherwise, attempt to troubleshoot or reset the process with the fore mentioned <code>rm</code> command.<br />
<br />
=== VNC ===<br />
Most members of the group interact with these machines via a VNC, which provides an GUI interface. Setting up the VNC server is documented on the [[VNC]] page.<br />
<br />
== Machines ==<br />
<br />
=== <code>jumpgate</code> ===<br />
This is the machine that allows you to "jump" to the other machines in the local network via <code>ssh</code>. It is simply the public-facing machine and should only be used as such.<br />
<br />
=== <code>portal1</code> ===<br />
This is where most of the non-computationally intensive tasks are done, such as text editing, moving files, etc. Effectively, if it takes longer than 5 seconds to run, you should probably think about running it on one of the <code>viz*</code> nodes.<br />
<br />
=== <code>viz003</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([[NAS]], [[ALCF]], etc.)<br />
<br />
=== <code>viz002</code> ===<br />
This is where most computationally intensive tasks are done. However, they should only be run for debugging or post-processing. Production runs should be run on servers outside of the group's local machines ([[NAS]], [[ALCF]], etc.)</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=927VNC2020-09-08T00:20:55Z<p>Kjansen: </p>
<hr />
<div>'''Logging in'''<br />
<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication. Existing users will have one week to switch over to this process. New users are expected to do this within 24 hours. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough) or using Putty (see below for installing and setting up putty-- stuff you need to type will be in ''italic''):<br />
<br />
''ssh jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''username'' and ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
If you want to be safe, start a second terminal connection to jumpgate by repeating the above. In the first (or only) jumpgate terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all). If you goof this step in any way and want to start over, just go to that second window I mentioned and type ''rm -rf ~/.google_authenticator'' and start over but, more than likely, what you did is fine.<br />
<br />
The next time you log into jumpgate, it will request a verification code which your phone application will provide. Enter that codes in the terminal.<br />
<br />
<br />
'''Virtual Network Computing (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. <br />
<br />
'''Warning: The VNC password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
<code>portal1</code> is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session type the following with a return after each line:<br />
<br />
''ssh jumpgate-phasta.colorado.edu''<br />
''ssh portal1''<br />
''source /etc/profile''<br />
''start_vnc.sh''<br />
<br />
Then follow the directions from <code>start_vnc.sh</code>. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It is common practice to leave your VNC session running on <code>portal1</code>. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's VNC port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
''source /etc/profile''<br />
''stop_vnc.sh'' # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
<code>portal1</code> is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the <code>vglrun</code> command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from <code>portal1</code>. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are <code>viz002</code> and <code>viz003</code> (<code>viz001</code> is probably never coming back to life). <br />
<code>portal1</code> doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command <code>vglrun</code>. You can test that you have it setup right<br />
with the toy-app <code>glxgears</code> as follows<br />
<br />
vglrun glxgears<br />
<br />
Note that VGL uses a number of threads. If you have trouble with <code>vglrun</code> crashing with a message about <code>Thread::Start()</code> make sure you haven't set your stack size too large (remove any <code>ulimit -s</code> or <code>ulimit -n</code> calls from your shell start scripts).<br />
<br />
NOTE ALSO: The primary purpose for <code>viz003</code> is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
<code>portal1</code> uses TurboVNC from the VirtualGL project, available from [http://www.virtualgl.org/Downloads/TurboVNC their website]<br />
<br />
Other VNC viewers will also work, such as [https://www.tightvnc.com/download.php TightVNC] and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Mac or Linux ==<br />
<br />
The instructions given when you started the session on <code>portal1</code> are OK but it always tells you to start a session (in a terminal on your mac or linux machine command line)<br />
<br />
ssh -L5905:portal1:59zw jumpgate-phasta.colorado.edu<br />
<br />
where <code>zw</code> will be different for each user. That suggestion is OK if you never plan to connect to anyone else's session but since we often collaborate but sharing VNC sessions, the better practice we adopt is to use <code>zw</code> in place of the suggested 05 (which just an arbitrary local port on your laptop). So if when I created a session the last for numbers were <code>5923</code> then <code>zw</code> for me is <code>23</code> and the best practice is to ignore the script suggestion in favor of<br />
<br />
ssh -L5923:portal1:5923 jumpgate-phasta.colorado.edu<br />
<br />
== Windows == <br />
The PuTTY SSH client can handle ssh tunneling on Windows based machines. You can download it [http://www.chiark.greenend.org.uk/~sgtatham/putty/ here].<br />
<br />
When you open putty, enter <code>jumpgate-phasta.colorado.edu</code> 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 <code>start_vnc.sh</code> script should tell you to run <code>ssh -L59xy:portal1:59zw jumpgate-phasta.colorado.edu</code> on your machine. Those instructions are OK but a better practice is to ignore what that script suggested for <code>xy</code> (it always suggests 05 currently) and instead use <code>ssh -L59zw:portal1:59zw jumpgate-phasta.colorado.edu" where <code>zw</code> varies for each new session created. If you get <code>23</code> that just means there were <code>22</code> sessions created before you created this one (but the plan is for you to keep using 23 until the machine gets rebooted). Enter <code>59zw</code> in the "Source Port" box. Enter <code>portal1:59zw</code> in the "Destination" box (starting and ''click the add button''). Putty is a little strange about saving the session which you want to do to avoid having to do all the above every time you re-connect. ''BEFORE'' you click the "Open" button, you want to name your session (your choice) and click save. Then in the future when you start putty you should be able to just click that saved session name and click load. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.<br />
<br />
Example:<br />
<br />
The script says:<br />
<code>ssh -L5905:portal1:5923 jumpgate-phasta.colorado.edu</code><br />
your <code>zw</code> from the instructions above is <code>23</code><br />
enter <code>5923</code> in the "Source Port" box<br />
enter <code>portal1:5923</code> in the destination box.<br />
<br />
===Connecting to your VNC with PuTTY===<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59zw.<br />
#* To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
#* To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>USERNAME@jumpgate-phasta.colorado.edu:22</code>, where <code>USERNAME</code> is your username on <code>jumpgate</code>, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59##</code> and destination port <code>portal1:59##</code>, where <code>##</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". <br />
#* We select <code>local</code> because we have a service (VNC Server) running on a machine (<code>portal1</code>) that can be reached from the remote machine (<code>jumpgate</code>), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between <code>localhost</code> and <code>jumpgate</code>, and tunneling <code>localhost:59##</code> to <code>portal1:59##</code> via this connection.<br />
# Open RealVNC, and connect to <code>localhost:##</code>, which is shorthand for <code>localhost:59##</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>##</code> is assumed to be port <code>59##</code>.<br />
# You should now have access to your desktop on <code>portal1</code>. DON'T FORGET-- no meshing, solving, post-processing, EVEN MATLAB on <code>portal1</code>. To run memory and/or processor and/or graphics intensive jobs you need to create a terminal and type <code>vglconnect -s viz00x</code> where, at this time <code>x</code> is either 2 or 3.<br />
<br />
== Starting a VNC viewer ==<br />
<br />
Whether you followed the Mac or Linux or Windows instructions above, successful completion will have established a tunnel from your laptop to <code>portal1</code>. The last step is to start a VNC viewer (graphical windowing program) that uses this tunnel to display your <code>portal1</code> session on the screen of your laptop. There are a variety of choices for each platform and they evolve but their operation seems, thankfully, pretty universal. <br />
<br />
The most basic input is that they provide a box that says VNC server. You will want to type <code>localhost:zw</code> in that box and then apply start (or whatever the particular applications action button is). The <code>zw</code> here will need to be whatever you used after the <code>59zw:portal1</code>..... part of the tunnel. What the number is actually doing is telling this VNC viewer which port you have established a tunnel on for the session you are starting the VNC viewer for. Note it is possible to have several different simultaneous sessions. Each needs its own tunnel (established by repeating the process above with a unique <code>zw</code>) and then a corresponding "new" VNC viewer. In this way we might continue to work in our own session but then take a break to look at a collaborator's session without having to close out the tunnel and viewer pair.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
You can usually use the <code>xrandr</code> 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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs).<br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
If you have used vncserver (It doesn't matter which version) before, you will need to clear your vnc settings for the script to work. You can do this by running rm -rf ~/.vnc<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=926VNC2020-09-08T00:19:11Z<p>Kjansen: </p>
<hr />
<div>'''Logging in'''<br />
<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication. Existing users will have one week to switch over to this process. New users are expected to do this within 24 hours. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough) or using Putty (see below for installing and setting up putty-- stuff you need to type will be in ''italic''):<br />
<br />
''ssh jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''username'' and ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
If you want to be safe, start a second terminal connection to jumpgate by repeating the above. In the first (or only) jumpgate terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all). If you goof this step in any way and want to start over, just go to that second window I mentioned and type ''rm -rf ~/.google_authenticator'' and start over but, more than likely, what you did is fine.<br />
<br />
The next time you log into jumpgate, it will request a verification code which your phone application will provide. Enter that codes in the terminal.<br />
<br />
<br />
'''Virtual Network Computing (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. <br />
<br />
'''Warning: The VNC password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
<code>portal1</code> is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from <code>start_vnc.sh</code>. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It is common practice to leave your VNC session running on <code>portal1</code>. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's VNC port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
<code>portal1</code> is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the <code>vglrun</code> command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from <code>portal1</code>. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are <code>viz002</code> and <code>viz003</code> (<code>viz001</code> is probably never coming back to life). <br />
<code>portal1</code> doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command <code>vglrun</code>. You can test that you have it setup right<br />
with the toy-app <code>glxgears</code> as follows<br />
<br />
vglrun glxgears<br />
<br />
Note that VGL uses a number of threads. If you have trouble with <code>vglrun</code> crashing with a message about <code>Thread::Start()</code> make sure you haven't set your stack size too large (remove any <code>ulimit -s</code> or <code>ulimit -n</code> calls from your shell start scripts).<br />
<br />
NOTE ALSO: The primary purpose for <code>viz003</code> is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
<code>portal1</code> uses TurboVNC from the VirtualGL project, available from [http://www.virtualgl.org/Downloads/TurboVNC their website]<br />
<br />
Other VNC viewers will also work, such as [https://www.tightvnc.com/download.php TightVNC] and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Mac or Linux ==<br />
<br />
The instructions given when you started the session on <code>portal1</code> are OK but it always tells you to start a session (in a terminal on your mac or linux machine command line)<br />
<br />
ssh -L5905:portal1:59zw jumpgate-phasta.colorado.edu<br />
<br />
where <code>zw</code> will be different for each user. That suggestion is OK if you never plan to connect to anyone else's session but since we often collaborate but sharing VNC sessions, the better practice we adopt is to use <code>zw</code> in place of the suggested 05 (which just an arbitrary local port on your laptop). So if when I created a session the last for numbers were <code>5923</code> then <code>zw</code> for me is <code>23</code> and the best practice is to ignore the script suggestion in favor of<br />
<br />
ssh -L5923:portal1:5923 jumpgate-phasta.colorado.edu<br />
<br />
== Windows == <br />
The PuTTY SSH client can handle ssh tunneling on Windows based machines. You can download it [http://www.chiark.greenend.org.uk/~sgtatham/putty/ here].<br />
<br />
When you open putty, enter <code>jumpgate-phasta.colorado.edu</code> 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 <code>start_vnc.sh</code> script should tell you to run <code>ssh -L59xy:portal1:59zw jumpgate-phasta.colorado.edu</code> on your machine. Those instructions are OK but a better practice is to ignore what that script suggested for <code>xy</code> (it always suggests 05 currently) and instead use <code>ssh -L59zw:portal1:59zw jumpgate-phasta.colorado.edu" where <code>zw</code> varies for each new session created. If you get <code>23</code> that just means there were <code>22</code> sessions created before you created this one (but the plan is for you to keep using 23 until the machine gets rebooted). Enter <code>59zw</code> in the "Source Port" box. Enter <code>portal1:59zw</code> in the "Destination" box (starting and ''click the add button''). Putty is a little strange about saving the session which you want to do to avoid having to do all the above every time you re-connect. ''BEFORE'' you click the "Open" button, you want to name your session (your choice) and click save. Then in the future when you start putty you should be able to just click that saved session name and click load. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.<br />
<br />
Example:<br />
<br />
The script says:<br />
<code>ssh -L5905:portal1:5923 jumpgate-phasta.colorado.edu</code><br />
your <code>zw</code> from the instructions above is <code>23</code><br />
enter <code>5923</code> in the "Source Port" box<br />
enter <code>portal1:5923</code> in the destination box.<br />
<br />
===Connecting to your VNC with PuTTY===<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59zw.<br />
#* To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
#* To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>USERNAME@jumpgate-phasta.colorado.edu:22</code>, where <code>USERNAME</code> is your username on <code>jumpgate</code>, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59##</code> and destination port <code>portal1:59##</code>, where <code>##</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". <br />
#* We select <code>local</code> because we have a service (VNC Server) running on a machine (<code>portal1</code>) that can be reached from the remote machine (<code>jumpgate</code>), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between <code>localhost</code> and <code>jumpgate</code>, and tunneling <code>localhost:59##</code> to <code>portal1:59##</code> via this connection.<br />
# Open RealVNC, and connect to <code>localhost:##</code>, which is shorthand for <code>localhost:59##</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>##</code> is assumed to be port <code>59##</code>.<br />
# You should now have access to your desktop on <code>portal1</code>. DON'T FORGET-- no meshing, solving, post-processing, EVEN MATLAB on <code>portal1</code>. To run memory and/or processor and/or graphics intensive jobs you need to create a terminal and type <code>vglconnect -s viz00x</code> where, at this time <code>x</code> is either 2 or 3.<br />
<br />
== Starting a VNC viewer ==<br />
<br />
Whether you followed the Mac or Linux or Windows instructions above, successful completion will have established a tunnel from your laptop to <code>portal1</code>. The last step is to start a VNC viewer (graphical windowing program) that uses this tunnel to display your <code>portal1</code> session on the screen of your laptop. There are a variety of choices for each platform and they evolve but their operation seems, thankfully, pretty universal. <br />
<br />
The most basic input is that they provide a box that says VNC server. You will want to type <code>localhost:zw</code> in that box and then apply start (or whatever the particular applications action button is). The <code>zw</code> here will need to be whatever you used after the <code>59zw:portal1</code>..... part of the tunnel. What the number is actually doing is telling this VNC viewer which port you have established a tunnel on for the session you are starting the VNC viewer for. Note it is possible to have several different simultaneous sessions. Each needs its own tunnel (established by repeating the process above with a unique <code>zw</code>) and then a corresponding "new" VNC viewer. In this way we might continue to work in our own session but then take a break to look at a collaborator's session without having to close out the tunnel and viewer pair.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
You can usually use the <code>xrandr</code> 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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs).<br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
If you have used vncserver (It doesn't matter which version) before, you will need to clear your vnc settings for the script to work. You can do this by running rm -rf ~/.vnc<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=925VNC2020-09-08T00:17:43Z<p>Kjansen: </p>
<hr />
<div>'''Logging in'''<br />
<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough) or using Putty (see below for installing and setting up putty-- stuff you need to type will be in ''italic''):<br />
<br />
''ssh jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''username'' and ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
If you want to be safe, start a second terminal connection to jumpgate by repeating the above. In the first (or only) jumpgate terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all). If you goof this step in any way and want to start over, just go to that second window I mentioned and type ''rm -rf ~/.google_authenticator'' and start over but, more than likely, what you did is fine.<br />
<br />
The next time you log into jumpgate, it will request a verification code which your phone application will provide. Enter that codes in the terminal.<br />
<br />
<br />
'''Virtual Network Computing (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. <br />
<br />
'''Warning: The VNC password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
<code>portal1</code> is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from <code>start_vnc.sh</code>. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It is common practice to leave your VNC session running on <code>portal1</code>. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's VNC port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
<code>portal1</code> is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the <code>vglrun</code> command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from <code>portal1</code>. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are <code>viz002</code> and <code>viz003</code> (<code>viz001</code> is probably never coming back to life). <br />
<code>portal1</code> doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command <code>vglrun</code>. You can test that you have it setup right<br />
with the toy-app <code>glxgears</code> as follows<br />
<br />
vglrun glxgears<br />
<br />
Note that VGL uses a number of threads. If you have trouble with <code>vglrun</code> crashing with a message about <code>Thread::Start()</code> make sure you haven't set your stack size too large (remove any <code>ulimit -s</code> or <code>ulimit -n</code> calls from your shell start scripts).<br />
<br />
NOTE ALSO: The primary purpose for <code>viz003</code> is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
<code>portal1</code> uses TurboVNC from the VirtualGL project, available from [http://www.virtualgl.org/Downloads/TurboVNC their website]<br />
<br />
Other VNC viewers will also work, such as [https://www.tightvnc.com/download.php TightVNC] and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Mac or Linux ==<br />
<br />
The instructions given when you started the session on <code>portal1</code> are OK but it always tells you to start a session (in a terminal on your mac or linux machine command line)<br />
<br />
ssh -L5905:portal1:59zw jumpgate-phasta.colorado.edu<br />
<br />
where <code>zw</code> will be different for each user. That suggestion is OK if you never plan to connect to anyone else's session but since we often collaborate but sharing VNC sessions, the better practice we adopt is to use <code>zw</code> in place of the suggested 05 (which just an arbitrary local port on your laptop). So if when I created a session the last for numbers were <code>5923</code> then <code>zw</code> for me is <code>23</code> and the best practice is to ignore the script suggestion in favor of<br />
<br />
ssh -L5923:portal1:5923 jumpgate-phasta.colorado.edu<br />
<br />
== Windows == <br />
The PuTTY SSH client can handle ssh tunneling on Windows based machines. You can download it [http://www.chiark.greenend.org.uk/~sgtatham/putty/ here].<br />
<br />
When you open putty, enter <code>jumpgate-phasta.colorado.edu</code> 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 <code>start_vnc.sh</code> script should tell you to run <code>ssh -L59xy:portal1:59zw jumpgate-phasta.colorado.edu</code> on your machine. Those instructions are OK but a better practice is to ignore what that script suggested for <code>xy</code> (it always suggests 05 currently) and instead use <code>ssh -L59zw:portal1:59zw jumpgate-phasta.colorado.edu" where <code>zw</code> varies for each new session created. If you get <code>23</code> that just means there were <code>22</code> sessions created before you created this one (but the plan is for you to keep using 23 until the machine gets rebooted). Enter <code>59zw</code> in the "Source Port" box. Enter <code>portal1:59zw</code> in the "Destination" box (starting and ''click the add button''). Putty is a little strange about saving the session which you want to do to avoid having to do all the above every time you re-connect. ''BEFORE'' you click the "Open" button, you want to name your session (your choice) and click save. Then in the future when you start putty you should be able to just click that saved session name and click load. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.<br />
<br />
Example:<br />
<br />
The script says:<br />
<code>ssh -L5905:portal1:5923 jumpgate-phasta.colorado.edu</code><br />
your <code>zw</code> from the instructions above is <code>23</code><br />
enter <code>5923</code> in the "Source Port" box<br />
enter <code>portal1:5923</code> in the destination box.<br />
<br />
===Connecting to your VNC with PuTTY===<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59zw.<br />
#* To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
#* To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>USERNAME@jumpgate-phasta.colorado.edu:22</code>, where <code>USERNAME</code> is your username on <code>jumpgate</code>, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59##</code> and destination port <code>portal1:59##</code>, where <code>##</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". <br />
#* We select <code>local</code> because we have a service (VNC Server) running on a machine (<code>portal1</code>) that can be reached from the remote machine (<code>jumpgate</code>), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between <code>localhost</code> and <code>jumpgate</code>, and tunneling <code>localhost:59##</code> to <code>portal1:59##</code> via this connection.<br />
# Open RealVNC, and connect to <code>localhost:##</code>, which is shorthand for <code>localhost:59##</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>##</code> is assumed to be port <code>59##</code>.<br />
# You should now have access to your desktop on <code>portal1</code>. DON'T FORGET-- no meshing, solving, post-processing, EVEN MATLAB on <code>portal1</code>. To run memory and/or processor and/or graphics intensive jobs you need to create a terminal and type <code>vglconnect -s viz00x</code> where, at this time <code>x</code> is either 2 or 3.<br />
<br />
== Starting a VNC viewer ==<br />
<br />
Whether you followed the Mac or Linux or Windows instructions above, successful completion will have established a tunnel from your laptop to <code>portal1</code>. The last step is to start a VNC viewer (graphical windowing program) that uses this tunnel to display your <code>portal1</code> session on the screen of your laptop. There are a variety of choices for each platform and they evolve but their operation seems, thankfully, pretty universal. <br />
<br />
The most basic input is that they provide a box that says VNC server. You will want to type <code>localhost:zw</code> in that box and then apply start (or whatever the particular applications action button is). The <code>zw</code> here will need to be whatever you used after the <code>59zw:portal1</code>..... part of the tunnel. What the number is actually doing is telling this VNC viewer which port you have established a tunnel on for the session you are starting the VNC viewer for. Note it is possible to have several different simultaneous sessions. Each needs its own tunnel (established by repeating the process above with a unique <code>zw</code>) and then a corresponding "new" VNC viewer. In this way we might continue to work in our own session but then take a break to look at a collaborator's session without having to close out the tunnel and viewer pair.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
You can usually use the <code>xrandr</code> 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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs).<br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
If you have used vncserver (It doesn't matter which version) before, you will need to clear your vnc settings for the script to work. You can do this by running rm -rf ~/.vnc<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=924VNC2020-09-08T00:17:28Z<p>Kjansen: </p>
<hr />
<div>'''Logging in'''<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough) or using Putty (see below for installing and setting up putty-- stuff you need to type will be in ''italic''):<br />
<br />
''ssh jumpgate-phasta.colorado.edu''<br />
<br />
This will prompt for your ''username'' and ''password'' (the private password you set or, if this is your first login the one in the account creation email).<br />
<br />
Next you need to download and install an authenticator application either for your computer or phone. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone or computer. In whatever mode it uses to create a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access).<br />
<br />
If you want to be safe, start a second terminal connection to jumpgate by repeating the above. In the first (or only) jumpgate terminal on your laptop type:<br />
<br />
''google-authenticator''<br />
<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all). If you goof this step in any way and want to start over, just go to that second window I mentioned and type ''rm -rf ~/.google_authenticator'' and start over but, more than likely, what you did is fine.<br />
<br />
The next time you log into jumpgate, it will request a verification code which your phone application will provide. Enter that codes in the terminal.<br />
<br />
<br />
'''Virtual Network Computing (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. <br />
<br />
'''Warning: The VNC password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
<code>portal1</code> is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from <code>start_vnc.sh</code>. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It is common practice to leave your VNC session running on <code>portal1</code>. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's VNC port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
<code>portal1</code> is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the <code>vglrun</code> command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from <code>portal1</code>. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are <code>viz002</code> and <code>viz003</code> (<code>viz001</code> is probably never coming back to life). <br />
<code>portal1</code> doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command <code>vglrun</code>. You can test that you have it setup right<br />
with the toy-app <code>glxgears</code> as follows<br />
<br />
vglrun glxgears<br />
<br />
Note that VGL uses a number of threads. If you have trouble with <code>vglrun</code> crashing with a message about <code>Thread::Start()</code> make sure you haven't set your stack size too large (remove any <code>ulimit -s</code> or <code>ulimit -n</code> calls from your shell start scripts).<br />
<br />
NOTE ALSO: The primary purpose for <code>viz003</code> is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
<code>portal1</code> uses TurboVNC from the VirtualGL project, available from [http://www.virtualgl.org/Downloads/TurboVNC their website]<br />
<br />
Other VNC viewers will also work, such as [https://www.tightvnc.com/download.php TightVNC] and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Mac or Linux ==<br />
<br />
The instructions given when you started the session on <code>portal1</code> are OK but it always tells you to start a session (in a terminal on your mac or linux machine command line)<br />
<br />
ssh -L5905:portal1:59zw jumpgate-phasta.colorado.edu<br />
<br />
where <code>zw</code> will be different for each user. That suggestion is OK if you never plan to connect to anyone else's session but since we often collaborate but sharing VNC sessions, the better practice we adopt is to use <code>zw</code> in place of the suggested 05 (which just an arbitrary local port on your laptop). So if when I created a session the last for numbers were <code>5923</code> then <code>zw</code> for me is <code>23</code> and the best practice is to ignore the script suggestion in favor of<br />
<br />
ssh -L5923:portal1:5923 jumpgate-phasta.colorado.edu<br />
<br />
== Windows == <br />
The PuTTY SSH client can handle ssh tunneling on Windows based machines. You can download it [http://www.chiark.greenend.org.uk/~sgtatham/putty/ here].<br />
<br />
When you open putty, enter <code>jumpgate-phasta.colorado.edu</code> 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 <code>start_vnc.sh</code> script should tell you to run <code>ssh -L59xy:portal1:59zw jumpgate-phasta.colorado.edu</code> on your machine. Those instructions are OK but a better practice is to ignore what that script suggested for <code>xy</code> (it always suggests 05 currently) and instead use <code>ssh -L59zw:portal1:59zw jumpgate-phasta.colorado.edu" where <code>zw</code> varies for each new session created. If you get <code>23</code> that just means there were <code>22</code> sessions created before you created this one (but the plan is for you to keep using 23 until the machine gets rebooted). Enter <code>59zw</code> in the "Source Port" box. Enter <code>portal1:59zw</code> in the "Destination" box (starting and ''click the add button''). Putty is a little strange about saving the session which you want to do to avoid having to do all the above every time you re-connect. ''BEFORE'' you click the "Open" button, you want to name your session (your choice) and click save. Then in the future when you start putty you should be able to just click that saved session name and click load. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.<br />
<br />
Example:<br />
<br />
The script says:<br />
<code>ssh -L5905:portal1:5923 jumpgate-phasta.colorado.edu</code><br />
your <code>zw</code> from the instructions above is <code>23</code><br />
enter <code>5923</code> in the "Source Port" box<br />
enter <code>portal1:5923</code> in the destination box.<br />
<br />
===Connecting to your VNC with PuTTY===<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59zw.<br />
#* To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
#* To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>USERNAME@jumpgate-phasta.colorado.edu:22</code>, where <code>USERNAME</code> is your username on <code>jumpgate</code>, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59##</code> and destination port <code>portal1:59##</code>, where <code>##</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". <br />
#* We select <code>local</code> because we have a service (VNC Server) running on a machine (<code>portal1</code>) that can be reached from the remote machine (<code>jumpgate</code>), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between <code>localhost</code> and <code>jumpgate</code>, and tunneling <code>localhost:59##</code> to <code>portal1:59##</code> via this connection.<br />
# Open RealVNC, and connect to <code>localhost:##</code>, which is shorthand for <code>localhost:59##</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>##</code> is assumed to be port <code>59##</code>.<br />
# You should now have access to your desktop on <code>portal1</code>. DON'T FORGET-- no meshing, solving, post-processing, EVEN MATLAB on <code>portal1</code>. To run memory and/or processor and/or graphics intensive jobs you need to create a terminal and type <code>vglconnect -s viz00x</code> where, at this time <code>x</code> is either 2 or 3.<br />
<br />
== Starting a VNC viewer ==<br />
<br />
Whether you followed the Mac or Linux or Windows instructions above, successful completion will have established a tunnel from your laptop to <code>portal1</code>. The last step is to start a VNC viewer (graphical windowing program) that uses this tunnel to display your <code>portal1</code> session on the screen of your laptop. There are a variety of choices for each platform and they evolve but their operation seems, thankfully, pretty universal. <br />
<br />
The most basic input is that they provide a box that says VNC server. You will want to type <code>localhost:zw</code> in that box and then apply start (or whatever the particular applications action button is). The <code>zw</code> here will need to be whatever you used after the <code>59zw:portal1</code>..... part of the tunnel. What the number is actually doing is telling this VNC viewer which port you have established a tunnel on for the session you are starting the VNC viewer for. Note it is possible to have several different simultaneous sessions. Each needs its own tunnel (established by repeating the process above with a unique <code>zw</code>) and then a corresponding "new" VNC viewer. In this way we might continue to work in our own session but then take a break to look at a collaborator's session without having to close out the tunnel and viewer pair.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
You can usually use the <code>xrandr</code> 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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs).<br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
If you have used vncserver (It doesn't matter which version) before, you will need to clear your vnc settings for the script to work. You can do this by running rm -rf ~/.vnc<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=923VNC2020-09-08T00:14:10Z<p>Kjansen: </p>
<hr />
<div>Logging in<br />
Due to recent brute force ssh attacks we are moving to using two factor authentication. This is pretty easy to setup as follows (from a terminal in your mac or linux laptop (and Windows if new enough) or using Putty (see below for installing and setting up putty-- stuff you need to type will be in italic):<br />
ssh jumpgate-phasta.colorado.edu<br />
This will prompt for your username and password (the private password you set or, if this is your first login the one in the account creation email).<br />
Next you need to download and install an authenticator application. There are several from Google, Microsoft, Twilio, etc. Launch that application on your phone. In whatever mode it uses to start a new token generator, do that (often it opens with a QR code scanner enabled as it knows that is the easiest way to link the phone application to the QR scan created on the machine you are trying to access). If you want to be safe, start a second terminal connection to jumpgate by repeating the above. In the first (or only) jumpgate terminal on your laptop type:<br />
google-authenticator<br />
If your terminal is big enough, it should display a QR code that you can scan with your phone. At this point it will ask you some questions about options (I answered yes to all). If you goof this step in any way and want to start over, just go to that second window I mentioned and type rm -rf ~/.google_authenticator but, more than likely, what you did is fine.<br />
The next time you log into jumpgate, it will request a verification code which your phone application will provide. Enter that codes in the terminal.<br />
<br />
<br />
'''Virtual Network Computing (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. <br />
<br />
'''Warning: The VNC password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
<code>portal1</code> is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from <code>start_vnc.sh</code>. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It is common practice to leave your VNC session running on <code>portal1</code>. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's VNC port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
<code>portal1</code> is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the <code>vglrun</code> command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from <code>portal1</code>. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are <code>viz002</code> and <code>viz003</code> (<code>viz001</code> is probably never coming back to life). <br />
<code>portal1</code> doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command <code>vglrun</code>. You can test that you have it setup right<br />
with the toy-app <code>glxgears</code> as follows<br />
<br />
vglrun glxgears<br />
<br />
Note that VGL uses a number of threads. If you have trouble with <code>vglrun</code> crashing with a message about <code>Thread::Start()</code> make sure you haven't set your stack size too large (remove any <code>ulimit -s</code> or <code>ulimit -n</code> calls from your shell start scripts).<br />
<br />
NOTE ALSO: The primary purpose for <code>viz003</code> is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
<code>portal1</code> uses TurboVNC from the VirtualGL project, available from [http://www.virtualgl.org/Downloads/TurboVNC their website]<br />
<br />
Other VNC viewers will also work, such as [https://www.tightvnc.com/download.php TightVNC] and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Mac or Linux ==<br />
<br />
The instructions given when you started the session on <code>portal1</code> are OK but it always tells you to start a session (in a terminal on your mac or linux machine command line)<br />
<br />
ssh -L5905:portal1:59zw jumpgate-phasta.colorado.edu<br />
<br />
where <code>zw</code> will be different for each user. That suggestion is OK if you never plan to connect to anyone else's session but since we often collaborate but sharing VNC sessions, the better practice we adopt is to use <code>zw</code> in place of the suggested 05 (which just an arbitrary local port on your laptop). So if when I created a session the last for numbers were <code>5923</code> then <code>zw</code> for me is <code>23</code> and the best practice is to ignore the script suggestion in favor of<br />
<br />
ssh -L5923:portal1:5923 jumpgate-phasta.colorado.edu<br />
<br />
== Windows == <br />
The PuTTY SSH client can handle ssh tunneling on Windows based machines. You can download it [http://www.chiark.greenend.org.uk/~sgtatham/putty/ here].<br />
<br />
When you open putty, enter <code>jumpgate-phasta.colorado.edu</code> 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 <code>start_vnc.sh</code> script should tell you to run <code>ssh -L59xy:portal1:59zw jumpgate-phasta.colorado.edu</code> on your machine. Those instructions are OK but a better practice is to ignore what that script suggested for <code>xy</code> (it always suggests 05 currently) and instead use <code>ssh -L59zw:portal1:59zw jumpgate-phasta.colorado.edu" where <code>zw</code> varies for each new session created. If you get <code>23</code> that just means there were <code>22</code> sessions created before you created this one (but the plan is for you to keep using 23 until the machine gets rebooted). Enter <code>59zw</code> in the "Source Port" box. Enter <code>portal1:59zw</code> in the "Destination" box (starting and ''click the add button''). Putty is a little strange about saving the session which you want to do to avoid having to do all the above every time you re-connect. ''BEFORE'' you click the "Open" button, you want to name your session (your choice) and click save. Then in the future when you start putty you should be able to just click that saved session name and click load. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.<br />
<br />
Example:<br />
<br />
The script says:<br />
<code>ssh -L5905:portal1:5923 jumpgate-phasta.colorado.edu</code><br />
your <code>zw</code> from the instructions above is <code>23</code><br />
enter <code>5923</code> in the "Source Port" box<br />
enter <code>portal1:5923</code> in the destination box.<br />
<br />
===Connecting to your VNC with PuTTY===<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59zw.<br />
#* To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
#* To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>USERNAME@jumpgate-phasta.colorado.edu:22</code>, where <code>USERNAME</code> is your username on <code>jumpgate</code>, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59##</code> and destination port <code>portal1:59##</code>, where <code>##</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". <br />
#* We select <code>local</code> because we have a service (VNC Server) running on a machine (<code>portal1</code>) that can be reached from the remote machine (<code>jumpgate</code>), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between <code>localhost</code> and <code>jumpgate</code>, and tunneling <code>localhost:59##</code> to <code>portal1:59##</code> via this connection.<br />
# Open RealVNC, and connect to <code>localhost:##</code>, which is shorthand for <code>localhost:59##</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>##</code> is assumed to be port <code>59##</code>.<br />
# You should now have access to your desktop on <code>portal1</code>. DON'T FORGET-- no meshing, solving, post-processing, EVEN MATLAB on <code>portal1</code>. To run memory and/or processor and/or graphics intensive jobs you need to create a terminal and type <code>vglconnect -s viz00x</code> where, at this time <code>x</code> is either 2 or 3.<br />
<br />
== Starting a VNC viewer ==<br />
<br />
Whether you followed the Mac or Linux or Windows instructions above, successful completion will have established a tunnel from your laptop to <code>portal1</code>. The last step is to start a VNC viewer (graphical windowing program) that uses this tunnel to display your <code>portal1</code> session on the screen of your laptop. There are a variety of choices for each platform and they evolve but their operation seems, thankfully, pretty universal. <br />
<br />
The most basic input is that they provide a box that says VNC server. You will want to type <code>localhost:zw</code> in that box and then apply start (or whatever the particular applications action button is). The <code>zw</code> here will need to be whatever you used after the <code>59zw:portal1</code>..... part of the tunnel. What the number is actually doing is telling this VNC viewer which port you have established a tunnel on for the session you are starting the VNC viewer for. Note it is possible to have several different simultaneous sessions. Each needs its own tunnel (established by repeating the process above with a unique <code>zw</code>) and then a corresponding "new" VNC viewer. In this way we might continue to work in our own session but then take a break to look at a collaborator's session without having to close out the tunnel and viewer pair.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
You can usually use the <code>xrandr</code> 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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs).<br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
If you have used vncserver (It doesn't matter which version) before, you will need to clear your vnc settings for the script to work. You can do this by running rm -rf ~/.vnc<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=870VNC2020-09-04T13:25:51Z<p>Kjansen: </p>
<hr />
<div>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. <br />
<br />
'''Warning: The vnc password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
Portal1 is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from start_vnc.sh. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It's okay to leave your VNC session running on portal1. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's vnc port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
Portal1 is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the "vglrun" command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from portal1. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are viz002 and viz003 (viz001 is probably never coming back to life).<br />
portal1 doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command vglrun. You can test that you have it setup right<br />
with the toyapp glxgears as follows<br />
<br />
vglrun glxgears<br />
<br />
<br />
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).<br />
<br />
NOTE ALSO: The primary purpose for viz003 is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
Portal1 uses TurboVNC from the VirtualGL project, available from http://www.virtualgl.org/Downloads/TurboVNC<br />
<br />
Other VNC viewers will also work, such as TightVNC and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Mac or Linux ==<br />
<br />
The instructions given when you started the session on portal1 are OK but it always tells you to start a session (in a terminal on your mac or linux machine command line)<br />
<br />
ssh -L5905:portal1:59zw jumpgate-phasta.colorado.edu<br />
<br />
where zw will be different for each user (actually each session created but we are hoping for only one per user please :> ). That suggestion is OK if you never plan to connect to anyone else's session but since we often collaborate but sharing VNC sessions, the better practice we adopt is to use zw in pl place of the suggested 05 (the 05 is just the local port on your laptop so it can be anything but its easier to remember which port is which if you always give them the same number and there is no chance of giving two VNC's the same number accidentally with this practice). So if when I created a session the last for numbers were 5923 then zw for me is 23 and the best practice is to ignore the script suggestion in favor of<br />
<br />
ssh -L5923:portal1:5923 jumpgate-phasta.colorado.edu<br />
<br />
== Windows == <br />
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/<br />
<br />
When you open putty, enter jumpgate-phasta.colorado.edu 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 -L59xy:portal1:59zw jumpgate-phasta.colorado.edu" on your machine. Those instructions are OK but a better practice is to ignore what that script suggested for xy (it always suggests 05 currently) and instead use "ssh -L59zw:portal1:59zw jumpgate-phasta.colorado.edu" where zw varies for each new session created. If you get 23 that just means there were 22 sessions created before you created this one but the plan is for you to keep using 23 for a long time (usually until the machine gets rebooted which can be a year or more in some cases). Enter 59zw in the "Source port" box. Enter portal1:59zw in the Destination box (starting and '''click the add button'''. Putty is a little strange about saving the session which you want to do to avoid having to do all the above every time you re-connect. BEFORE you click the Open button, you want to name your session (your choice) and click save. Then in the future when you start putty you should be able to just click that saved session name and click load. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.<br />
<br />
Example:<br />
<br />
The script says:<br />
ssh -L5905:portal1:5923 jumpgate-phasta.colorado.edu<br />
your "zw" from the instructions above is 23<br />
enter 5923 in the Source port box<br />
enter portal1:5923 in the destination box.<br />
<br />
Try using this viewer utility<br />
http://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_x86_viewer.zip<br />
<br />
'''Connecting to your VNC with PuTTY'''<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59zw.<br />
## To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
## To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>x@jumpgate-phasta.colorado.edu:22</code>, where <code>x</code> is your username on jumpgate, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59xx</code> and destination port <code>portal1:59xx</code>, where <code>xx</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". We select <code>local</code> because we have a service (VNC Server) running on a machine (portal1) that can be reached from the remote machine (jumpgate), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between localhost and jumpgate, and tunneling localhost:59xx to portal1:59xx via this connection.<br />
# Open RealVNC, and connect to <code>localhost:xx</code>, which is shorthand for <code>localhost:59xx</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>xx</code> is assumed to be port <code>59xx</code>.<br />
# You should now have access to your desktop on portal1. DON'T FORGET-- no meshing, solving, postprocessing, EVEN MATLAB on portal1. To run memory and/or processor and/or graphics intensive jobs you need to create a terminal and type vglconnect -s viz00x where, at this time x =2, or 3.<br />
<br />
== Starting a VNC viewer ==<br />
<br />
Whether you followed the Mac or Linux or Windows instructions above, successful completion will have established a tunnel from your laptop to portal1. The last step is to start a VNC viewer (graphical windowing program) that uses this tunnel to display your portal1 session on the screen of your laptop. There are a variety of choices for each platform and they evolve but their operation seems, thankfully, pretty universal. The most basic input is that they provide a box that says VNC server. You will want to type localhost:zw in that box and then apply start or whatever the particular applications action button is. Note that the zw here will need to be whatever you used after the 59zw:portal..... part of the tunnel. This is why we suggest using the same number twice so that you only have one number to remember. What the number is actually doing is telling this VNC viewer which port you have established a tunnel on for the session you are starting the VNC viewer for. Note it is possible to have several different simultaneous sessions. Each needs its own tunnel (established by repeating the process above with a unique zw) and then a corresponding "new" VNC viewer. In this way we might continue to work in our own session but then take a break to look at a collaborator's session without having to close out the tunnel and viewer pair.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs). <br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
If you have used vncserver (It doesn't matter which version) before, you will need to clear your vnc settings for the script to work. You can do this by running rm -rf ~/.vnc<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=869VNC2020-09-04T13:13:37Z<p>Kjansen: </p>
<hr />
<div>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. <br />
<br />
'''Warning: The vnc password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
Portal1 is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from start_vnc.sh. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It's okay to leave your VNC session running on portal1. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's vnc port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
Portal1 is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the "vglrun" command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from portal1. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are viz002 and viz003 (viz001 is probably never coming back to life).<br />
portal1 doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command vglrun. You can test that you have it setup right<br />
with the toyapp glxgears as follows<br />
<br />
vglrun glxgears<br />
<br />
<br />
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).<br />
<br />
NOTE ALSO: The primary purpose for viz003 is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
Portal1 uses TurboVNC from the VirtualGL project, available from http://www.virtualgl.org/Downloads/TurboVNC<br />
<br />
Other VNC viewers will also work, such as TightVNC and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Mac or Linux ==<br />
<br />
The instructions given when you started the session on portal1 are OK but it always tells you to start a session (in a terminal on your mac or linux machine command line)<br />
<br />
ssh -L5905:portal1:59zw jumpgate-phasta.colorado.edu<br />
<br />
where zw will be different for each user (actually each session created but we are hoping for only one per user please :> ). That suggestion is OK if you never plan to connect to anyone else's session but since we often collaborate but sharing VNC sessions, the better practice we adopt is to use zw in pl place of the suggested 05 (the 05 is just the local port on your laptop so it can be anything but its easier to remember which port is which if you always give them the same number and there is no chance of giving two VNC's the same number accidentally with this practice). So if when I created a session the last for numbers were 5923 then zw for me is 23 and the best practice is to ignore the script suggestion in favor of<br />
<br />
ssh -L5923:portal1:5923 jumpgate-phasta.colorado.edu<br />
<br />
== Windows == <br />
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/<br />
<br />
When you open putty, enter jumpgate-phasta.colorado.edu 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 -L59xy:portal1:59zw jumpgate-phasta.colorado.edu" on your machine. Those instructions are OK but a better practice is to ignore what that script suggested for xy (it always suggests 05 currently) and instead use "ssh -L59zw:portal1:59zw jumpgate-phasta.colorado.edu" where zw varies for each new session created. If you get 23 that just means there were 22 sessions created before you created this one but the plan is for you to keep using 23 for a long time (usually until the machine gets rebooted which can be a year or more in some cases). Enter 59zw in the "Source port" box. Enter portal1:59zw in the Destination box (starting and '''click the add button'''. Putty is a little strange about saving the session which you want to do to avoid having to do all the above every time you re-connect. BEFORE you click the Open button, you want to name your session (your choice) and click save. Then in the future when you start putty you should be able to just click that saved session name and click load. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.<br />
<br />
Example:<br />
<br />
The script says:<br />
ssh -L5905:portal1:5923 jumpgate-phasta.colorado.edu<br />
your "zw" from the instructions above is 23<br />
enter 5923 in the Source port box<br />
enter portal1:5923 in the destination box.<br />
<br />
Try using this viewer utility<br />
http://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_x86_viewer.zip<br />
<br />
'''Connecting to your VNC with PuTTY'''<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59zw.<br />
## To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
## To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>x@jumpgate-phasta.colorado.edu:22</code>, where <code>x</code> is your username on jumpgate, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59xx</code> and destination port <code>portal1:59xx</code>, where <code>xx</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". We select <code>local</code> because we have a service (VNC Server) running on a machine (portal1) that can be reached from the remote machine (jumpgate), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between localhost and jumpgate, and tunneling localhost:59xx to portal1:59xx via this connection.<br />
# Open RealVNC, and connect to <code>localhost:xx</code>, which is shorthand for <code>localhost:59xx</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>xx</code> is assumed to be port <code>59xx</code>.<br />
# You should now have access to your desktop on portal1. DON'T FORGET-- no meshing, solving, postprocessing, EVEN MATLAB on portal1. To run memory and/or processor and/or graphics intensive jobs you need to create a terminal and type vglconnect -s viz00x where, at this time x =2, or 3.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs). <br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
If you have used vncserver (It doesn't matter which version) before, you will need to clear your vnc settings for the script to work. You can do this by running rm -rf ~/.vnc<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=868VNC2020-09-04T13:11:01Z<p>Kjansen: </p>
<hr />
<div>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. <br />
<br />
'''Warning: The vnc password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
Portal1 is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from start_vnc.sh. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It's okay to leave your VNC session running on portal1. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's vnc port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
Portal1 is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the "vglrun" command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from portal1. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are viz002 and viz003 (viz001 is probably never coming back to life).<br />
portal1 doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command vglrun. You can test that you have it setup right<br />
with the toyapp glxgears as follows<br />
<br />
vglrun glxgears<br />
<br />
<br />
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).<br />
<br />
NOTE ALSO: The primary purpose for viz003 is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
Portal1 uses TurboVNC from the VirtualGL project, available from http://www.virtualgl.org/Downloads/TurboVNC<br />
<br />
Other VNC viewers will also work, such as TightVNC and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Mac of Linux ==<br />
<br />
The instructions given when you started the session on portal1 are OK but it always tells you <br />
<br />
ssh -L5905:portal1:59zw jumpgate-phasta.colorado.edu<br />
<br />
where zw will be different for each user (actually each session created but we are hoping for only one per user please :> ). That suggestion is OK if you never plan to connect to anyone else's session but since we often collaborate but sharing VNC sessions, the better practice we adopt is to use zw in pl place of the suggested 05 (the 05 is just the local port on your laptop so it can be anything but its easier to remember which port is which if you always give them the same number and there is no chance of giving two VNC's the same number accidentally with this practice). So if when I created a session the last for numbers were 5923 then zw for me is 23 and the best practice is to ignore the script suggestion in favor of<br />
<br />
ssh -L5923:portal1:5923 jumpgate-phasta.colorado.edu<br />
<br />
== Windows == <br />
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/<br />
<br />
When you open putty, enter jumpgate-phasta.colorado.edu 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 -L59xy:portal1:59zw jumpgate-phasta.colorado.edu" on your machine. Those instructions are OK but a better practice is to ignore what that script suggested for xy (it always suggests 05 currently) and instead use "ssh -L59zw:portal1:59zw jumpgate-phasta.colorado.edu" where zw varies for each new session created. If you get 23 that just means there were 22 sessions created before you created this one but the plan is for you to keep using 23 for a long time (usually until the machine gets rebooted which can be a year or more in some cases). Enter 59zw in the "Source port" box. Enter portal1:59zw in the Destination box (starting and '''click the add button'''. Putty is a little strange about saving the session which you want to do to avoid having to do all the above every time you re-connect. BEFORE you click the Open button, you want to name your session (your choice) and click save. Then in the future when you start putty you should be able to just click that saved session name and click load. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.<br />
<br />
Example:<br />
<br />
The script says:<br />
ssh -L5905:portal1:5923 jumpgate-phasta.colorado.edu<br />
your "zw" from the instructions above is 23<br />
enter 5923 in the Source port box<br />
enter portal1:5923 in the destination box.<br />
<br />
Try using this viewer utility<br />
http://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_x86_viewer.zip<br />
<br />
'''Connecting to your VNC with PuTTY'''<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59zw.<br />
## To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
## To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>x@jumpgate-phasta.colorado.edu:22</code>, where <code>x</code> is your username on jumpgate, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59xx</code> and destination port <code>portal1:59xx</code>, where <code>xx</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". We select <code>local</code> because we have a service (VNC Server) running on a machine (portal1) that can be reached from the remote machine (jumpgate), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between localhost and jumpgate, and tunneling localhost:59xx to portal1:59xx via this connection.<br />
# Open RealVNC, and connect to <code>localhost:xx</code>, which is shorthand for <code>localhost:59xx</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>xx</code> is assumed to be port <code>59xx</code>.<br />
# You should now have access to your desktop on portal1. DON'T FORGET-- no meshing, solving, postprocessing, EVEN MATLAB on portal1. To run memory and/or processor and/or graphics intensive jobs you need to create a terminal and type vglconnect -s viz00x where, at this time x =2, or 3.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs). <br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
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<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=867VNC2020-09-04T12:52:30Z<p>Kjansen: /* Windows */</p>
<hr />
<div>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. <br />
<br />
'''Warning: The vnc password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
Portal1 is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from start_vnc.sh. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It's okay to leave your VNC session running on portal1. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's vnc port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
Portal1 is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the "vglrun" command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from portal1. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are viz002 and viz003 (viz001 is probably never coming back to life).<br />
portal1 doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command vglrun. You can test that you have it setup right<br />
with the toyapp glxgears as follows<br />
<br />
vglrun glxgears<br />
<br />
<br />
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).<br />
<br />
NOTE ALSO: The primary purpose for viz003 is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
Portal1 uses TurboVNC from the VirtualGL project, available from http://www.virtualgl.org/Downloads/TurboVNC<br />
<br />
Other VNC viewers will also work, such as TightVNC and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Windows == <br />
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/<br />
<br />
When you open putty, enter jumpgate-phasta.colorado.edu 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 -L59xy:portal1:59zw jumpgate-phasta.colorado.edu" on your machine. Those instructions are OK but a better practice is to ignore what that script suggested for xy (it always suggests 05 currently) and instead use "ssh -L59zw:portal1:59zw jumpgate-phasta.colorado.edu" where zw varies for each new session created. If you get 23 that just means there were 22 sessions created before you created this one but the plan is for you to keep using 23 for a long time (usually until the machine gets rebooted which can be a year or more in some cases). Enter 59zw in the "Source port" box. Enter portal1:59zw in the Destination box (starting and '''click the add button'''. Putty is a little strange about saving the session which you want to do to avoid having to do all the above every time you re-connect. BEFORE you click the Open button, you want to name your session (your choice) and click save. Then in the future when you start putty you should be able to just click that saved session name and click load. Then click "Open" and login as normal. You will then be able to use a vncviewer as instructed by the script.<br />
<br />
Example:<br />
<br />
The script says:<br />
ssh -L5905:portal1:5923 jumpgate-phasta.colorado.edu<br />
your "zw" from the instructions above is 23<br />
enter 5923 in the Source port box<br />
enter portal1:5923 in the destination box.<br />
<br />
Try using this viewer utility<br />
http://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_x86_viewer.zip<br />
<br />
'''Connecting to your VNC with PuTTY'''<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59zw.<br />
## To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
## To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>x@jumpgate-phasta.colorado.edu:22</code>, where <code>x</code> is your username on jumpgate, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59xx</code> and destination port <code>portal1:59xx</code>, where <code>xx</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". We select <code>local</code> because we have a service (VNC Server) running on a machine (portal1) that can be reached from the remote machine (jumpgate), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between localhost and jumpgate, and tunneling localhost:59xx to portal1:59xx via this connection.<br />
# Open RealVNC, and connect to <code>localhost:xx</code>, which is shorthand for <code>localhost:59xx</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>xx</code> is assumed to be port <code>59xx</code>.<br />
# You should now have access to your desktop on portal1. DON'T FORGET-- no meshing, solving, postprocessing, EVEN MATLAB on portal1. To run memory and/or processor and/or graphics intensive jobs you need to create a terminal and type vglconnect -s viz00x where, at this time x =2, or 3.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs). <br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
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<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=866VNC2020-09-04T12:37:51Z<p>Kjansen: </p>
<hr />
<div>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. <br />
<br />
'''Warning: The vnc password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
Portal1 is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from start_vnc.sh. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It's okay to leave your VNC session running on portal1. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's vnc port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop. Most users will never need to do this as the idea is to create one session and continue to use that one for all future usage.<br />
<br />
<br />
== OpenGL == <br />
<br />
Portal1 is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the "vglrun" command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from portal1. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are viz002 and viz003 (viz001 is probably never coming back to life).<br />
portal1 doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command vglrun. You can test that you have it setup right<br />
with the toyapp glxgears as follows<br />
<br />
vglrun glxgears<br />
<br />
<br />
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).<br />
<br />
NOTE ALSO: The primary purpose for viz003 is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
Portal1 uses TurboVNC from the VirtualGL project, available from http://www.virtualgl.org/Downloads/TurboVNC<br />
<br />
Other VNC viewers will also work, such as TightVNC and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Windows == <br />
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/<br />
<br />
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????:portal1:???? 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 portal1) 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.<br />
<br />
Example:<br />
<br />
The script says:<br />
ssh -L5905:portal1:5900 jumpgate-phasta.colorado.edu<br />
enter 5905 in the Source port box<br />
enter portal1:5900 in the destination box.<br />
<br />
Try using this viewer utility<br />
http://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_x86_viewer.zip<br />
<br />
'''Connecting to your VNC with PuTTY'''<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59xx.<br />
## To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
## To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>x@jumpgate-phasta.colorado.edu:22</code>, where <code>x</code> is your username on jumpgate, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59xx</code> and destination port <code>portal1:59xx</code>, where <code>xx</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". We select <code>local</code> because we have a service (VNC Server) running on a machine (portal1) that can be reached from the remote machine (jumpgate), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between localhost and jumpgate, and tunneling localhost:59xx to portal1:59xx via this connection.<br />
# Open RealVNC, and connect to <code>localhost:xx</code>, which is shorthand for <code>localhost:59xx</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>xx</code> is assumed to be port <code>59xx</code>.<br />
# You should now have access to your desktop on portal1.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs). <br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
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<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Tutorial_Video_Overviews&diff=851Tutorial Video Overviews2020-09-03T20:51:37Z<p>Kjansen: </p>
<hr />
<div>Learning to use PHASTA involves a lot of non-trivial steps, each that have a significant learning curve. Videos are a natural way to learn but we have accumulated a lot of them and this makes it daunting to start. The purpose of this page is to organize and index that knowledge and make it more enabling to self-paced learning.<br />
<br />
Here are notes going over the contents of the [https://fluid.colorado.edu/tutorials/ different tutorial videos] with the goal of helping others find tutorial videos of use to them.<br />
<br />
See [[#Meta|Meta]] for details on adding new entries.<br />
<br />
<br />
== Video Table ==<br />
{| class="wikitable"<br />
! Video Name<br />
! Date<br />
! Software Used<br />
! Description<br />
! More Notes<br />
! Misc. Tags<br />
|-<br />
| [https://fluid.colorado.edu/tutorials/RajDemo.mov Raj_demo.mov]<br />
| 2019-05-12<br />
| SimModeler, vglconnect<br />
|<br />
* Overview of using portal1/viznodes, how/when to use vglconnect etc (first ~10 minutes)<br />
* Use of SimModeler for creating unstructured mesh of a windtunnel<br />
| N/A<br />
| viznode, meshing<br />
|-<br />
| [https://fluid.colorado.edu/tutorials/MatLabMeshAndConvert.mov MatLabMeshAndConvert.mov]<br />
| 2019-09-09<br />
| Matlab, StructMesh_Channel.m, runMatchedNodeElmReader.sh<br />
| <br />
* Using Riccardo's Matlab script (StructMesh_Channel.m) to create structured mesh for LES_DNS simulation<br />
* Converting that mesh for use with Chef using runMatchedNodeElmReader.sh<br />
| [[#MatLabMeshAndConvert.mov|Jump to Notes Below]]<br />
| Channel, Bump, meshing<br />
|-<br />
| [https://fluid.colorado.edu/tutorials/SpanWiseAveragingPostProcessing.mov SpanWiseAveragingPostProcessing.mov]<br />
| 2020-02-11<br />
| Matlab, Spanwise averaging Matlab scripts, PHASTA<br />
| <br />
* Viewing required settings for PHASTA to create spanwise averaged statistic files<br />
* Using Riccardo's Matlab script to take those files and plot them<br />
| N/A<br />
| post-processing <br />
|}<br />
<br />
<br />
== Video Notes ==<br />
<br />
=== MatLabMeshAndConvert.mov ===<br />
<br />
==== Time Stamps ====<br />
{| class="wikitable"<br />
! Time<br />
! Notes<br />
|-<br />
| 0:00<br />
| Begin reviewing code of the Matlab scripts<br />
|-<br />
| 10:30<br />
| Run Example Script<br />
|- <br />
| 12:45<br />
| Observing the files generated by Matlab<br />
|- <br />
| 13:40<br />
| Discussion of using <code>matchedNodeElmReader</code><br />
|- <br />
| 14:50<br />
| Running of <code>runMatchedNodeElmReader.sh</code> script<br />
|- <br />
| 16:10<br />
| Viewing mesh in Paraview<br />
|}<br />
<br />
==== Notes ====<br />
Create structured meshes using Matlab script created by Riccardo and other tools. <br />
Matlab script defines the "values" of the mesh to be generated, while <code>matchedNodeElmReader</code> actually generates the mesh files themselves.<br />
<br />
Note that <code>matchedNodeElmReader</code> may also be referred to/named as <code>streamMds</code>.<br />
<br />
Result of Matlab script is 5 different files:<br />
{| class="wikitable"<br />
| <code>*.crd</code><br />
| Coordinates of each vertex<br />
|-<br />
| <code>*.class</code><br />
| Classification with respect to the geometrical model (a box in this case)<br />
|-<br />
| <code>*.cnn</code><br />
| Connectivity of each element<br />
|-<br />
| <code>*.fathers2D</code><br />
| 2D grid of the fathers, Used in spanwise averaging<br />
|-<br />
| <code>*.match</code><br />
| "vertex matching flag" for periodic boundary conditions<br />
|}<br />
<br />
<code>matchedNodeElmReader</code> then takes these files as input and generates two directories: <code>outMesh</code> and <code>rendered</code>.<br />
The <code>rendered</code> is a way to view the mesh in Paraview.<br />
<br />
The code is run with:<br />
mpirun -np 1 matchedNodeElmReader *.cnn *.crd *.match *.class *.fathers2D output_model.dmg outputMeshDir/<br />
<br />
where in the tutorial <code>matchedNodeElmReader</code> is located at <code>/users/rbalin/matchedReader/build-addNfathDebug/test/matchedNodeElnReader</code>.<br />
The mesh files (SCOREC Mesh, <code>*.smb</code>) are then placed inside the output mesh directory.<br />
A usage message can be shown by running the executable without any arguments.<br />
<br />
This command can also be run with multiple MPI processes. Note that this process does "preliminary" partitioning, so the number of mpi processes used is the number of <code>*.smd</code>. The nodes are stored in z, y, x major order (which is generally spanwise, wall-normal, streamwise order), so Riccardo recommends that the number of mpi processes be evenly divisible by the number of streamwise nodes such that these partitions are not divided unevenly.<br />
<br />
Once this is done, the <code>*.smb</code> and <code>*.dmg</code> files are fed to Chef for further partitioning and processing.<br />
<br />
== Meta ==<br />
<br />
==== Editing the Wiki Page ====<br />
Just login to the wiki (click the login button at the top right of the page) and click the edit tab at the top of the page. Login information will be the same as your ''original'' login for jumpgate (the wiki password is not updated with your jumpgate password if you changed it)<br />
<br />
==== Filling in New Entries ====<br />
<br />
{| class="wikitable"<br />
! Video Name<br />
! Date<br />
! Software Used<br />
! Description<br />
! Misc. Tags<br />
|-<br />
| Should be the exact name of the video file and should have a link to the actual video.<br />
| ISO format (YYYY-MM-DD)<br />
| List of software used, including relevant scripts<br />
| Short description of what was done in the video<br />
| Place for random key words that don't fit in other categories (ie. used for using the browsers search function)<br />
|}</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Interpolate_Solution_from_Different_Mesh&diff=787Interpolate Solution from Different Mesh2020-07-26T14:11:46Z<p>Kjansen: /* 1. Create CSV */</p>
<hr />
<div>This will be a general page for how to interpolate solutions from different meshes onto a new mesh. <br />
Those meshes are assumed to be of the same domain. <br />
<br />
The generic terms for the two meshes are "source" and "target", where source has the desired solution data and target is the mesh that will be receiving. <br />
<br />
<br />
== "Structured" Mesh Methodology ==<br />
This section will assume that the source mesh is in a structured ijk form. In the future, this may be expanded to meshes created by MGEN.<br />
<br />
=== Process Overview ===<br />
<br />
First, a CSV of the solution must be created. This must be done on a serial running version of ParaView '''and''' must be done after a MergeBlocks filter is done.<br />
<br />
Second, a special solution file is created via <code>Sort2StructuredGrid</code>, which will take in the csv from step 1 and the ordered coordinates of the source file from Matlab. Effectively, it creates a single solution file in the same ordering as the Matlab points. The importance of this is significant as the executable used in the next step depends on some expected ordering. If the ordering is different, a new executable will need to be used/created. <br />
<br />
Third, the interpolation is performed onto the new grid via <code>par3DInterp3</code>, which creates <code>solInterp.<1-nparts></code> files in the <code>solnTarget</code> directory.<br />
<br />
Fourth, the interpolation is then used by PHASTA by setting <code>Load and set 3D IC: True</code> in the <code>solver.inp</code>. This should only be done for 1 timestep, as it will continue to reset the IC for all proceeding timesteps. The <code>solnTarget</code> directory needs to be symlinked into the <code>-procs_case</code> directory for this to work.<br />
<br />
==== 1. Create CSV ====<br />
<br />
* Created using ParaView<br />
* PV must be running in Serial mode<br />
** Otherwise the CSV will not be in the correct order and possibly have duplicated points<br />
# Load in source dataset<br />
# Apply Mergeblocks filter<br />
# Save dataset as a csv with 12 digits of precision in scientific notation<br />
# Take csv make sure it is in "pressure, u0, u1, u2, x0, x1, x2" format<br />
# Though the next step looks for a .csv extension, it is a fortran formatted read and actually needs those commas replaced by spaces so edit them out with vi or sed -i 's/,/\ /g' test.csv<br />
# Note you also need to delete the first line of this file for the next program. Again, could be done in vi or sed ( sed -i 1,1d test.csv) or tail (tail -n +2 test.csv > trimmedLine1.csv) or, better yet, we should change the next code to read past that header line and then delete this line when that is complete. We should also consider the top answer here https://stackoverflow.com/questions/46444414/how-to-read-my-csv-file-in-fortran as it shows how to make a data structure that could read the csv lines directly in the next program and avoid ALL this file manipulation with modern fortran (see HighPerformanceMark's answer).<br />
<br />
==== 2. Create Structured Solution File ====<br />
'''Note:''' These instructions will be for the <code>parallelSortDNSzBinJames</code> executable, which has some highly specific requirements and command inputs. <br />
<br />
This step will take the data from the source solution file and put it in an format/order that will make the interpolation process work much faster.<br />
<br />
# Symlink the sources ordered coordinate file as <code>ordered.crd</code><br />
# Rename/symlink csv to be the correct file name (in my specific case, it was <code>dnsSolution1procLongFort.csv</code>)<br />
# Create an interactive job on whatever machine you're needing to run on (ALCF Cooley in this case)<br />
# Load approriate MPI environment variables (<code>soft add +mvapich2</code> for Cooley)<br />
# Run the executable via <code>mpirun -np [nprocs] [executable path] [executable inputs]</code> <br />
#* This will produce <code>source.sln.{1..nprocs}</code> files<br />
# Concatenate <code>source.sln.{1..nprocs}</code> files '''in order''' into single <code>source.sln</code> file<br />
#* The individual <code>source.sln.{1..nprocs}</code> files need to be concatenated into a single <code>solution.sln</code> file, which can be done (in zsh at least) via <code>echo source.sln.{1..[MPIRanks]}| xargs cat > source.sln</code> (or probably equivalent <code>cat source.sln.{1..[MPIRanks]} > source.sln</code>). Note these files '''must''' be concatenated in order of rank, otherwise it will be out of sequence.<br />
<br />
<br />
'''Example Command:''' <code>mpirun -np 24 /lus/theta-fs0/projects/PHASTA_aesp/Utilities/Sort2StructuredGrid/parallelSortDNSzBinJames 47822547 47822547 212 0.0291</code><br />
<br />
* The inputs for this command are <code>[nlines of csv] [nlines of ordered.crd] [number of element in z] [z domain width]</code><br />
* '''Note:''' These inputs are specfic to this executable. Changing executable will change which is used<br />
* Also note that the <code>[number of elements in z]</code> is equivalent to <code>nsons</code> - 1 or the number of nodes in z - 1.<br />
<br />
==== 3. Create Interpolated files ====<br />
<br />
This step will create the <code>solInterp.[target nprocs]</code> files used by PHASTA to perform the interpolation.<br />
<br />
# Create <code>Interpolate...</code> directory in the target's Chef directory<br />
# Symlink the <code>coords.[target nprocs]</code> files (that were created by Chef) to the a directory called <code>coordsTarget</code> <br />
#* Note that it's been common practice to put these files in a directory called <code>Coords</code> within a Chef directory. In that case, just symlink the whole directory<br />
# Create a directory called <code>solnTarget</code><br />
#* This may be corrected in the future, but currently if <code>solnTarget</code> is not present the job will fail<br />
# Symlink the <code>source.sln</code> to the directory and the <code>ordered.crd</code> file as <code>source.crd</code><br />
# Run the interpolation executable via mpirun on an interactive job.<br />
# This creates a series of <code>solInterp.[target nprocs]</code> files in the <code>solnTarget</code> directory<br />
<br />
'''Example Command:''' <code>mpirun -np 64 $ph_aesp/Utilities/Intpolate/par3DInterp3 16 799 281 213</code><br />
<br />
* The inputs for this command are <code>[target parts per MPIProc] [source nx] [source ny] [source nz]</code><br />
* Note that the number of processes given to <code>mpirun</code> times the <code>[target parts per MPIProc]</code> must be equal to the number of target partitions. In this case, the target partition was 1024, so 64*16 = 1024<br />
* The way it works is that each of the 64 MPIProcs is given 16 partitions to interpolate.<br />
<br />
==== 4. Interpolate the solution in PHASTA ====<br />
<br />
This step will take the <code>solInterp.[target nprocs]</code> files and load them as initial conditions.<br />
<br />
# Symlink the <code>solnTarget</code> directory into the <code>[target nprocs]-procs_case</code> directory. <br />
# Add/uncomment <code>Load and set 3D IC: True</code> in the <code>solver.inp</code> <br />
# Run PHASTA for a few timesteps and write out <code>restart-dat.[target nprocs]</code> files<br />
# Remove/comment out the <code>Load and set 3D IC: True</code> line from the <code>solver.inp</code><br />
# The new restart files have the interpolated solution<br />
#* Note that if you forget to remove the <code>Load and set 3D IC: True</code> statement from <code>solver.inp</code>, PHASTA will overwrite the existing solution in the restart files</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Interpolate_Solution_from_Different_Mesh&diff=786Interpolate Solution from Different Mesh2020-07-26T13:56:43Z<p>Kjansen: /* 1. Create CSV */</p>
<hr />
<div>This will be a general page for how to interpolate solutions from different meshes onto a new mesh. <br />
Those meshes are assumed to be of the same domain. <br />
<br />
The generic terms for the two meshes are "source" and "target", where source has the desired solution data and target is the mesh that will be receiving. <br />
<br />
<br />
== "Structured" Mesh Methodology ==<br />
This section will assume that the source mesh is in a structured ijk form. In the future, this may be expanded to meshes created by MGEN.<br />
<br />
=== Process Overview ===<br />
<br />
First, a CSV of the solution must be created. This must be done on a serial running version of ParaView '''and''' must be done after a MergeBlocks filter is done.<br />
<br />
Second, a special solution file is created via <code>Sort2StructuredGrid</code>, which will take in the csv from step 1 and the ordered coordinates of the source file from Matlab. Effectively, it creates a single solution file in the same ordering as the Matlab points. The importance of this is significant as the executable used in the next step depends on some expected ordering. If the ordering is different, a new executable will need to be used/created. <br />
<br />
Third, the interpolation is performed onto the new grid via <code>par3DInterp3</code>, which creates <code>solInterp.<1-nparts></code> files in the <code>solnTarget</code> directory.<br />
<br />
Fourth, the interpolation is then used by PHASTA by setting <code>Load and set 3D IC: True</code> in the <code>solver.inp</code>. This should only be done for 1 timestep, as it will continue to reset the IC for all proceeding timesteps. The <code>solnTarget</code> directory needs to be symlinked into the <code>-procs_case</code> directory for this to work.<br />
<br />
==== 1. Create CSV ====<br />
<br />
* Created using ParaView<br />
* PV must be running in Serial mode<br />
** Otherwise the CSV will not be in the correct order and possibly have duplicated points<br />
# Load in source dataset<br />
# Apply Mergeblocks filter<br />
# Save dataset as a csv with 12 digits of precision in scientific notation<br />
# Take csv make sure it is in "pressure, u0, u1, u2, x0, x1, x2" format<br />
# Though the next step looks for a .csv extension, it is a fortran formatted read and actually needs those commas replaced by spaces so edit them out with vi or sed -i 's/,/\ /g' test.csv<br />
# Note you also need to delete the first line of this file for the next program. Again, could be done in vi or sed ( sed -i 1,1d test.csv) or tail (tail -n +2 test.csv > trimmedLine1.csv) or, better yet, we should change the next code to read past that header line and then delete this line when that is complete.<br />
<br />
==== 2. Create Structured Solution File ====<br />
'''Note:''' These instructions will be for the <code>parallelSortDNSzBinJames</code> executable, which has some highly specific requirements and command inputs. <br />
<br />
This step will take the data from the source solution file and put it in an format/order that will make the interpolation process work much faster.<br />
<br />
# Symlink the sources ordered coordinate file as <code>ordered.crd</code><br />
# Rename/symlink csv to be the correct file name (in my specific case, it was <code>dnsSolution1procLongFort.csv</code>)<br />
# Create an interactive job on whatever machine you're needing to run on (ALCF Cooley in this case)<br />
# Load approriate MPI environment variables (<code>soft add +mvapich2</code> for Cooley)<br />
# Run the executable via <code>mpirun -np [nprocs] [executable path] [executable inputs]</code> <br />
#* This will produce <code>source.sln.{1..nprocs}</code> files<br />
# Concatenate <code>source.sln.{1..nprocs}</code> files '''in order''' into single <code>source.sln</code> file<br />
#* The individual <code>source.sln.{1..nprocs}</code> files need to be concatenated into a single <code>solution.sln</code> file, which can be done (in zsh at least) via <code>echo source.sln.{1..[MPIRanks]}| xargs cat > source.sln</code> (or probably equivalent <code>cat source.sln.{1..[MPIRanks]} > source.sln</code>). Note these files '''must''' be concatenated in order of rank, otherwise it will be out of sequence.<br />
<br />
<br />
'''Example Command:''' <code>mpirun -np 24 /lus/theta-fs0/projects/PHASTA_aesp/Utilities/Sort2StructuredGrid/parallelSortDNSzBinJames 47822547 47822547 212 0.0291</code><br />
<br />
* The inputs for this command are <code>[nlines of csv] [nlines of ordered.crd] [number of element in z] [z domain width]</code><br />
* '''Note:''' These inputs are specfic to this executable. Changing executable will change which is used<br />
* Also note that the <code>[number of elements in z]</code> is equivalent to <code>nsons</code> - 1 or the number of nodes in z - 1.<br />
<br />
==== 3. Create Interpolated files ====<br />
<br />
This step will create the <code>solInterp.[target nprocs]</code> files used by PHASTA to perform the interpolation.<br />
<br />
# Create <code>Interpolate...</code> directory in the target's Chef directory<br />
# Symlink the <code>coords.[target nprocs]</code> files (that were created by Chef) to the a directory called <code>coordsTarget</code> <br />
#* Note that it's been common practice to put these files in a directory called <code>Coords</code> within a Chef directory. In that case, just symlink the whole directory<br />
# Create a directory called <code>solnTarget</code><br />
#* This may be corrected in the future, but currently if <code>solnTarget</code> is not present the job will fail<br />
# Symlink the <code>source.sln</code> to the directory and the <code>ordered.crd</code> file as <code>source.crd</code><br />
# Run the interpolation executable via mpirun on an interactive job.<br />
# This creates a series of <code>solInterp.[target nprocs]</code> files in the <code>solnTarget</code> directory<br />
<br />
'''Example Command:''' <code>mpirun -np 64 $ph_aesp/Utilities/Intpolate/par3DInterp3 16 799 281 213</code><br />
<br />
* The inputs for this command are <code>[target parts per MPIProc] [source nx] [source ny] [source nz]</code><br />
* Note that the number of processes given to <code>mpirun</code> times the <code>[target parts per MPIProc]</code> must be equal to the number of target partitions. In this case, the target partition was 1024, so 64*16 = 1024<br />
* The way it works is that each of the 64 MPIProcs is given 16 partitions to interpolate.<br />
<br />
==== 4. Interpolate the solution in PHASTA ====<br />
<br />
This step will take the <code>solInterp.[target nprocs]</code> files and load them as initial conditions.<br />
<br />
# Symlink the <code>solnTarget</code> directory into the <code>[target nprocs]-procs_case</code> directory. <br />
# Add/uncomment <code>Load and set 3D IC: True</code> in the <code>solver.inp</code> <br />
# Run PHASTA for a few timesteps and write out <code>restart-dat.[target nprocs]</code> files<br />
# Remove/comment out the <code>Load and set 3D IC: True</code> line from the <code>solver.inp</code><br />
# The new restart files have the interpolated solution<br />
#* Note that if you forget to remove the <code>Load and set 3D IC: True</code> statement from <code>solver.inp</code>, PHASTA will overwrite the existing solution in the restart files</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Interpolate_Solution_from_Different_Mesh&diff=785Interpolate Solution from Different Mesh2020-07-26T13:51:52Z<p>Kjansen: /* 1. Create CSV */</p>
<hr />
<div>This will be a general page for how to interpolate solutions from different meshes onto a new mesh. <br />
Those meshes are assumed to be of the same domain. <br />
<br />
The generic terms for the two meshes are "source" and "target", where source has the desired solution data and target is the mesh that will be receiving. <br />
<br />
<br />
== "Structured" Mesh Methodology ==<br />
This section will assume that the source mesh is in a structured ijk form. In the future, this may be expanded to meshes created by MGEN.<br />
<br />
=== Process Overview ===<br />
<br />
First, a CSV of the solution must be created. This must be done on a serial running version of ParaView '''and''' must be done after a MergeBlocks filter is done.<br />
<br />
Second, a special solution file is created via <code>Sort2StructuredGrid</code>, which will take in the csv from step 1 and the ordered coordinates of the source file from Matlab. Effectively, it creates a single solution file in the same ordering as the Matlab points. The importance of this is significant as the executable used in the next step depends on some expected ordering. If the ordering is different, a new executable will need to be used/created. <br />
<br />
Third, the interpolation is performed onto the new grid via <code>par3DInterp3</code>, which creates <code>solInterp.<1-nparts></code> files in the <code>solnTarget</code> directory.<br />
<br />
Fourth, the interpolation is then used by PHASTA by setting <code>Load and set 3D IC: True</code> in the <code>solver.inp</code>. This should only be done for 1 timestep, as it will continue to reset the IC for all proceeding timesteps. The <code>solnTarget</code> directory needs to be symlinked into the <code>-procs_case</code> directory for this to work.<br />
<br />
==== 1. Create CSV ====<br />
<br />
* Created using ParaView<br />
* PV must be running in Serial mode<br />
** Otherwise the CSV will not be in the correct order and possibly have duplicated points<br />
# Load in source dataset<br />
# Apply Mergeblocks filter<br />
# Save dataset as a csv with 12 digits of precision in scientific notation<br />
# Take csv make sure it is in "pressure, u0, u1, u2, x0, x1, x2" format<br />
# Though the next step looks for a .csv extension, it is a fortran formatted read and actually needs those commas replaced by spaces so edit them out with vi or sed -i 's/,/\ /g' test.csv<br />
# Note you also need to delete the first line of this file for the next program. Again, could be done in vi or sed ( sed -i 1,1d test.csv) or tail (tail -n +1 test.csv) or, better yet, we should change the next code to read past that header line and then delete this line when that is complete.<br />
<br />
==== 2. Create Structured Solution File ====<br />
'''Note:''' These instructions will be for the <code>parallelSortDNSzBinJames</code> executable, which has some highly specific requirements and command inputs. <br />
<br />
This step will take the data from the source solution file and put it in an format/order that will make the interpolation process work much faster.<br />
<br />
# Symlink the sources ordered coordinate file as <code>ordered.crd</code><br />
# Rename/symlink csv to be the correct file name (in my specific case, it was <code>dnsSolution1procLongFort.csv</code>)<br />
# Create an interactive job on whatever machine you're needing to run on (ALCF Cooley in this case)<br />
# Load approriate MPI environment variables (<code>soft add +mvapich2</code> for Cooley)<br />
# Run the executable via <code>mpirun -np [nprocs] [executable path] [executable inputs]</code> <br />
#* This will produce <code>source.sln.{1..nprocs}</code> files<br />
# Concatenate <code>source.sln.{1..nprocs}</code> files '''in order''' into single <code>source.sln</code> file<br />
#* The individual <code>source.sln.{1..nprocs}</code> files need to be concatenated into a single <code>solution.sln</code> file, which can be done (in zsh at least) via <code>echo source.sln.{1..[MPIRanks]}| xargs cat > source.sln</code> (or probably equivalent <code>cat source.sln.{1..[MPIRanks]} > source.sln</code>). Note these files '''must''' be concatenated in order of rank, otherwise it will be out of sequence.<br />
<br />
<br />
'''Example Command:''' <code>mpirun -np 24 /lus/theta-fs0/projects/PHASTA_aesp/Utilities/Sort2StructuredGrid/parallelSortDNSzBinJames 47822547 47822547 212 0.0291</code><br />
<br />
* The inputs for this command are <code>[nlines of csv] [nlines of ordered.crd] [number of element in z] [z domain width]</code><br />
* '''Note:''' These inputs are specfic to this executable. Changing executable will change which is used<br />
* Also note that the <code>[number of elements in z]</code> is equivalent to <code>nsons</code> - 1 or the number of nodes in z - 1.<br />
<br />
==== 3. Create Interpolated files ====<br />
<br />
This step will create the <code>solInterp.[target nprocs]</code> files used by PHASTA to perform the interpolation.<br />
<br />
# Create <code>Interpolate...</code> directory in the target's Chef directory<br />
# Symlink the <code>coords.[target nprocs]</code> files (that were created by Chef) to the a directory called <code>coordsTarget</code> <br />
#* Note that it's been common practice to put these files in a directory called <code>Coords</code> within a Chef directory. In that case, just symlink the whole directory<br />
# Create a directory called <code>solnTarget</code><br />
#* This may be corrected in the future, but currently if <code>solnTarget</code> is not present the job will fail<br />
# Symlink the <code>source.sln</code> to the directory and the <code>ordered.crd</code> file as <code>source.crd</code><br />
# Run the interpolation executable via mpirun on an interactive job.<br />
# This creates a series of <code>solInterp.[target nprocs]</code> files in the <code>solnTarget</code> directory<br />
<br />
'''Example Command:''' <code>mpirun -np 64 $ph_aesp/Utilities/Intpolate/par3DInterp3 16 799 281 213</code><br />
<br />
* The inputs for this command are <code>[target parts per MPIProc] [source nx] [source ny] [source nz]</code><br />
* Note that the number of processes given to <code>mpirun</code> times the <code>[target parts per MPIProc]</code> must be equal to the number of target partitions. In this case, the target partition was 1024, so 64*16 = 1024<br />
* The way it works is that each of the 64 MPIProcs is given 16 partitions to interpolate.<br />
<br />
==== 4. Interpolate the solution in PHASTA ====<br />
<br />
This step will take the <code>solInterp.[target nprocs]</code> files and load them as initial conditions.<br />
<br />
# Symlink the <code>solnTarget</code> directory into the <code>[target nprocs]-procs_case</code> directory. <br />
# Add/uncomment <code>Load and set 3D IC: True</code> in the <code>solver.inp</code> <br />
# Run PHASTA for a few timesteps and write out <code>restart-dat.[target nprocs]</code> files<br />
# Remove/comment out the <code>Load and set 3D IC: True</code> line from the <code>solver.inp</code><br />
# The new restart files have the interpolated solution<br />
#* Note that if you forget to remove the <code>Load and set 3D IC: True</code> statement from <code>solver.inp</code>, PHASTA will overwrite the existing solution in the restart files</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Interpolate_Solution_from_Different_Mesh&diff=784Interpolate Solution from Different Mesh2020-07-24T17:55:29Z<p>Kjansen: /* 2. Create Structured Solution File */</p>
<hr />
<div>This will be a general page for how to interpolate solutions from different meshes onto a new mesh. <br />
Those meshes are assumed to be of the same domain. <br />
<br />
The generic terms for the two meshes are "source" and "target", where source has the desired solution data and target is the mesh that will be receiving. <br />
<br />
<br />
== "Structured" Mesh Methodology ==<br />
This section will assume that the source mesh is in a structured ijk form. In the future, this may be expanded to meshes created by MGEN.<br />
<br />
=== Process Overview ===<br />
<br />
First, a CSV of the solution must be created. This must be done on a serial running version of ParaView '''and''' must be done after a MergeBlocks filter is done.<br />
<br />
Second, a special solution file is created via <code>Sort2StructuredGrid</code>, which will take in the csv from step 1 and the ordered coordinates of the source file from Matlab. Effectively, it creates a single solution file in the same ordering as the Matlab points. The importance of this is significant as the executable used in the next step depends on some expected ordering. If the ordering is different, a new executable will need to be used/created. <br />
<br />
Third, the interpolation is performed onto the new grid via <code>par3DInterp3</code>, which creates <code>solInterp.<1-nparts></code> files in the <code>solnTarget</code> directory.<br />
<br />
Fourth, the interpolation is then used by PHASTA by setting <code>Load and set 3D IC: True</code> in the <code>solver.inp</code>. This should only be done for 1 timestep, as it will continue to reset the IC for all proceeding timesteps. The <code>solnTarget</code> directory needs to be symlinked into the <code>-procs_case</code> directory for this to work.<br />
<br />
==== 1. Create CSV ====<br />
<br />
* Created using ParaView<br />
* PV must be running in Serial mode<br />
** Otherwise the CSV will not be in the correct order and possibly have duplicated points<br />
# Load in source dataset<br />
# Apply Mergeblocks filter<br />
# Save dataset as a csv with 12 digits of precision in scientific notation<br />
# Take csv make sure it is in "pressure, u0, u1, u2, x0, x1, x2" format<br />
# Though the next step looks for a .csv extension, it is a fortran formatted read and actually needs those commas replaced by spaces so edit them out with vi or sed -i 's/,/\ /g' test.csv<br />
<br />
==== 2. Create Structured Solution File ====<br />
'''Note:''' These instructions will be for the <code>parallelSortDNSzBinJames</code> executable, which has some highly specific requirements and command inputs. <br />
<br />
This step will take the data from the source solution file and put it in an format/order that will make the interpolation process work much faster.<br />
<br />
# Symlink the sources ordered coordinate file as <code>ordered.crd</code><br />
# Rename/symlink csv to be the correct file name (in my specific case, it was <code>dnsSolution1procLongFort.csv</code>)<br />
# Create an interactive job on whatever machine you're needing to run on (ALCF Cooley in this case)<br />
# Load approriate MPI environment variables (<code>soft add +mvapich2</code> for Cooley)<br />
# Run the executable via <code>mpirun -np [nprocs] [executable path] [executable inputs]</code> <br />
#* This will produce <code>source.sln.{1..nprocs}</code> files<br />
# Concatenate <code>source.sln.{1..nprocs}</code> files '''in order''' into single <code>source.sln</code> file<br />
#* The individual <code>source.sln.{1..nprocs}</code> files need to be concatenated into a single <code>solution.sln</code> file, which can be done (in zsh at least) via <code>echo source.sln.{1..[MPIRanks]}| xargs cat > source.sln</code> (or probably equivalent <code>cat source.sln.{1..[MPIRanks]} > source.sln</code>). Note these files '''must''' be concatenated in order of rank, otherwise it will be out of sequence.<br />
<br />
<br />
'''Example Command:''' <code>mpirun -np 24 /lus/theta-fs0/projects/PHASTA_aesp/Utilities/Sort2StructuredGrid/parallelSortDNSzBinJames 47822547 47822547 212 0.0291</code><br />
<br />
* The inputs for this command are <code>[nlines of csv] [nlines of ordered.crd] [number of element in z] [z domain width]</code><br />
* '''Note:''' These inputs are specfic to this executable. Changing executable will change which is used<br />
* Also note that the <code>[number of elements in z]</code> is equivalent to <code>nsons</code> - 1 or the number of nodes in z - 1.<br />
<br />
==== 3. Create Interpolated files ====<br />
<br />
This step will create the <code>solInterp.[target nprocs]</code> files used by PHASTA to perform the interpolation.<br />
<br />
# Create <code>Interpolate...</code> directory in the target's Chef directory<br />
# Symlink the <code>coords.[target nprocs]</code> files (that were created by Chef) to the a directory called <code>coordsTarget</code> <br />
#* Note that it's been common practice to put these files in a directory called <code>Coords</code> within a Chef directory. In that case, just symlink the whole directory<br />
# Create a directory called <code>solnTarget</code><br />
#* This may be corrected in the future, but currently if <code>solnTarget</code> is not present the job will fail<br />
# Symlink the <code>source.sln</code> to the directory and the <code>ordered.crd</code> file as <code>source.crd</code><br />
# Run the interpolation executable via mpirun on an interactive job.<br />
# This creates a series of <code>solInterp.[target nprocs]</code> files in the <code>solnTarget</code> directory<br />
<br />
'''Example Command:''' <code>mpirun -np 64 $ph_aesp/Utilities/Intpolate/par3DInterp3 16 799 281 213</code><br />
<br />
* The inputs for this command are <code>[target parts per MPIProc] [source nx] [source ny] [source nz]</code><br />
* Note that the number of processes given to <code>mpirun</code> times the <code>[target parts per MPIProc]</code> must be equal to the number of target partitions. In this case, the target partition was 1024, so 64*16 = 1024<br />
* The way it works is that each of the 64 MPIProcs is given 16 partitions to interpolate.<br />
<br />
==== 4. Interpolate the solution in PHASTA ====<br />
<br />
This step will take the <code>solInterp.[target nprocs]</code> files and load them as initial conditions.<br />
<br />
# Symlink the <code>solnTarget</code> directory into the <code>[target nprocs]-procs_case</code> directory. <br />
# Add/uncomment <code>Load and set 3D IC: True</code> in the <code>solver.inp</code> <br />
# Run PHASTA for a few timesteps and write out <code>restart-dat.[target nprocs]</code> files<br />
# Remove/comment out the <code>Load and set 3D IC: True</code> line from the <code>solver.inp</code><br />
# The new restart files have the interpolated solution<br />
#* Note that if you forget to remove the <code>Load and set 3D IC: True</code> statement from <code>solver.inp</code>, PHASTA will overwrite the existing solution in the restart files</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Interpolate_Solution_from_Different_Mesh&diff=783Interpolate Solution from Different Mesh2020-07-24T14:23:03Z<p>Kjansen: /* 1. Create CSV */</p>
<hr />
<div>This will be a general page for how to interpolate solutions from different meshes onto a new mesh. <br />
Those meshes are assumed to be of the same domain. <br />
<br />
The generic terms for the two meshes are "source" and "target", where source has the desired solution data and target is the mesh that will be receiving. <br />
<br />
<br />
== "Structured" Mesh Methodology ==<br />
This section will assume that the source mesh is in a structured ijk form. In the future, this may be expanded to meshes created by MGEN.<br />
<br />
=== Process Overview ===<br />
<br />
First, a CSV of the solution must be created. This must be done on a serial running version of ParaView '''and''' must be done after a MergeBlocks filter is done.<br />
<br />
Second, a special solution file is created via <code>Sort2StructuredGrid</code>, which will take in the csv from step 1 and the ordered coordinates of the source file from Matlab. Effectively, it creates a single solution file in the same ordering as the Matlab points. The importance of this is significant as the executable used in the next step depends on some expected ordering. If the ordering is different, a new executable will need to be used/created. <br />
<br />
Third, the interpolation is performed onto the new grid via <code>par3DInterp3</code>, which creates <code>solInterp.<1-nparts></code> files in the <code>solnTarget</code> directory.<br />
<br />
Fourth, the interpolation is then used by PHASTA by setting <code>Load and set 3D IC: True</code> in the <code>solver.inp</code>. This should only be done for 1 timestep, as it will continue to reset the IC for all proceeding timesteps. The <code>solnTarget</code> directory needs to be symlinked into the <code>-procs_case</code> directory for this to work.<br />
<br />
==== 1. Create CSV ====<br />
<br />
* Created using ParaView<br />
* PV must be running in Serial mode<br />
** Otherwise the CSV will not be in the correct order and possibly have duplicated points<br />
# Load in source dataset<br />
# Apply Mergeblocks filter<br />
# Save dataset as a csv with 12 digits of precision in scientific notation<br />
# Take csv make sure it is in "pressure, u0, u1, u2, x0, x1, x2" format<br />
# Though the next step looks for a .csv extension, it is a fortran formatted read and actually needs those commas replaced by spaces so edit them out with vi or sed -i 's/,/\ /g' test.csv<br />
<br />
==== 2. Create Structured Solution File ====<br />
'''Note:''' These instructions will be for the <code>parallelSortDNSzBinJames</code> executable, which has some highly specific requirements and command inputs. <br />
<br />
This step will take the data from the source solution file and put it in an format/order that will make the interpolation process work much faster.<br />
<br />
# Symlink the sources ordered coordinate file as <code>ordered.crd</code><br />
# Rename/symlink csv to be the correct file name (in my specific case, it was <code>dnsSolution1procLongFort.csv</code>)<br />
# Create an interactive job on whatever machine you're needing to run on (ALCF Cooley in this case)<br />
# Load approriate MPI environment variables (<code>soft add +mvapich2</code> for Cooley)<br />
# Run the executable via <code>mpirun -np [nprocs] [executable path] [executable inputs]</code> <br />
#* This will produce <code>source.sln.{1..nprocs}</code> files<br />
# Concatenate <code>source.sln.{1..nprocs}</code> files '''in order''' into single <code>source.sln</code> file<br />
#* The individual <code>solution.sln.{1..nprocs}</code> files need to be concatenated into a single <code>solution.sln</code> file, which can be done (in zsh at least) via <code>echo solution.sln.{1..[MPIRanks]}| xargs cat > solution.sln</code> (or probably equivalent <code>cat solution.sln.{1..[MPIRanks]} > solution.sln</code>). Note these files '''must''' be concatenated in order of rank, otherwise it will be out of sequence.<br />
<br />
<br />
'''Example Command:''' <code>mpirun -np 24 /lus/theta-fs0/projects/PHASTA_aesp/Utilities/Sort2StructuredGrid/parallelSortDNSzBinJames 47822547 47822547 212 0.0291</code><br />
<br />
* The inputs for this command are <code>[nlines of csv] [nlines of ordered.crd] [number of element in z] [z domain width]</code><br />
* '''Note:''' These inputs are specfic to this executable. Changing executable will change which is used<br />
* Also note that the <code>[number of elements in z]</code> is equivalent to <code>nsons</code> - 1 or the number of nodes in z - 1.<br />
<br />
==== 3. Create Interpolated files ====<br />
<br />
This step will create the <code>solInterp.[target nprocs]</code> files used by PHASTA to perform the interpolation.<br />
<br />
# Create <code>Interpolate...</code> directory in the target's Chef directory<br />
# Symlink the <code>coords.[target nprocs]</code> files (that were created by Chef) to the a directory called <code>coordsTarget</code> <br />
#* Note that it's been common practice to put these files in a directory called <code>Coords</code> within a Chef directory. In that case, just symlink the whole directory<br />
# Create a directory called <code>solnTarget</code><br />
#* This may be corrected in the future, but currently if <code>solnTarget</code> is not present the job will fail<br />
# Symlink the <code>source.sln</code> to the directory and the <code>ordered.crd</code> file as <code>source.crd</code><br />
# Run the interpolation executable via mpirun on an interactive job.<br />
# This creates a series of <code>solInterp.[target nprocs]</code> files in the <code>solnTarget</code> directory<br />
<br />
'''Example Command:''' <code>mpirun -np 64 $ph_aesp/Utilities/Intpolate/par3DInterp3 16 799 281 213</code><br />
<br />
* The inputs for this command are <code>[target parts per MPIProc] [source nx] [source ny] [source nz]</code><br />
* Note that the number of processes given to <code>mpirun</code> times the <code>[target parts per MPIProc]</code> must be equal to the number of target partitions. In this case, the target partition was 1024, so 64*16 = 1024<br />
* The way it works is that each of the 64 MPIProcs is given 16 partitions to interpolate.<br />
<br />
==== 4. Interpolate the solution in PHASTA ====<br />
<br />
This step will take the <code>solInterp.[target nprocs]</code> files and load them as initial conditions.<br />
<br />
# Symlink the <code>solnTarget</code> directory into the <code>[target nprocs]-procs_case</code> directory. <br />
# Add/uncomment <code>Load and set 3D IC: True</code> in the <code>solver.inp</code> <br />
# Run PHASTA for a few timesteps and write out <code>restart-dat.[target nprocs]</code> files<br />
# Remove/comment out the <code>Load and set 3D IC: True</code> line from the <code>solver.inp</code><br />
# The new restart files have the interpolated solution<br />
#* Note that if you forget to remove the <code>Load and set 3D IC: True</code> statement from <code>solver.inp</code>, PHASTA will overwrite the existing solution in the restart files</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Interpolate_Solution_from_Different_Mesh&diff=684Interpolate Solution from Different Mesh2020-06-27T18:41:19Z<p>Kjansen: /* 4. Interpolate the solution in PHASTA */</p>
<hr />
<div>This will be a general page for how to interpolate solutions from different meshes onto a new mesh. <br />
Those meshes are assumed to be of the same domain. <br />
<br />
The generic terms for the two meshes are "source" and "target", where source has the desired solution data and target is the mesh that will be receiving. <br />
<br />
<br />
== "Structured" Mesh Methodology ==<br />
This section will assume that the source mesh is in a structured ijk form. In the future, this may be expanded to meshes created by MGEN.<br />
<br />
=== Process Overview ===<br />
<br />
First, a CSV of the solution must be created. This must be done on a serial running version of ParaView '''and''' must be done after a MergeBlocks filter is done.<br />
<br />
Second, a special solution file is created via <code>Sort2StructuredGrid</code>, which will take in the csv from step 1 and the ordered coordinates of the source file from Matlab. Effectively, it creates a single solution file in the same ordering as the Matlab points. The importance of this is significant as the executable used in the next step depends on some expected ordering. If the ordering is different, a new executable will need to be used/created. <br />
<br />
Third, the interpolation is performed onto the new grid via <code>par3DInterp3</code>, which creates <code>solInterp.<1-nparts></code> files in the <code>solnTarget</code> directory.<br />
<br />
Fourth, the interpolation is then used by PHASTA by setting <code>Load and set 3D IC: True</code> in the <code>solver.inp</code>. This should only be done for 1 timestep, as it will continue to reset the IC for all proceeding timesteps. The <code>solnTarget</code> directory needs to be symlinked into the <code>-procs_case</code> directory for this to work.<br />
<br />
==== 1. Create CSV ====<br />
<br />
* Created using ParaView<br />
* PV must be running in Serial mode<br />
** Otherwise the CSV will not be in the correct order and possibly have duplicated points<br />
# Load in source dataset<br />
# Apply Mergeblocks filter<br />
# Save dataset as a csv with 12 digits of precision in scientific notation<br />
# Take csv make sure it is in "pressure, u0, u1, u2, x0, x1, x2" format<br />
<br />
==== 2. Create Structured Solution File ====<br />
'''Note:''' These instructions will be for the <code>parallelSortDNSzBinJames</code> executable, which has some highly specific requirements and command inputs. <br />
<br />
This step will take the data from the source solution file and put it in an format/order that will make the interpolation process work much faster.<br />
<br />
# Symlink the sources ordered coordinate file as <code>ordered.crd</code><br />
# Rename/symlink csv to be the correct file name (in my specific case, it was <code>dnsSolution1procLongFort.csv</code>)<br />
# Create an interactive job on whatever machine you're needing to run on (ALCF Cooley in this case)<br />
# Load approriate MPI environment variables (<code>soft add +mvapich2</code> for Cooley)<br />
# Run the executable via <code>mpirun -np [nprocs] [executable path] [executable inputs]</code> <br />
#* This will produce <code>source.sln.{1..nprocs}</code> files<br />
# Concatenate <code>source.sln.{1..nprocs}</code> files '''in order''' into single <code>source.sln</code> file<br />
#* The individual <code>solution.sln.{1..nprocs}</code> files need to be concatenated into a single <code>solution.sln</code> file, which can be done (in zsh at least) via <code>echo solution.sln.{1..[MPIRanks]}| xargs cat > solution.sln</code> (or probably equivalent <code>cat solution.sln.{1..[MPIRanks]} > solution.sln</code>). Note these files '''must''' be concatenated in order of rank, otherwise it will be out of sequence.<br />
<br />
<br />
'''Example Command:''' <code>mpirun -np 24 /lus/theta-fs0/projects/PHASTA_aesp/Utilities/Sort2StructuredGrid/parallelSortDNSzBinJames 47822547 47822547 212 0.0291</code><br />
<br />
* The inputs for this command are <code>[nlines of csv] [nlines of ordered.crd] [number of element in z] [z domain width]</code><br />
* '''Note:''' These inputs are specfic to this executable. Changing executable will change which is used<br />
* Also note that the <code>[number of elements in z]</code> is equivalent to <code>nsons</code> - 1 or the number of nodes in z - 1.<br />
<br />
==== 3. Create Interpolated files ====<br />
<br />
This step will create the <code>solInterp.[target nprocs]</code> files used by PHASTA to perform the interpolation.<br />
<br />
# Create <code>Interpolate...</code> directory in the target's Chef directory<br />
# Symlink the <code>coords.[target nprocs]</code> files (that were created by Chef) to the a directory called <code>coordsTarget</code> <br />
#* Note that it's been common practice to put these files in a directory called <code>Coords</code> within a Chef directory. In that case, just symlink the whole directory<br />
# Create a directory called <code>solnTarget</code><br />
#* This may be corrected in the future, but currently if <code>solnTarget</code> is not present the job will fail<br />
# Symlink the <code>source.sln</code> to the directory and the <code>ordered.crd</code> file as <code>source.crd</code><br />
# Run the interpolation executable via mpirun on an interactive job.<br />
# This creates a series of <code>solInterp.[target nprocs]</code> files in the <code>solnTarget</code> directory<br />
<br />
'''Example Command:''' <code>mpirun -np 64 $ph_aesp/Utilities/Intpolate/par3DInterp3 16 799 281 213</code><br />
<br />
* The inputs for this command are <code>[parts per MPIProc] [nx] [ny] [nz]</code><br />
* Note that the number of processes given to <code>mpirun</code> times the <code>[parts per MPIProc]</code> must be equal to the number of target partitions. In this case, the target partition was 1024, so 64*16 = 1024<br />
* The way it works is that each of the 64 MPIProcs is given 16 partitions to interpolate.<br />
<br />
==== 4. Interpolate the solution in PHASTA ====<br />
<br />
This step will take the <code>solInterp.[target nprocs]</code> files and load them as initial conditions.<br />
<br />
# Symlink the <code>solnTarget</code> directory into the <code>[target nprocs]-procs_case</code> directory. <br />
# Add/uncomment <code>Load and set 3D IC: True</code> in the <code>solver.inp</code> <br />
# Run PHASTA for a few timesteps and write out <code>restart-dat.[target nprocs]</code> files<br />
# Remove/comment out the <code>Load and set 3D IC: True</code> line from the <code>solver.inp</code><br />
# The new restart files have the interpolated solution<br />
#* Note that if you forget to remove the <code>Load and set 3D IC: True</code> statement from <code>solver.inp</code>, PHASTA will overwrite the existing solution in the restart files</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Interpolate_Solution_from_Different_Mesh&diff=683Interpolate Solution from Different Mesh2020-06-27T18:39:56Z<p>Kjansen: 4</p>
<hr />
<div>This will be a general page for how to interpolate solutions from different meshes onto a new mesh. <br />
Those meshes are assumed to be of the same domain. <br />
<br />
The generic terms for the two meshes are "source" and "target", where source has the desired solution data and target is the mesh that will be receiving. <br />
<br />
<br />
== "Structured" Mesh Methodology ==<br />
This section will assume that the source mesh is in a structured ijk form. In the future, this may be expanded to meshes created by MGEN.<br />
<br />
=== Process Overview ===<br />
<br />
First, a CSV of the solution must be created. This must be done on a serial running version of ParaView '''and''' must be done after a MergeBlocks filter is done.<br />
<br />
Second, a special solution file is created via <code>Sort2StructuredGrid</code>, which will take in the csv from step 1 and the ordered coordinates of the source file from Matlab. Effectively, it creates a single solution file in the same ordering as the Matlab points. The importance of this is significant as the executable used in the next step depends on some expected ordering. If the ordering is different, a new executable will need to be used/created. <br />
<br />
Third, the interpolation is performed onto the new grid via <code>par3DInterp3</code>, which creates <code>solInterp.<1-nparts></code> files in the <code>solnTarget</code> directory.<br />
<br />
Fourth, the interpolation is then used by PHASTA by setting <code>Load and set 3D IC: True</code> in the <code>solver.inp</code>. This should only be done for 1 timestep, as it will continue to reset the IC for all proceeding timesteps. The <code>solnTarget</code> directory needs to be symlinked into the <code>-procs_case</code> directory for this to work.<br />
<br />
==== 1. Create CSV ====<br />
<br />
* Created using ParaView<br />
* PV must be running in Serial mode<br />
** Otherwise the CSV will not be in the correct order and possibly have duplicated points<br />
# Load in source dataset<br />
# Apply Mergeblocks filter<br />
# Save dataset as a csv with 12 digits of precision in scientific notation<br />
# Take csv make sure it is in "pressure, u0, u1, u2, x0, x1, x2" format<br />
<br />
==== 2. Create Structured Solution File ====<br />
'''Note:''' These instructions will be for the <code>parallelSortDNSzBinJames</code> executable, which has some highly specific requirements and command inputs. <br />
<br />
This step will take the data from the source solution file and put it in an format/order that will make the interpolation process work much faster.<br />
<br />
# Symlink the sources ordered coordinate file as <code>ordered.crd</code><br />
# Rename/symlink csv to be the correct file name (in my specific case, it was <code>dnsSolution1procLongFort.csv</code>)<br />
# Create an interactive job on whatever machine you're needing to run on (ALCF Cooley in this case)<br />
# Load approriate MPI environment variables (<code>soft add +mvapich2</code> for Cooley)<br />
# Run the executable via <code>mpirun -np [nprocs] [executable path] [executable inputs]</code> <br />
#* This will produce <code>source.sln.{1..nprocs}</code> files<br />
# Concatenate <code>source.sln.{1..nprocs}</code> files '''in order''' into single <code>source.sln</code> file<br />
#* The individual <code>solution.sln.{1..nprocs}</code> files need to be concatenated into a single <code>solution.sln</code> file, which can be done (in zsh at least) via <code>echo solution.sln.{1..[MPIRanks]}| xargs cat > solution.sln</code> (or probably equivalent <code>cat solution.sln.{1..[MPIRanks]} > solution.sln</code>). Note these files '''must''' be concatenated in order of rank, otherwise it will be out of sequence.<br />
<br />
<br />
'''Example Command:''' <code>mpirun -np 24 /lus/theta-fs0/projects/PHASTA_aesp/Utilities/Sort2StructuredGrid/parallelSortDNSzBinJames 47822547 47822547 212 0.0291</code><br />
<br />
* The inputs for this command are <code>[nlines of csv] [nlines of ordered.crd] [number of element in z] [z domain width]</code><br />
* '''Note:''' These inputs are specfic to this executable. Changing executable will change which is used<br />
* Also note that the <code>[number of elements in z]</code> is equivalent to <code>nsons</code> - 1 or the number of nodes in z - 1.<br />
<br />
==== 3. Create Interpolated files ====<br />
<br />
This step will create the <code>solInterp.[target nprocs]</code> files used by PHASTA to perform the interpolation.<br />
<br />
# Create <code>Interpolate...</code> directory in the target's Chef directory<br />
# Symlink the <code>coords.[target nprocs]</code> files (that were created by Chef) to the a directory called <code>coordsTarget</code> <br />
#* Note that it's been common practice to put these files in a directory called <code>Coords</code> within a Chef directory. In that case, just symlink the whole directory<br />
# Create a directory called <code>solnTarget</code><br />
#* This may be corrected in the future, but currently if <code>solnTarget</code> is not present the job will fail<br />
# Symlink the <code>source.sln</code> to the directory and the <code>ordered.crd</code> file as <code>source.crd</code><br />
# Run the interpolation executable via mpirun on an interactive job.<br />
# This creates a series of <code>solInterp.[target nprocs]</code> files in the <code>solnTarget</code> directory<br />
<br />
'''Example Command:''' <code>mpirun -np 64 $ph_aesp/Utilities/Intpolate/par3DInterp3 16 799 281 213</code><br />
<br />
* The inputs for this command are <code>[parts per MPIProc] [nx] [ny] [nz]</code><br />
* Note that the number of processes given to <code>mpirun</code> times the <code>[parts per MPIProc]</code> must be equal to the number of target partitions. In this case, the target partition was 1024, so 64*16 = 1024<br />
* The way it works is that each of the 64 MPIProcs is given 16 partitions to interpolate.<br />
<br />
==== 4. Interpolate the solution in PHASTA ====<br />
<br />
This step will take the <code>solInterp.[target nprocs]</code> files and load them as initial conditions.<br />
<br />
# Symlink the <code>solnTarget</code> directory into the <code>[target nprocs]-procs_case</code> directory. <br />
# Add/uncomment <code>Load and set 3D IC: True</code> in the <code>solver.inp</code> <br />
# Run PHASTA for 1 timestep and write out <code>restart-dat.[target nprocs]</code> files<br />
# Remove/comment out the <code>Load and set 3D IC: True</code> line from the <code>solver.inp</code><br />
# The new restart files have the interpolated solution<br />
#* Note that if you forget to remove the <code>Load and set 3D IC: True</code> statement from <code>solver.inp</code>, PHASTA will overwrite the existing solution in the restart files</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=615VNC2017-05-19T23:20:18Z<p>Kjansen: </p>
<hr />
<div>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. <br />
<br />
'''Warning: The vnc password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
Portal1 is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from start_vnc.sh. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It's okay to leave your VNC session running on portal1. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's vnc port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop.<br />
<br />
<br />
== OpenGL == <br />
<br />
Portal1 is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the "vglrun" command<br />
vlgrun glxgears<br />
<br />
Our lab has 2 VirtualGL servers you can connect to from portal1. You must connect to one of them for large memory and/or computationally intensive processes.<br />
The names of the servers are viz002 and viz003 (viz001 is probably never coming back to life).<br />
portal1 doesn't have a particularly fast graphics processor and MUST NOT be used for large memory or computationally intensive process)<br />
<br />
vglconnect -s viz002<br />
or<br />
vglconnect -s viz003<br />
<br />
from this connection you will want to run graphic applications (e.g., SimModeler or ParaView) prefaced by the command vglrun. You can test that you have it setup right<br />
with the toyapp glxgears as follows<br />
<br />
vglrun glxgears<br />
<br />
<br />
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).<br />
<br />
NOTE ALSO: The primary purpose for viz003 is for visualization and for debugging. Production runs should be done elsewhere. <br />
<br />
== Clients == <br />
<br />
Portal1 uses TurboVNC from the VirtualGL project, available from http://www.virtualgl.org/Downloads/TurboVNC<br />
<br />
Other VNC viewers will also work, such as TightVNC and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Windows == <br />
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/<br />
<br />
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????:portal1:???? 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 portal1) 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.<br />
<br />
Example:<br />
<br />
The script says:<br />
ssh -L5905:portal1:5900 jumpgate-phasta.colorado.edu<br />
enter 5905 in the Source port box<br />
enter portal1:5900 in the destination box.<br />
<br />
Try using this viewer utility<br />
http://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_x86_viewer.zip<br />
<br />
'''Connecting to your VNC with PuTTY'''<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59xx.<br />
## To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
## To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>x@jumpgate-phasta.colorado.edu:22</code>, where <code>x</code> is your username on jumpgate, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59xx</code> and destination port <code>portal1:59xx</code>, where <code>xx</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". We select <code>local</code> because we have a service (VNC Server) running on a machine (portal1) that can be reached from the remote machine (jumpgate), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between localhost and jumpgate, and tunneling localhost:59xx to portal1:59xx via this connection.<br />
# Open RealVNC, and connect to <code>localhost:xx</code>, which is shorthand for <code>localhost:59xx</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>xx</code> is assumed to be port <code>59xx</code>.<br />
# You should now have access to your desktop on portal1.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs). <br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
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<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=VNC&diff=614VNC2017-05-19T23:09:56Z<p>Kjansen: </p>
<hr />
<div>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. <br />
<br />
'''Warning: The vnc password is transmitted in clear text over the network and should not be considered secure'''<br />
<br />
Portal1 is designated to host VNC sessions.<br />
<br />
<br />
To start a VNC session:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
ssh portal1<br />
source /etc/profile<br />
start_vnc.sh<br />
<br />
Then follow the directions from start_vnc.sh. Make sure to remember your password and port number (59**) so that you can reuse your session.<br />
<br />
It's okay to leave your VNC session running on portal1. Next time you want to access your desktop, just ssh into jumpgate with a tunnel between portal1's vnc port (59**) and some port on your machine. Then use a VNC client to connect to the port on your machine.<br />
<br />
If, for some reason, you want to end your session and kill your virtual desktop, run<br />
<br />
source /etc/profile<br />
stop_vnc.sh # ONLY run this if you want to kill your virtual desktop.<br />
<br />
<br />
== OpenGL == <br />
<br />
Portal1 is equipped with a VirtualGL install which will allow you to use OpenGL programs (which do not use pthreads)<br />
<br />
Simply wrap your OpenGL program with the "vglrun" command<br />
vlgrun glxgears<br />
<br />
If you have access to another VirtualGL server you can connect to it first (Portal1 doesn't have a particularly fast graphics processor)<br />
vglconnect server<br />
vglrun glxgears<br />
<br />
<br />
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)<br />
<br />
== Clients == <br />
<br />
Portal1 uses TurboVNC from the VirtualGL project, available from http://www.virtualgl.org/Downloads/TurboVNC<br />
<br />
Other VNC viewers will also work, such as TightVNC and RealVNC<br />
<br />
== Changing the VNC Password ==<br />
<br />
/opt/tigervnc/bin/vncpasswd<br />
<br />
== View Only Mode == <br />
<br />
To share your desktop with another user in view only mode set a view only password <br />
by running<br />
vncpasswd<br />
<br />
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:<br />
vncviewer -viewonly<br />
<br />
== Windows == <br />
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/<br />
<br />
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????:portal1:???? 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 portal1) 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.<br />
<br />
Example:<br />
<br />
The script says:<br />
ssh -L5905:portal1:5900 jumpgate-phasta.colorado.edu<br />
enter 5905 in the Source port box<br />
enter portal1:5900 in the destination box.<br />
<br />
Try using this viewer utility<br />
http://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_x86_viewer.zip<br />
<br />
'''Connecting to your VNC with PuTTY'''<br />
<br />
Once we SSH to jumpgate (on the default SSH port 22), our main desktop on portal1 can be accessed via a VNC session as follows.<br />
<br />
# The VNC server should already be running on portal1 using port 59xx.<br />
## To check the port, on portal1 run <code>/opt/vnc_script/findsession.sh</code><br />
## To confirm the VNC server is running (and see port), run <code>ps aux | grep vnc</code><br />
# Open PuTTY on your local machine.<br />
# Under "Session", SSH to <code>x@jumpgate-phasta.colorado.edu:22</code>, where <code>x</code> is your username on jumpgate, and <code>22</code> is the standard SSH port.<br />
# Under "Session">"SSH">"Tunnels", select source port <code>59xx</code> and destination port <code>portal1:59xx</code>, where <code>xx</code> is the two-digit number of your VNC session. Select destination <code>local</code> and click "Add". We select <code>local</code> because we have a service (VNC Server) running on a machine (portal1) that can be reached from the remote machine (jumpgate), and we want to access it directly from the <code>local</code> machine.<br />
# Confirm the dialog by clicking "Open", thus establishing an SSH connection between localhost and jumpgate, and tunneling localhost:59xx to portal1:59xx via this connection.<br />
# Open RealVNC, and connect to <code>localhost:xx</code>, which is shorthand for <code>localhost:59xx</code>. VNC ports are enumerated starting with <code>5901</code>, so any two digit port <code>xx</code> is assumed to be port <code>59xx</code>.<br />
# You should now have access to your desktop on portal1.<br />
<br />
== Web Based Viewer ==<br />
<br />
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<br />
<br />
Forward your session through jumpgate as before before, adding a second port, 580n. For example, if the script tells you to <br />
<br />
ssh -L5905:portal1:5902 jumpgate-phasta.colorado.edu you should<br />
ssh -L5902:portal1:5902 -L5802:portal1:5802 jumpgate-phasta.colorado.edu<br />
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)<br />
<br />
== Changing the Size (Resolution) of an Existing Session ==<br />
<br />
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. <br />
<br />
Once you know your screen number, you can see the list of supported modes as follows:<br />
xrandr -display :2<br />
<br />
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<br />
xrandr -s 1400x1050 -display :2<br />
<br />
(this example will set the resolution to 1400 pixels by 1050 pixels)<br />
<br />
You'll probably be disconnected at this point, but when you reconnect your screen size should be changed (hopefully without crashing your running programs). <br />
<br />
== Finding an Existing Session ==<br />
SSH to portal1 and then run:<br />
/opt/vnc_script/findsession.sh<br />
<br />
Which will return the shortened port number of each of your currently running sessions.<br />
<br />
== Troubleshooting == <br />
<br />
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<br />
<br />
stop_vnc.sh may display some errors; this is normal.<br />
<br />
If you have trouble deleting ~/.vnc send an email to Benjamin.A.Matthews@colorado.edu<br />
<br />
If any of these commands fail, you may need to source /etc/profile to get the necessary environment variables (this should be fixed soon)<br />
<br />
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. <br />
<br />
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.<br />
<br />
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<br />
<br />
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<br />
vncviewer -encodings tight -quality 6 -compresslevel 6<br />
If you have trouble with text distortion try adding <br />
-nojpeg<br />
<br />
If you're running OSX and see an error about Zlib, try changing your compression settings (maximum quality usually works) or use a different client. RealVNC and certain versions of ChickenOfTheVNC both exhibit this issue. The latest build of TigerVNC should work reliably, as does the Java based TightVNC client.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=ParaViewOnTukey&diff=600ParaViewOnTukey2016-06-30T23:23:11Z<p>Kjansen: /* Video Tutorial about how to run a pvserver-syncio in parallel on the Tukey visualization nodes and connect the pvserver to a ParaView Gui running on portal0 at Colorado */</p>
<hr />
<div>== Video Tutorial about how to run a pvserver-syncio in parallel on the Tukey visualization nodes and connect the pvserver to a ParaView Gui running on portal0 at Colorado ==<br />
http://fluid.colorado.edu/~mrasquin/Documents_HIDE/Tukey/ParaviewOnTukeyFromPortal0/index.html<br />
<br />
This video can be copied from /users/mrasquin/public_html/Documents_HIDE/Tukey/ParaviewOnTukeyFromPortal0 on the viz nodes.<br />
<br />
== Video Tutorial about how to run a pvserver-syncio in parallel on the Tukey visualization nodes and connect the pvserver to a ParaView Gui running on the Tukey login node ==<br />
http://fluid.colorado.edu/~mrasquin/Tukey/ParaviewOnTukeyThroughVNC/index.html<br />
<br />
This video can be copied from /users/mrasquin/public_html/Tukey/ParaviewOnTukeyThroughVNC on the viz nodes.<br />
<br />
Note that because vncserver on the Tukey head node does not support OpenGL, this method does not allow the export of png pictures from the ParaView Gui. Indeed, the result will be completely fuzzy. The first method is therefore strongly recommended.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Work_Plan_In_Memory_Adapt&diff=570Work Plan In Memory Adapt2015-07-13T02:35:48Z<p>Kjansen: </p>
<hr />
<div>SUMMARY of phases<br />
<br />
phase0= clean syncio (almost there)<br />
<br />
phase1=PHASTA can read AND write both<br />
<br />
phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory data<br />
<br />
phase3=PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields <br />
<br />
phase4= bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)<br />
<br />
phase5=replace UR with local adaptation<br />
<br />
phase6=loop and we are done<br />
<br />
<br />
For the sake of discussion lets group phastaIO functions as follows<br />
<br />
A) init<br />
<br />
B) open-close<br />
<br />
C) read (readheader, readdatablock)<br />
<br />
D) write (writeheader, writedatablock)<br />
<br />
E) finalize<br />
<br />
To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach<br />
where the functions that the PHASTA workflow directly uses to perform IO are:<br />
<br />
# phio_openfileread (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)<br />
# phio_openfilewrite (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)<br />
# phio_readheader<br />
# phio_readdatablock<br />
# phio_writeheader<br />
# phio_writedatablock<br />
# phio_closefile<br />
<br />
These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.<br />
<br />
DETAIL<br />
<br />
phase0<br />
<br />
0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)<br />
<br />
0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.<br />
<br />
0.2' Move query and init into B)<br />
<br />
0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)<br />
<br />
0.4 Repeat 0.1-0.3 for writing of files<br />
<br />
phase1<br />
<br />
1.1 Migrate string constructors into conditional for syncio<br />
<br />
1.2 Create posix counterparts and put them in the posix branch of conditional<br />
<br />
1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)<br />
<br />
1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio<br />
<br />
1.4 Debug to make sure that files written are correct (two successive runs)<br />
<br />
phase2<br />
<br />
2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file<br />
<br />
2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)<br />
<br />
2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote<br />
<br />
phase3<br />
<br />
3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location<br />
<br />
3.2 Create ability to pass the descriptor of that memory location back to Chef<br />
<br />
3.3 Create ability for Chef to read adapt-fields when passed descriptor<br />
<br />
3.4 Invoke a UR with solution transfer and write files to confirm phase3 success<br />
<br />
phase4<br />
<br />
4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)<br />
<br />
phase5<br />
<br />
5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).<br />
<br />
THORNY ISSUES<br />
<br />
phase0<br />
<br />
1) extra write files. Seems to me that there should be either<br />
<br />
a) only 2 write_restart and write_field, or<br />
<br />
b) an init function and then only write_field<br />
<br />
2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)<br />
<br />
3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code<br />
<br />
4) KEJ is still trying to sort out the roles of {query,init}phmpiio. <br />
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)<br />
b) init is called for both reads and writes of syncio files<br />
<br />
preliminary design plan<br />
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)<br />
ii) push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix<br />
openfile, closefile, {read,write}X{header,datablock}</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Work_Plan_In_Memory_Adapt&diff=569Work Plan In Memory Adapt2015-07-13T02:33:49Z<p>Kjansen: </p>
<hr />
<div>SUMMARY of phases<br />
<br />
phase0= clean syncio (almost there)<br />
<br />
phase1=PHASTA can read AND write both<br />
<br />
phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory data<br />
<br />
phase3=PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields <br />
<br />
phase4= bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)<br />
<br />
phase5=replace UR with local adaptation<br />
<br />
phase6=loop and we are done<br />
<br />
<br />
For the sake of discussion lets group phastaIO functions as follows<br />
<br />
A) init<br />
<br />
B) open-close<br />
<br />
C) read (readheader, readdatablock)<br />
<br />
D) write (writeheader, writedatablock)<br />
<br />
E) finalize<br />
<br />
To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach<br />
where the functions that the PHASTA workflow directly uses to perform IO are:<br />
<br />
# phio_openfile (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)<br />
# readheader_phio<br />
# readdatablock_phio<br />
# writeheader_phio<br />
# writedatablock_phio<br />
# closefile_phio<br />
<br />
These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those six wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.<br />
<br />
DETAIL<br />
<br />
phase0<br />
<br />
0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)<br />
<br />
0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.<br />
<br />
0.2' Move query and init into B)<br />
<br />
0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)<br />
<br />
0.4 Repeat 0.1-0.3 for writing of files<br />
<br />
phase1<br />
<br />
1.1 Migrate string constructors into conditional for syncio<br />
<br />
1.2 Create posix counterparts and put them in the posix branch of conditional<br />
<br />
1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)<br />
<br />
1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio<br />
<br />
1.4 Debug to make sure that files written are correct (two successive runs)<br />
<br />
phase2<br />
<br />
2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file<br />
<br />
2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)<br />
<br />
2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote<br />
<br />
phase3<br />
<br />
3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location<br />
<br />
3.2 Create ability to pass the descriptor of that memory location back to Chef<br />
<br />
3.3 Create ability for Chef to read adapt-fields when passed descriptor<br />
<br />
3.4 Invoke a UR with solution transfer and write files to confirm phase3 success<br />
<br />
phase4<br />
<br />
4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)<br />
<br />
phase5<br />
<br />
5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).<br />
<br />
THORNY ISSUES<br />
<br />
phase0<br />
<br />
1) extra write files. Seems to me that there should be either<br />
<br />
a) only 2 write_restart and write_field, or<br />
<br />
b) an init function and then only write_field<br />
<br />
2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)<br />
<br />
3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code<br />
<br />
4) KEJ is still trying to sort out the roles of {query,init}phmpiio. <br />
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)<br />
b) init is called for both reads and writes of syncio files<br />
<br />
preliminary design plan<br />
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)<br />
ii) push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix<br />
openfile, closefile, {read,write}X{header,datablock}</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Work_Plan_In_Memory_Adapt&diff=568Work Plan In Memory Adapt2015-07-12T05:24:51Z<p>Kjansen: </p>
<hr />
<div>SUMMARY of phases<br />
<br />
phase0= clean syncio (almost there)<br />
<br />
phase1=PHASTA can read AND write both<br />
<br />
phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory data<br />
<br />
phase3=PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields <br />
<br />
phase4= bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)<br />
<br />
phase5=replace UR with local adaptation<br />
<br />
phase6=loop and we are done<br />
<br />
<br />
For the sake of discussion lets group phastaIO functions as follows<br />
<br />
A) init<br />
<br />
B) open-close<br />
<br />
C) read (readheader, readdatablock)<br />
<br />
D) write (writeheader, writedatablock)<br />
<br />
E) finalize<br />
<br />
To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach<br />
where the functions that the PHASTA workflow directly uses to perform IO are:<br />
<br />
# openfile_phio (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)<br />
# readheader_phio<br />
# readdatablock_phio<br />
# writeheader_phio<br />
# writedatablock_phio<br />
# closefile_phio<br />
<br />
These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those six wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.<br />
<br />
DETAIL<br />
<br />
phase0<br />
<br />
0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)<br />
<br />
0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.<br />
<br />
0.2' Move query and init into B)<br />
<br />
0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)<br />
<br />
0.4 Repeat 0.1-0.3 for writing of files<br />
<br />
phase1<br />
<br />
1.1 Migrate string constructors into conditional for syncio<br />
<br />
1.2 Create posix counterparts and put them in the posix branch of conditional<br />
<br />
1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)<br />
<br />
1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio<br />
<br />
1.4 Debug to make sure that files written are correct (two successive runs)<br />
<br />
phase2<br />
<br />
2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file<br />
<br />
2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)<br />
<br />
2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote<br />
<br />
phase3<br />
<br />
3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location<br />
<br />
3.2 Create ability to pass the descriptor of that memory location back to Chef<br />
<br />
3.3 Create ability for Chef to read adapt-fields when passed descriptor<br />
<br />
3.4 Invoke a UR with solution transfer and write files to confirm phase3 success<br />
<br />
phase4<br />
<br />
4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)<br />
<br />
phase5<br />
<br />
5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).<br />
<br />
THORNY ISSUES<br />
<br />
phase0<br />
<br />
1) extra write files. Seems to me that there should be either<br />
<br />
a) only 2 write_restart and write_field, or<br />
<br />
b) an init function and then only write_field<br />
<br />
2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)<br />
<br />
3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code<br />
<br />
4) KEJ is still trying to sort out the roles of {query,init}phmpiio. <br />
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)<br />
b) init is called for both reads and writes of syncio files<br />
<br />
preliminary design plan<br />
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)<br />
ii) push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix<br />
openfile, closefile, {read,write}X{header,datablock}</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Work_Plan_In_Memory_Adapt&diff=567Work Plan In Memory Adapt2015-07-12T05:22:52Z<p>Kjansen: </p>
<hr />
<div>SUMMARY of phases<br />
<br />
phase0= clean syncio (almost there)<br />
<br />
phase1=PHASTA can read AND write both<br />
<br />
phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory data<br />
<br />
phase3=PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields <br />
<br />
phase4= bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)<br />
<br />
phase5=replace UR with local adaptation<br />
<br />
phase6=loop and we are done<br />
<br />
<br />
For the sake of discussion lets group phastaIO functions as follows<br />
<br />
A) init<br />
<br />
B) open-close<br />
<br />
C) read (readheader, readdatablock)<br />
<br />
D) write (writeheader, writedatablock)<br />
<br />
E) finalize<br />
<br />
To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach<br />
where the functions that the PHASTA workflow directly uses to perform IO are:<br />
<br />
# openfile_phio (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)<br />
# readheader_phio<br />
# readdatablock_phio<br />
# writeheader_phio<br />
# writedatablock_phio<br />
# closefile_phio<br />
<br />
These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those six wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.<br />
<br />
DETAIL<br />
<br />
phase0<br />
<br />
0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)<br />
<br />
0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.<br />
<br />
0.2' Move query and init into B)<br />
<br />
0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)<br />
<br />
0.4 Repeat 0.1-0.3 for writing of files<br />
<br />
phase1<br />
<br />
1.1 Migrate string constructors into conditional for syncio<br />
<br />
1.2 Create posix counterparts and put them in the posix branch of conditional<br />
<br />
1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)<br />
<br />
1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio<br />
<br />
1.4 Debug to make sure that files written are correct (two successive runs)<br />
<br />
phase2<br />
<br />
2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file<br />
<br />
2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)<br />
<br />
2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote<br />
<br />
phase3<br />
<br />
3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location<br />
<br />
3.2 Create ability to pass the descriptor of that memory location back to Chef<br />
<br />
3.3 Create ability for Chef to read adapt-fields when passed descriptor<br />
<br />
3.4 Invoke a UR with solution transfer and write files to confirm phase3 success<br />
<br />
phase4<br />
<br />
4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)<br />
<br />
phase5<br />
<br />
5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).<br />
<br />
THORNY ISSUES<br />
<br />
phase0<br />
<br />
1) extra write files. Seems to me that there should be either<br />
<br />
a) only 2 write_restart and write_field, or<br />
<br />
b) an init function and then only write_field<br />
<br />
2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)<br />
<br />
3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code<br />
<br />
4) KEJ is still trying to sort out the roles of {query,init}phmpiio. <br />
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)<br />
b) init is called for both reads and writes of syncio files<br />
<br />
preliminary design plan<br />
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)<br />
ii) make new function called init and it will basically return doing nothing for posix but for syncio it will call query if it is init for read and then just do what initphmpiio currently does<br />
iii) this should allow us to push all init stuff into a single function or potentially all the way into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix<br />
openfile, closefile, {read,write}X{header,datablock}</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Work_Plan_In_Memory_Adapt&diff=566Work Plan In Memory Adapt2015-07-12T05:20:11Z<p>Kjansen: </p>
<hr />
<div>SUMMARY of phases<br />
<br />
phase0= clean syncio (almost there)<br />
<br />
phase1=PHASTA can read AND write both<br />
<br />
phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory data<br />
<br />
phase3=PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields <br />
<br />
phase4= bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)<br />
<br />
phase5=replace UR with local adaptation<br />
<br />
phase6=loop and we are done<br />
<br />
<br />
For the sake of discussion lets group phastaIO functions as follows<br />
<br />
A) init<br />
<br />
B) open-close<br />
<br />
C) read (readheader, readdatablock)<br />
<br />
D) write (writeheader, writedatablock)<br />
<br />
E) finalize<br />
<br />
To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a three layer approach<br />
Layer 1 Functions that PHASTA workflow function use directly to perform IO<br />
<br />
# openfile_phio (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)<br />
# readheader_phio<br />
# readdatablock_phio<br />
# writeheader_phio<br />
# writedatablock_phio<br />
# closefile_phio<br />
<br />
These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those six wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.<br />
<br />
DETAIL<br />
<br />
phase0<br />
<br />
0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)<br />
<br />
0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.<br />
<br />
0.2' Move query and init into B)<br />
<br />
0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)<br />
<br />
0.4 Repeat 0.1-0.3 for writing of files<br />
<br />
phase1<br />
<br />
1.1 Migrate string constructors into conditional for syncio<br />
<br />
1.2 Create posix counterparts and put them in the posix branch of conditional<br />
<br />
1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)<br />
<br />
1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio<br />
<br />
1.4 Debug to make sure that files written are correct (two successive runs)<br />
<br />
phase2<br />
<br />
2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file<br />
<br />
2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)<br />
<br />
2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote<br />
<br />
phase3<br />
<br />
3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location<br />
<br />
3.2 Create ability to pass the descriptor of that memory location back to Chef<br />
<br />
3.3 Create ability for Chef to read adapt-fields when passed descriptor<br />
<br />
3.4 Invoke a UR with solution transfer and write files to confirm phase3 success<br />
<br />
phase4<br />
<br />
4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)<br />
<br />
phase5<br />
<br />
5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).<br />
<br />
THORNY ISSUES<br />
<br />
phase0<br />
<br />
1) extra write files. Seems to me that there should be either<br />
<br />
a) only 2 write_restart and write_field, or<br />
<br />
b) an init function and then only write_field<br />
<br />
2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)<br />
<br />
3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code<br />
<br />
4) KEJ is still trying to sort out the roles of {query,init}phmpiio. <br />
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)<br />
b) init is called for both reads and writes of syncio files<br />
<br />
preliminary design plan<br />
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)<br />
ii) make new function called init and it will basically return doing nothing for posix but for syncio it will call query if it is init for read and then just do what initphmpiio currently does<br />
iii) this should allow us to push all init stuff into a single function or potentially all the way into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix<br />
openfile, closefile, {read,write}X{header,datablock}</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Work_Plan_In_Memory_Adapt&diff=565Work Plan In Memory Adapt2015-07-12T05:19:23Z<p>Kjansen: </p>
<hr />
<div>SUMMARY of phases<br />
<br />
phase0= clean syncio (almost there)<br />
<br />
phase1=PHASTA can read AND write both<br />
<br />
phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory data<br />
<br />
phase3=PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields <br />
<br />
phase4= bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)<br />
<br />
phase5=replace UR with local adaptation<br />
<br />
phase6=loop and we are done<br />
<br />
<br />
For the sake of discussion lets group phastaIO functions as follows<br />
<br />
A) init<br />
<br />
B) open-close<br />
<br />
C) read (readheader, readdatablock)<br />
<br />
D) write (writeheader, writedatablock)<br />
<br />
E) finalize<br />
<br />
To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a three layer approach<br />
Layer 1 Functions that PHASTA workflow function use directly to perform IO<br />
<br />
# openfile_phio (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)<br />
# readheader_phio<br />
# readdatablock_phio<br />
# writeheader_phio<br />
# writedatablock_phio<br />
<br />
These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those six wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.<br />
<br />
DETAIL<br />
<br />
phase0<br />
<br />
0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)<br />
<br />
0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.<br />
<br />
0.2' Move query and init into B)<br />
<br />
0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)<br />
<br />
0.4 Repeat 0.1-0.3 for writing of files<br />
<br />
phase1<br />
<br />
1.1 Migrate string constructors into conditional for syncio<br />
<br />
1.2 Create posix counterparts and put them in the posix branch of conditional<br />
<br />
1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)<br />
<br />
1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio<br />
<br />
1.4 Debug to make sure that files written are correct (two successive runs)<br />
<br />
phase2<br />
<br />
2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file<br />
<br />
2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)<br />
<br />
2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote<br />
<br />
phase3<br />
<br />
3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location<br />
<br />
3.2 Create ability to pass the descriptor of that memory location back to Chef<br />
<br />
3.3 Create ability for Chef to read adapt-fields when passed descriptor<br />
<br />
3.4 Invoke a UR with solution transfer and write files to confirm phase3 success<br />
<br />
phase4<br />
<br />
4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)<br />
<br />
phase5<br />
<br />
5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).<br />
<br />
THORNY ISSUES<br />
<br />
phase0<br />
<br />
1) extra write files. Seems to me that there should be either<br />
<br />
a) only 2 write_restart and write_field, or<br />
<br />
b) an init function and then only write_field<br />
<br />
2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)<br />
<br />
3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code<br />
<br />
4) KEJ is still trying to sort out the roles of {query,init}phmpiio. <br />
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)<br />
b) init is called for both reads and writes of syncio files<br />
<br />
preliminary design plan<br />
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)<br />
ii) make new function called init and it will basically return doing nothing for posix but for syncio it will call query if it is init for read and then just do what initphmpiio currently does<br />
iii) this should allow us to push all init stuff into a single function or potentially all the way into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix<br />
openfile, closefile, {read,write}X{header,datablock}</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Work_Plan_In_Memory_Adapt&diff=564Work Plan In Memory Adapt2015-07-12T05:18:38Z<p>Kjansen: </p>
<hr />
<div><br />
SUMMARY of phases<br />
<br />
phase0= clean syncio (almost there)<br />
<br />
phase1=PHASTA can read AND write both<br />
<br />
phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory data<br />
<br />
phase3=PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields <br />
<br />
phase4= bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)<br />
<br />
phase5=replace UR with local adaptation<br />
<br />
phase6=loop and we are done<br />
<br />
<br />
For the sake of discussion lets group phastaIO functions as follows<br />
<br />
A) init<br />
<br />
B) open-close<br />
<br />
C) read (readheader, readdatablock)<br />
<br />
D) write (writeheader, writedatablock)<br />
<br />
E) finalize<br />
<br />
To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a three layer approach<br />
##Layer 1 Functions that PHASTA workflow function use directly to perform IO<br />
# openfile_phio (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)<br />
# readheader_phio<br />
# readdatablock_phio<br />
# writeheader_phio<br />
# writedatablock_phio<br />
## These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those six wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.<br />
<br />
DETAIL<br />
<br />
phase0<br />
<br />
0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)<br />
<br />
0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.<br />
<br />
0.2' Move query and init into B)<br />
<br />
0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)<br />
<br />
0.4 Repeat 0.1-0.3 for writing of files<br />
<br />
phase1<br />
<br />
1.1 Migrate string constructors into conditional for syncio<br />
<br />
1.2 Create posix counterparts and put them in the posix branch of conditional<br />
<br />
1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)<br />
<br />
1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio<br />
<br />
1.4 Debug to make sure that files written are correct (two successive runs)<br />
<br />
phase2<br />
<br />
2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file<br />
<br />
2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)<br />
<br />
2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote<br />
<br />
phase3<br />
<br />
3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location<br />
<br />
3.2 Create ability to pass the descriptor of that memory location back to Chef<br />
<br />
3.3 Create ability for Chef to read adapt-fields when passed descriptor<br />
<br />
3.4 Invoke a UR with solution transfer and write files to confirm phase3 success<br />
<br />
phase4<br />
<br />
4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)<br />
<br />
phase5<br />
<br />
5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).<br />
<br />
THORNY ISSUES<br />
<br />
phase0<br />
<br />
1) extra write files. Seems to me that there should be either<br />
<br />
a) only 2 write_restart and write_field, or<br />
<br />
b) an init function and then only write_field<br />
<br />
2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)<br />
<br />
3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code<br />
<br />
4) KEJ is still trying to sort out the roles of {query,init}phmpiio. <br />
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)<br />
b) init is called for both reads and writes of syncio files<br />
<br />
preliminary design plan<br />
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)<br />
ii) make new function called init and it will basically return doing nothing for posix but for syncio it will call query if it is init for read and then just do what initphmpiio currently does<br />
iii) this should allow us to push all init stuff into a single function or potentially all the way into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix<br />
openfile, closefile, {read,write}X{header,datablock}</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Work_Plan_In_Memory_Adapt&diff=563Work Plan In Memory Adapt2015-07-11T19:41:09Z<p>Kjansen: </p>
<hr />
<div>SUMMARY of phases<br />
<br />
phase0= clean syncio (almost there)<br />
<br />
phase1=PHASTA can read AND write both<br />
<br />
phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory data<br />
<br />
phase3=PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields <br />
<br />
phase4= bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)<br />
<br />
phase5=replace UR with local adaptation<br />
<br />
phase6=loop and we are done<br />
<br />
<br />
For the sake of discussion lets group phastaIO functions as follows<br />
<br />
A) init<br />
<br />
B) open-close<br />
<br />
C) read (readheader, readdatablock)<br />
<br />
D) write (writeheader, writedatablock)<br />
<br />
E) finalize<br />
<br />
DETAIL<br />
<br />
phase0<br />
<br />
0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)<br />
<br />
0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.<br />
<br />
0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (hopefully complete to 15-July-11)<br />
<br />
0.4 Repeat 0.1-0.3 for writing of files<br />
<br />
phase1<br />
<br />
1.1 Migrate string constructors into conditional for syncio<br />
<br />
1.2 Create posix counterparts and put them in the posix branch of conditional<br />
<br />
1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)<br />
<br />
1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio<br />
<br />
1.4 Debug to make sure that files written are correct (two successive runs)<br />
<br />
phase2<br />
<br />
2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file<br />
<br />
2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)<br />
<br />
2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote<br />
<br />
phase3<br />
<br />
3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location<br />
<br />
3.2 Create ability to pass the descriptor of that memory location back to Chef<br />
<br />
3.3 Create ability for Chef to read adapt-fields when passed descriptor<br />
<br />
3.4 Invoke a UR with solution transfer and write files to confirm phase3 success<br />
<br />
phase4<br />
<br />
4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)<br />
<br />
phase5<br />
<br />
5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).<br />
<br />
THORNY ISSUES<br />
<br />
phase0<br />
<br />
1) extra write files. Seems to me that there should be either<br />
<br />
a) only 2 write_restart and write_field, or<br />
<br />
b) an init function and then only write_field<br />
<br />
2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)<br />
<br />
3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code<br />
<br />
4) KEJ is still trying to sort out the roles of {query,init}phmpiio. <br />
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)<br />
b) init is called for both reads and writes of syncio files<br />
<br />
preliminary design plan<br />
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)<br />
ii) make new function called init and it will basically return doing nothing for posix but for syncio it will call query if it is init for read and then just do what initphmpiio currently does<br />
iii) this should allow us to push all init stuff into a single function or potentially all the way into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix<br />
openfile, closefile, {read,write}X{header,datablock}</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Work_Plan_In_Memory_Adapt&diff=562Work Plan In Memory Adapt2015-07-11T18:42:53Z<p>Kjansen: Created page with "SUMMARY of phases phase0= clean syncio (almost there) phase1=PHASTA can read AND write both phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory ..."</p>
<hr />
<div>SUMMARY of phases<br />
<br />
phase0= clean syncio (almost there)<br />
<br />
phase1=PHASTA can read AND write both<br />
<br />
phase2=PHASTA runs after chef though an in-memory read of Chef's written in-memory data<br />
<br />
phase3=PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields <br />
<br />
phase4= bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)<br />
<br />
phase5=replace UR with local adaptation<br />
<br />
phase6=loop and we are done<br />
<br />
<br />
For the sake of discussion lets group phastaIO functions as follows<br />
<br />
A) init<br />
<br />
B) open-close<br />
<br />
C) read (readheader, readdatablock)<br />
<br />
D) write (writeheader, writedatablock)<br />
<br />
E) finalize<br />
<br />
DETAIL<br />
<br />
phase0<br />
<br />
0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)<br />
<br />
0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.<br />
<br />
0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (hopefully complete to 15-July-11)<br />
<br />
0.4 Repeat 0.1-0.3 for writing of files<br />
<br />
phase1<br />
<br />
1.1 Migrate string constructors into conditional for syncio<br />
<br />
1.2 Create posix counterparts and put them in the posix branch of conditional<br />
<br />
1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)<br />
<br />
1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio<br />
<br />
1.4 Debug to make sure that files written are correct (two successive runs)<br />
<br />
phase2<br />
<br />
2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file<br />
<br />
2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)<br />
<br />
2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote<br />
<br />
phase3<br />
<br />
3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location<br />
<br />
3.2 Create ability to pass the descriptor of that memory location back to Chef<br />
<br />
3.3 Create ability for Chef to read adapt-fields when passed descriptor<br />
<br />
3.4 Invoke a UR with solution transfer and write files to confirm phase3 success<br />
<br />
phase4<br />
<br />
4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)<br />
<br />
phase5<br />
<br />
5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).<br />
<br />
THORNY ISSUES<br />
<br />
phase0<br />
<br />
1) extra write files. Seems to me that there should be either<br />
<br />
a) only 2 write_restart and write_field, or<br />
<br />
b) an init function and then only write_field<br />
<br />
2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Making_A_New_Wiki&diff=561Making A New Wiki2015-07-11T18:36:00Z<p>Kjansen: </p>
<hr />
<div>So you are ready to make make a brand new wiki page. The process for doing this is:<br />
<br />
1) assuming you are reading this you are on the wiki page but be sure you login<br />
<br />
2) go to your browsers url and replace whatever is after index.php/ with whatever you want to name your page noting that underscores will map to spaces. For example, this page was made by the following edit<br />
http://fluid.colorado.edu/wiki/index.php/Making_A_New_Wiki<br />
<br />
3) assuming you chose a unique title this will take you to a new blank wiki page with a Create button near the top<br />
<br />
4) click that create button and then start composing your new wiki in the editing window<br />
<br />
5) when you are done with this draft (wikis are NEVER done) click the save page button (feel free to put something descriptive in the Summary window at the bottom.<br />
<br />
DONE</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Making_A_New_Wiki&diff=560Making A New Wiki2015-07-11T18:35:38Z<p>Kjansen: </p>
<hr />
<div>So you are ready to make make a brand new wiki page. The process for doing this is:<br />
<br />
1) assuming you are reading this you are on the wiki page but be sure you login<br />
<br />
2) go to your browsers url and replace whatever is after index.php/ with whatever you want to name your page noting that underscores will map to spaces. For example, this page was made by the following edit<br />
http://fluid.colorado.edu/wiki/index.php/Making_A_New_Wiki<br />
<br />
3) assuming you chose a unique title this will take you to a new blank wiki page with a Create button near the top<br />
<br />
4) click that create button and then start composing your new wiki in the editing window<br />
<br />
5) when you are done with this draft (wikis are NEVER done) click the save page button (feel free to put something descriptive in the Summary window at the bottom.<br />
DONE</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Making_A_New_Wiki&diff=559Making A New Wiki2015-07-11T18:34:51Z<p>Kjansen: Create a new wiki page in 5 easy steps.</p>
<hr />
<div>So you are ready to make make a brand new wiki page. The process for doing this is:<br />
1) assuming you are reading this you are on the wiki page but be sure you login<br />
2) go to your browsers url and replace whatever is after index.php/ with whatever you want to name your page noting that underscores will map to spaces. For example, this page was made by the following edit<br />
http://fluid.colorado.edu/wiki/index.php/Making_A_New_Wiki<br />
3) assuming you chose a unique title this will take you to a new blank wiki page with a Create button near the top<br />
4) click that create button and then start composing your new wiki in the editing window<br />
5) when you are done with this draft (wikis are NEVER done) click the save page button (feel free to put something descriptive in the Summary window at the bottom.<br />
DONE</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=PHASTA/Reduce_Restart_and_Geombc_Files&diff=558PHASTA/Reduce Restart and Geombc Files2015-06-11T00:43:43Z<p>Kjansen: /* Reduction from M to N parts in // for phasta files initially partitioned with NSpre_parallel, phParAdapt-SCOREC or chef */</p>
<hr />
<div>== Reduction from M parts to 1 part in serial for phasta files initially partitioned with NSpre_parallel ==<br />
<br />
*cd to the procs_case directory that contains the files you want to reduce<br />
*Run the executable:<br />
~mrasquin/develop/phasta/phPost/phPost/bin/x86_64_linux-icc/reduce-openmpi-O -sn<br />
where sn is the time step number. For example, the restart files corresponding to time step 5 would be restart.5.* and geombc.dat.* . <br />
*The reduce operation will generate restart.##.0 in the procs_case directory, where ## stands for the step number you have reduced.<br />
*restart.##.0, combined with geombc.dat.1 (which contains the boundary conditions for all the parts - it is created when you run NSPre_Parasolid), are what you need to see the solution on 1 part.<br />
<br />
<br />
== Reduction from M to N parts in // for phasta files initially partitioned with NSpre_parallel, phParAdapt-SCOREC or chef ==<br />
<br />
* Prerequisites:<br />
The tool described in this section apply to phasta files initially partitioned with phParAdapt-SCOREC or chef. We consider here that M parts were generated from N parts with M>N (M is usually a multiple of N). A vertex mapping between the M parts and N parts needs to be generated by phParAdapt-SCOREC or chef through the variable "buildMapping 1" in adapt.inp.<br />
<br />
* Download the M2N and M2NFixBdn packages from<br />
cd your-develop-dir-cmake/phasta<br />
git clone ssh://username@jumpgate-phasta.colorado.edu/users/mrasquin/develop-FlowControl-SyncIO-Cmake/phasta/M2N <br />
git clone ssh://username@jumpgate-phasta.colorado.edu/users/mrasquin/develop-FlowControl-SyncIO-Cmake/phasta/M2NFixBnd<br />
<br />
* Build both packages with cmake. For instance, on the viz nodes with gcc:<br />
<br />
cd your-develop-dir-cmake<br />
<br />
mkdir build-M2N<br />
cd build-M2N<br />
CC=gcc CXX=g++ FC=gfortran cmake -DCMAKE_BUILD_TYPE=Release ../phasta/M2N/src<br />
make -j 8 VERBOSE=1<br />
cd ..<br />
<br />
mkdir build-M2NFixBnd<br />
cd build-M2NFixBnd<br />
CC=gcc CXX=g++ FC=gfortran cmake -DCMAKE_BUILD_TYPE=Release ../phasta/M2NFixBnd/src<br />
make -j 8 VERBOSE=1<br />
cd ..<br />
<br />
* Run M2N on M processes<br />
<br />
mpirun -np M your-develop-dir-cmake/build-M2N/M2N<br />
<br />
Input: M2N reads<br />
- The geombc files files under the SyncIO format (M parts);<br />
- The solution, dwal, error and ybar fields from a set of restart files under the SyncIO format (M parts) for adaptation or post-processing later;<br />
- The vertex mapping field from a set of restart files under the SyncIO format (M parts). <br />
- An input file named "M2N_input.dat" described below<br />
Note that usually, the vertex mapping field is included in the restart files of the first time step of your computation, whereas the solution, dwal, error and dwal come from the last time step of the computation.<br />
<br />
The "M2N_input.dat" must include the following information:<br />
120 # time step of the restart files for solution, dwal, error and ybar. It can be very useful when processing many files on queued systems to <br />
# replace this number (120) by Step2Red and then use sed in the submit script to replace it with a number entered on the command line <br />
# e.g., Step2Red=$4<br />
# sed "s/Step2Red/${Step2Red}/g" M2N_inputSed.dat > M2N_input.dat <br />
# for easy replacement just ahead of execution and $4 is the 4th argument on the submit script passed to the run script with this insertion<br />
100 # time step of the restart files for partID and vtxID (mapping between M and N)<br />
0 # Reduce method: 0 = communicatoin based approach (recommended), 1 = file based approach. <br />
1 # (For reduce method = 1 only): 0 = ascii files, 1 = binary files<br />
1 # Print debug statement if = 1, none if = 0 (recommended at scale)<br />
<br />
Output: M2N produces<br />
- N restart files under the Posix format, which is what phParAdapt requires for now.<br />
<br />
* Run M2NFixBnd on N processes<br />
<br />
The value of the solution, dwal, errors and ybar fields still need to be updated on the part boundaries of the N parts, which is the purpose of M2NFixBnd<br />
<br />
mpirun -np N your-develop-dir-cmake/build-M2NFixBnd/M2NFixBnd<br />
<br />
Input: M2NFixBnd reads<br />
- The solution, dwal, errors and ybars field from the N restart files under the Posix format produced by M2N in the previous step;<br />
- The ilwork array from the N geombc files under the Posix format that matches the restart files produced by M2N.<br />
<br />
Output: M2NFixBnd produces<br />
- N restart files under the posix format that overwrite the ones generated by M2N.<br />
<br />
* Example<br />
<br />
See <br />
<br />
/users/mrasquin/Models/CrossFlowTest/1-A0-Mixed-9.0/SyncIO-phPA/Runs-pumi-Tet-ts100/ReduceM2N-16TetPumi-8MixedSim/runReduceM2N.sh</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=PHASTA/Reduce_Restart_and_Geombc_Files&diff=557PHASTA/Reduce Restart and Geombc Files2015-06-11T00:42:01Z<p>Kjansen: /* Reduction from M to N parts in // for phasta files initially partitioned with NSpre_parallel */</p>
<hr />
<div>== Reduction from M parts to 1 part in serial for phasta files initially partitioned with NSpre_parallel ==<br />
<br />
*cd to the procs_case directory that contains the files you want to reduce<br />
*Run the executable:<br />
~mrasquin/develop/phasta/phPost/phPost/bin/x86_64_linux-icc/reduce-openmpi-O -sn<br />
where sn is the time step number. For example, the restart files corresponding to time step 5 would be restart.5.* and geombc.dat.* . <br />
*The reduce operation will generate restart.##.0 in the procs_case directory, where ## stands for the step number you have reduced.<br />
*restart.##.0, combined with geombc.dat.1 (which contains the boundary conditions for all the parts - it is created when you run NSPre_Parasolid), are what you need to see the solution on 1 part.<br />
<br />
<br />
== Reduction from M to N parts in // for phasta files initially partitioned with NSpre_parallel, phParAdapt-SCOREC or chef ==<br />
<br />
* Prerequisites:<br />
The tool described in this section apply to phasta files initially partitioned with phParAdapt-SCOREC or chef. We consider here that M parts were generated from N parts with M>N (M is usually a multiple of N). A vertex mapping between the M parts and N parts needs to be generated by phParAdapt-SCOREC or chef through the variable "buildMapping 1" in adapt.inp.<br />
<br />
* Download the M2N and M2NFixBdn packages from<br />
cd your-develop-dir-cmake/phasta<br />
git clone ssh://username@jumpgate-phasta.colorado.edu/users/mrasquin/develop-FlowControl-SyncIO-Cmake/phasta/M2N <br />
git clone ssh://username@jumpgate-phasta.colorado.edu/users/mrasquin/develop-FlowControl-SyncIO-Cmake/phasta/M2NFixBnd<br />
<br />
* Build both packages with cmake. For instance, on the viz nodes with gcc:<br />
<br />
cd your-develop-dir-cmake<br />
<br />
mkdir build-M2N<br />
cd build-M2N<br />
CC=gcc CXX=g++ FC=gfortran cmake -DCMAKE_BUILD_TYPE=Release ../phasta/M2N/src<br />
make -j 8 VERBOSE=1<br />
cd ..<br />
<br />
mkdir build-M2NFixBnd<br />
cd build-M2NFixBnd<br />
CC=gcc CXX=g++ FC=gfortran cmake -DCMAKE_BUILD_TYPE=Release ../phasta/M2NFixBnd/src<br />
make -j 8 VERBOSE=1<br />
cd ..<br />
<br />
* Run M2N on M processes<br />
<br />
mpirun -np M your-develop-dir-cmake/build-M2N/M2N<br />
<br />
Input: M2N reads<br />
- The geombc files files under the SyncIO format (M parts);<br />
- The solution, dwal, error and ybar fields from a set of restart files under the SyncIO format (M parts) for adaptation or post-processing later;<br />
- The vertex mapping field from a set of restart files under the SyncIO format (M parts). <br />
- An input file named "M2N_input.dat" described below<br />
Note that usually, the vertex mapping field is included in the restart files of the first time step of your computation, whereas the solution, dwal, error and dwal come from the last time step of the computation.<br />
<br />
The "M2N_input.dat" must include the following information:<br />
120 # time step of the restart files for solution, dwal, error and ybar. It can be very useful when processing many files on queued systems to <br />
# replace this number by Step2Red and then use sed in the submit script to replace it with a number entered on the command line <br />
# e.g., Step2Red=$4<br />
# sed "s/Step2Red/${Step2Red}/g" M2N_inputSed.dat > M2N_input.dat <br />
# and replace th3 120 in this example by the string Step2Red for easy replacement just ahead of execution and $4 is the 4th argument on the submit script<br />
100 # time step of the restart files for partID and vtxID (mapping between M and N)<br />
0 # Reduce method: 0 = communicatoin based approach (recommended), 1 = file based approach. <br />
1 # (For reduce method = 1 only): 0 = ascii files, 1 = binary files<br />
1 # Print debug statement if = 1, none if = 0 (recommended at scale)<br />
<br />
Output: M2N produces<br />
- N restart files under the Posix format, which is what phParAdapt requires for now.<br />
<br />
* Run M2NFixBnd on N processes<br />
<br />
The value of the solution, dwal, errors and ybar fields still need to be updated on the part boundaries of the N parts, which is the purpose of M2NFixBnd<br />
<br />
mpirun -np N your-develop-dir-cmake/build-M2NFixBnd/M2NFixBnd<br />
<br />
Input: M2NFixBnd reads<br />
- The solution, dwal, errors and ybars field from the N restart files under the Posix format produced by M2N in the previous step;<br />
- The ilwork array from the N geombc files under the Posix format that matches the restart files produced by M2N.<br />
<br />
Output: M2NFixBnd produces<br />
- N restart files under the posix format that overwrite the ones generated by M2N.<br />
<br />
* Example<br />
<br />
See <br />
<br />
/users/mrasquin/Models/CrossFlowTest/1-A0-Mixed-9.0/SyncIO-phPA/Runs-pumi-Tet-ts100/ReduceM2N-16TetPumi-8MixedSim/runReduceM2N.sh</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=NSPre&diff=508NSPre2015-02-12T00:31:42Z<p>Kjansen: </p>
<hr />
<div>There are currently many versions of NSpre out there. It falls into the category of code that few people change but it gets out of date because it is built against libraries from Simmetrix that do change a few times a year. If you find that the current recommended version fails for your case, send an email to Professor Jansen and he will redirect the email to the current maintainer.<br />
<br />
'''Current recommended version'''<br />
<br />
/users/chitak/develop/phasta/phNSpre/phNSpre/bin/x86_64_linux-icc/NSpre-Parasolid_Serial-openmpi-O<br />
<br />
If this fails AND you are working with older meshes and models, you may have to work with on of the older versions listed below.<br />
<br />
The oldest version of NSpre which should work with any meshes created with Simmetrix versions prior to 7.2-120626, uses geom.spj file (old attribute file format, created with simappssdk). This vesion can also use version_2 meshes. You need to have geom.xmt_txt, geom.spj, geom.sms files in the directory where you run this. <br />
To use this NSpre (if you still have geom.spj files), use<br />
<br />
/users/kjansen/NSpre-Parasolid_Serial-mpich1-O<br />
<br />
<br />
If you have created your mesh with a version later than 7.x libraries, most probably above version is going to fail. Also, if you have used SimModeler to create your attribute file (*.smd), above version is not going to work. There is another executable for this. You need to have geom.xmt_txt, geom.smd, geom.sms files in the directory where you run it. The path is: <br />
<br />
/users/chitak/Executables/NSpre-Parasolid_Serial-openmpi-O<br />
<br />
This and newer versions require a geom.smd file as the attribute file, so if you still have a geom.spj file, you can convert it to smd format (check [[SimModeler]])<br />
<br />
There are counterparts for these executables which use discrete model (*-Discrete_*). You can use the same parallel NSpre executable from<br />
<br />
/users/kjansen/NSpre_Parallel-mpich1-O</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=SimModeler&diff=506SimModeler2014-08-14T19:16:20Z<p>Kjansen: /* Creating new files */</p>
<hr />
<div>[[Category:Software]]<br />
<br />
SimModeler is a model creation program from Simmetrix. It takes the mesh and geometric model and creates the input files for PHASTA.<br />
<br />
<br />
== Running ==<br />
To run SimModeler, first connect via VNC, then use vglconnect to connect to one of the compute machines:<br />
<br />
vglconnect -s viz001<br />
<br />
Add the desired version of SimModeler to your environment (the below example will get the "default" version):<br />
<br />
soft add +simmodeler<br />
<br />
and lunch the GUI:<br />
<br />
vglrun simmodeler<br />
<br />
== Converting old files ==<br />
This is a guide for converting old files (parasolid and .spj) to the new format (.smd).<br />
<br />
After connecting to one of the compute machines, add the suite of tools for SimModeler to your environment:<br />
<br />
soft add +simmodsuite<br />
<br />
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: <br />
<br />
~matthb2/simmodelerconvert/testConvert <br />
<br />
Your directory now contains two new files: model.smd and model.x_t<br />
<br />
== Creating new files ==<br />
<br />
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]. Note you must also double click on "problem definition" which will allow you to name the case. Later post processing expects the name "geom" so always name it so.<br />
<br />
== Boundary conditions ==<br />
<br />
Commonly boundary conditions include:<br />
<br />
*comp3 - Specifies a 3D velocity vector<br />
*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. <br />
*temperature - Sets the temperature of the wall. This is only needed for compressible cases. <br />
*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)<br />
*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. <br />
*natural pressure - Apply a mean pressure over a surface. The pressure at any particular point is still allowed to vary (someone verify). <br />
*traction vector - ??. The zero vector is typically applied at outlet. <br />
*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. <br />
*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. <br />
*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.</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=GridFTP&diff=81GridFTP2011-09-06T21:21:19Z<p>Kjansen: /* GSISSH */</p>
<hr />
<div>==Introduction==<br />
<br />
GridFTP is a high performance file transfer tool supported by many of the large super-compute sites. It uses parallelism to hide the effects of latency and TCP's congestion controls. <br />
<br />
GridFTP is part of the larger Globus Toolkit, which also includes (among other things) a custom PKI based authentication mechanism. This can be used to achieve password-less authentication with supported sites (most of TeraGrid for example). <br />
<br />
==Setup==<br />
GridFTP should already be in your path and configured by default on jumpgate-phasta.colorado.edu. If it is not (due to unusual shell configuration or other issues) you can usually get it by running<br />
<br />
source /etc/profile<br />
<br />
To test if you have GridFTP in your path correctly you can run these command (each should give you some output)<br />
<br />
which globus-url-copy<br />
which myproxy-logon<br />
echo $GLOBUS_LOCATION<br />
echo $LD_LIBRARY_PATH | grep gt5<br />
<br />
To use sshftp mode, you'll also want to have a SSH preshared key configured with your account, (either without a password, or with ssh-agent)<br />
<br />
==Authentication==<br />
<br />
Most sites support the use of "GSI" password-less authentication. If the site you want to connect to offers this option, you probably want to use it. <br />
<br />
The way GSI authentication is usually implemented uses a tool called "myproxy" which generates a key which you can use for a short time to authenticate without a password. <br />
<br />
The first step to using GSI authentication is to install the necessary certificates in your home directory. Most sites will allow you to do this automatically using the myproxy tool's "-T" option. You only need to use this option the first time you use myproxy. <br />
<br />
For example, to configure my account to connect to the GridFTP/myproxy server at ANL, I could use this command:<br />
<br />
myproxy-logon -T -l matthb -t 300 -s gs1.intrepid.alcf.anl.gov<br />
<br />
This command can be disected as follows:<br />
-T tells myproxy to fetch the trust roots (CA, etc). You should only need to do this the first time you connect to a particular server and when the server's CA is updated. <br />
<br />
-l matthb specifies my username (replace "matthb" with your username)<br />
<br />
-t 300 specifies that I want my session key to expire in 300 hours (the default is 24)<br />
<br />
-s gs1.intrepid.alcf.anl.gov specifies the myproxy server (*not* necessarily the gridftp server)<br />
<br />
<br />
== Common myproxy Servers ==<br />
Intrepid and Eureka (ALCF/ANL)<br />
gs1.intrepid.alcf.anl.gov<br />
(authenticate with your CryptoCard and pin)<br />
<br />
Teragrid (Kraken, Ranger, etc)<br />
myproxy.teragrid.org<br />
(authenticate with your Teragrid portal username/password)<br />
<br />
*-phasta.colorado.edu <br />
myproxy-phasta.colorado.edu<br />
(authenticate with your normal UNIX/LDAP username/password)<br />
(coming soon)<br />
<br />
==GSISSH==<br />
Once you have a GSI key/ticket, many sites allow you to use it to gain shell access as well as do file transfers. For example, even if I don't have my SecureID for Kraken handy, I can still log-in using GSI and my TeraGrid credentials as follows:<br />
<br />
ssh jumpgate-phasta.colorado.edu<br />
myproxy-logon -T -l myteragriduser -s myproxy.teragrid.org<br />
gsissh mykrakenuser@kraken-gsi.nics.utk.edu<br />
<br />
==GridFTP==<br />
The primary tool for doing GridFTP transfers is called "globus-url-copy" To see it's complete usage you can run<br />
globus-url-copy -help<br />
<br />
In general, you should start with the following set of options:<br />
<br />
globus-url-copy -r -cd -rst -rst-retries 0 -fast -vb -p 64 -g2 -stripe -tcp-bs 4M<br />
<br />
followed by your source and destination URLs. <br />
<br />
To transfer to/from jumpgate-phasta.colorado.edu your URL should look something like this<br />
<br />
sshftp://username@jumpgate-phasta.colorado.edu/users/username/file<br />
<br />
Please see the site specific documentation for other site's URLs. These URLs may be helpful to get you started:<br />
https://wiki.alcf.anl.gov/index.php/Using_GridFTP<br />
https://www.teragrid.org/web/user-support/transfer_location<br />
http://www.olcf.ornl.gov/kb_articles/gridftp/<br />
<br />
Recent versions of globus-url-copy also support a mode which behaves somewhat like rsync, enabled by the <br />
-sync -sync-level 3<br />
flags. <br />
<br />
A complete example to copy a directory from ALCF to jumpgate would be:<br />
<br />
globus-url-copy -r -cd -rst -rst-retries 0 -fast -vb -p 64 -stripe -tcp-bs 4M -g2 -sync -sync-level 3 gsiftp://gridftp.intrepid.alcf.anl.gov/intrepid-fs0/users/matthb/scratch/ sshftp://matthb2@jumpgate-phasta.colorado.edu/scratch/matthb2/scratch_from_anl/<br />
<br />
==UberFTP==<br />
A simpler (but less powerful) tool to do GridFTP transfers is UberFTP. First get a certificate from myproxy as before then run:<br />
uberftp hostname<br />
<br />
Set the number of streams with<br />
parallel 128<br />
<br />
then interact as you would with traditional ftp. The full list of commands is available by typing "help"<br />
<br />
UberFTP> help<br />
Usage "help [topic]" where topic is one of:<br />
! ? active ascii binary <br />
blksize bugs bye cat cd <br />
cdup chgrp chmod cksum close <br />
dcau debug dir family get <br />
glob hash help keepalive lcat <br />
lcd lcdup lchgrp lchmod lclose <br />
ldir lls lmkdir lopen lpwd <br />
lquote lrename lrm lrmdir ls <br />
lsize lstage mget mkdir mode <br />
mput open order parallel passive <br />
pbsz pget pput prot put <br />
pwd quit quote rename resume <br />
retry rm rmdir runique size <br />
stage sunique tcpbuf versions wait <br />
<br />
You probably will need at least the "ls", "get", "put", and "mget"/"mput" commands<br />
<br />
==GridFTP Tuning==<br />
Depending on the network conditions, you can see massive GridFTP can perform very well or very poorly. You can often improve things by changing a few parameters:<br />
<br />
-p 64<br />
Specifies that you want to use 64 streams. Because TCP needs to receive an acknowledgment before more data can be sent latency can drastically reduce performance over long distances. By adding more streams you can increase the amount of in-transit data and somewhat hide the effects of latency. If performance is poor try increasing this number until you stop seeing improvement. Using excessive numbers of streams won't help and will increase the load on the servers involved. You shouldn't need more than one or two more doublings of the value recommended here. <br />
<br />
-pp<br />
Enable pipelining. This can help with large number of files (particularly relatively small ones), but can also be buggy. If your transfers hang, try disabling this. If you're transferring lots of files, try enabling it. <br />
<br />
-cc 4<br />
Split the transfer over several (4 in this case) concurrent GridFTP sessions. This can also help with large numbers of small files. Use sparingly, and disable if you experience stalled/crashed transfers. <br />
<br />
-sync-level 3<br />
If you're using "sync" mode (similar to rsync) this determines the algorithm used to decide which files need to be (re) transferred. Level 3 uses checksums and will be the most reliable, but slowest. Level 2 is probably fine for most uses. See the globus-url-copy documentation for all the options.<br />
<br />
==More Examples==<br />
Kraken:<br />
myproxy-logon -T -l teragriduser -s myproxy.teragrid.org<br />
globus-url-copy -dbg -r -cd -rst -rst-retries 0 -pp -fast -vb -p 64 -stripe -tcp-bs 4M -g2 gsiftp://user@gridftp.kraken.nics.teragrid.org:2811/lustre/scratch/bmatth/test.img sshftp://user@jumpgate-phasta.colorado.edu/scratch/user/<br />
<br />
Script to transfer from Kraken to jumpgate-phasta and vice versa (easy to update for other destinations):<br />
[[media:Transfer.sh | transfer.sh]]<br />
<br />
example: ./transfer.sh 1 kraken2ucb /lustre/scratch/mrasquin/Models/Boeing/Beta/Open6_B5_D20_U20/15-A0-12jets/Runs-12jets/Archive4992.3600-3780/ /users/mrasquin/Models/Boeing/Beta/Open6_B5_D20_U20/15-A0-12jets/Runs-12jets/Archive4992.3600-3780/ 1<br />
<br />
You have to connect to jumpgate-phasta to execute this script. Do not forget to replace "mrasquin" by your TeraGrid login name (for the "myproxy-logon" command) and jumpgate-phasta and kraken login name (for the "globus-url-copy" commands).<br />
<br />
Note that it is faster to transfer a tar file than a directory that contains many files. But to tar or untar an archive on Kraken or Intrepid can take much more time so that it is recommended (so far) not to tar any directory and transfer its content directly.<br />
<br />
==Troubleshooting== <br />
<br />
If you get a message from myproxy that looks like this, try adding the "-b" option as prompted the (you should only need this option the first time you connect)<br />
<br />
Error authenticating: GSS Major Status: Authentication Failed<br />
GSS Minor Status Error Chain:<br />
globus_gss_assist: Error during context initialization<br />
OpenSSL Error: s3_clnt.c:985: in library: SSL routines, function SSL3_GET_SERVER_CERTIFICATE: certificate verify failed <br />
globus_gsi_callback_module: Could not verify credential<br />
globus_gsi_callback_module: Can't get the local trusted CA certificate: Untrusted self-signed certificate in chain with hash 9b95bbf2<br />
<br />
The CA that signed the myproxy-server's certificate is untrusted.<br />
If you want to trust the CA, re-run with the -b option.<br />
<br />
<br />
You command would then look something like this<br />
<br />
myproxy-logon -s myproxy.teragrid.org -l matthb2 -T -b</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Debugging&diff=34Debugging2011-08-20T13:19:05Z<p>Kjansen: /* Debugging Strategies */</p>
<hr />
<div>== '''Introduction''' ==<br />
<br />
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. <br />
<br />
The goal of this wiki is to organize our groups experience with debugging in general and specific tips for debugging our software.<br />
<br />
<br />
== '''General''' ==<br />
<br />
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.<br />
<br />
''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.<br />
<br />
''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. '''''Valgrind''''' (someone provide a link and 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.<br />
<br />
''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).'''<br />
<br />
<br />
== '''Choice of Debugger''' ==<br />
<br />
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.<br />
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.<br />
<br />
''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.<br />
<br />
''Command line debuggers'' link to gdb....some comments on when they are effective<br />
<br />
''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.<br />
<br />
== '''Debugging Strategies''' ==<br />
<br />
''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).<br />
<br />
<br />
''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).<br />
<br />
<br />
''Specific tips for SCOREC/Simmetrix Meshing and MeshAdapt software and associated databases:'' <br />
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<br />
<br />
V_info(ivert) // gives information about the the vertex ivert<br />
F_info(iface) // gives information about the the face iface<br />
R_info(iregion) // gives information about the the region iregion<br />
<br />
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.<br />
<br />
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.<br />
<br />
ADD TO ME<br />
<br />
''Specific tips for PHASTA:'' <br />
ADD TO ME</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Debugging&diff=33Debugging2011-08-20T13:16:38Z<p>Kjansen: /* Debugging Strategies */</p>
<hr />
<div>== '''Introduction''' ==<br />
<br />
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. <br />
<br />
The goal of this wiki is to organize our groups experience with debugging in general and specific tips for debugging our software.<br />
<br />
<br />
== '''General''' ==<br />
<br />
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.<br />
<br />
''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.<br />
<br />
''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. '''''Valgrind''''' (someone provide a link and 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.<br />
<br />
''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).'''<br />
<br />
<br />
== '''Choice of Debugger''' ==<br />
<br />
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.<br />
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.<br />
<br />
''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.<br />
<br />
''Command line debuggers'' link to gdb....some comments on when they are effective<br />
<br />
''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.<br />
<br />
== '''Debugging Strategies''' ==<br />
<br />
''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).<br />
<br />
<br />
''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).<br />
<br />
<br />
''Specific tips for SCOREC/Simmetrix Meshing and MeshAdapt software and associated databases:'' <br />
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<br />
<br />
V_info(ivert) // gives information about the the vertex ivert<br />
<br />
F_info(iface) // gives information about the the face iface<br />
<br />
R_info(iregion) // gives information about the the region iregion<br />
<br />
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.<br />
<br />
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.<br />
<br />
ADD TO ME<br />
<br />
''Specific tips for PHASTA:'' <br />
ADD TO ME</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Debugging&diff=32Debugging2011-08-20T13:05:30Z<p>Kjansen: </p>
<hr />
<div>== '''Introduction''' ==<br />
<br />
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. <br />
<br />
The goal of this wiki is to organize our groups experience with debugging in general and specific tips for debugging our software.<br />
<br />
<br />
== '''General''' ==<br />
<br />
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.<br />
<br />
''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.<br />
<br />
''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. '''''Valgrind''''' (someone provide a link and 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.<br />
<br />
''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).'''<br />
<br />
<br />
== '''Choice of Debugger''' ==<br />
<br />
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.<br />
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.<br />
<br />
''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.<br />
<br />
''Command line debuggers'' link to gdb....some comments on when they are effective<br />
<br />
''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.<br />
<br />
== '''Debugging Strategies''' ==<br />
<br />
''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).<br />
<br />
<br />
''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).<br />
<br />
<br />
''Specific tips for SCOREC/Simmetrix Meshing and MeshAdapt software and associated databases:'' <br />
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<br />
<br />
V_info(ivert) // gives information about the the vertex ivert<br />
F_info(iface) // gives information about the the face iface<br />
R_info(iregion) // gives information about the the region iregion<br />
<br />
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.<br />
<br />
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.<br />
<br />
ADD TO ME<br />
<br />
''Specific tips for PHASTA:'' <br />
ADD TO ME</div>Kjansenhttps://fluid.colorado.edu/wiki/index.php?title=Debugging&diff=31Debugging2011-08-20T13:04:24Z<p>Kjansen: </p>
<hr />
<div>== '''Introduction''' ==<br />
<br />
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. <br />
<br />
The goal of this wiki is to organize our groups experience with debugging in general and specific tips for debugging our software.<br />
<br />
<br />
== '''General''' ==<br />
<br />
<br />
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.<br />
<br />
''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.<br />
<br />
''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. '''''Valgrind''''' (someone provide a link and 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.<br />
<br />
''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).'''<br />
<br />
== '''Choice of Debugger''' ==<br />
<br />
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.<br />
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.<br />
<br />
''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.<br />
<br />
''Command line debuggers'' link to gdb....some comments on when they are effective<br />
<br />
''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.<br />
<br />
== '''Debugging Strategies''' ==<br />
<br />
''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).<br />
<br />
<br />
''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).<br />
<br />
<br />
''Specific tips for SCOREC/Simmetrix Meshing and MeshAdapt software and associated databases:'' <br />
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<br />
<br />
V_info(ivert) // gives information about the the vertex ivert<br />
F_info(iface) // gives information about the the face iface<br />
R_info(iregion) // gives information about the the region iregion<br />
<br />
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.<br />
<br />
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.<br />
<br />
ADD TO ME<br />
<br />
''Specific tips for PHASTA:'' <br />
ADD TO ME</div>Kjansen