Tutorials
MSU_TURBO

This Page Illustrates How to Run Different
Cases Using MSU TURBO.


Below are listed the current tutorials available. Tutorials for additional formats will be added at a later date.






APNASA

MULTI BLADE ROW CASES



PLOT3D

SINGLE BLADE ROW CASES
 
 









This page is under construction. Please be patient while we construct tutorials for your use.



 
 
 
 

SINGLE BLADE ROW CASES

This tutorial illustrates the running of MSU TURBO for a case with a single blade row, a rotor.
The initial grid used in this example is in PLOT3D format.
 

UNDERSTANDING THE INTERFACE

Before starting this tutorial, it is suggested that the user try to familiarize him-/herself with the navigation of the MSU TURBO Interface. The figure below has labeled the modules currently supported in MSU TURBO. The MSU TURBO interface came about as an attempt to reduce the complexity of case setup and the associated human error. Owing to the number of parameters available for use, it is quite possible that some parameters could be set in opposition to others; by performing a series of checks on the case input parameter files (input0#), this interface is capable of catching a large quantity of input conflicts and errors. If the input parameter files exist in the working directory, these checks are performed as the interface is started. If a user starts a job from scratch within the MSU TURBO interface, the input parameter files are created in that directory and the input parameters are checked as they are set by the user. For those who prefer to manipulate the input parameter files directly, it is suggested that the files are read into the interface for checking. Please realize that this interface is still under development, and is not guaranteed to catch every conflict or problem. As with any software, user feedback is very helpful in the development process. Please send all comments, questions, or problems to the webmaster .
MSU TURBO Interface

MSU TURBO Graphical User Interface


INPUT FILE NAMING CONVENTION

Before starting up GUMBO (labeled Grid BC's on the interface), it is important to understand GUMBO file nomenclature -- to understand what data formats are supported by  GUMBO and how they are identified. This section deals with the naming convention required by GUMBO for a grid file in PLOT3D format. The naming format is seen below: where the casename is arbitrary and dependent on the user. The r and b refer to the blade row and blade passage numbers, respectively. The string p3d designates PLOT3D formatting. The letter g refers to the fact that this is a grid file. Lastly, the r or b at the end of the filename refers to the whether the files are unformatted single precision/double precision ( r4/r8) or binary single precision/double precision ( b4/b8); no r4/r8/b4/b8 suffix indicates a straight ASCII text file.

This tutorial will use a single blade row case with a single precision, Cartesian grid file and has a casename of r67. Following the naming convention described above, the grid file is renamed to the following:

As you can see, since there is only one blade row and one blade passage under consideration, the word r#b# is designated as r1b1.

Note: At this point, MSU TURBO only supports cases with up to 20 blade rows. Please contact the webmaster for information on setting up cases that exceed this limit.

RUNNING MSU TURBO

GUMBO

GUMBO may be accessed either from within the MSU TURBO interface, or it may be called as an argument within the MSU TURBO command.

GUMBOinputscreen_blank.gif
GUMBO Input Screen
To access GUMBO from within MSU TURBO, click on the Grid BC's button on the interface; this will bring up GUMBO 's input screen. The user has the option of entering the casename (as described above in INPUT FILE NAMING CONVENTION ) within the Case Name text box before pressing Launch to bring up the GUMBO interface. If a casename is prescribed here, all pre-existing GUMBO files (contained within the present working directory) named in direct association with that casename (including casename.bc, casename.dmap, casename.turbo, casename.case) shall be loaded. Should the user not elect to specify the casename, GUMBO will load all pre-existing MSU TURBO input files, including bc.in, dmap.in, turbo.in, GU#, DU#, and/or QU# files).

To access GUMBO directly from the command line, one may type

>>>msuturbo -case casename

As in the first scenario, the casename may be specified at the user's discretion (it is not necessary). Again, GUMBO will read pre-existing GUMBO files directly associated with the casename if the casename is specified, and GUMBO will read MSU TURBO input files directly if no casename is specified.

Setting the Boundary Conditions

To ensure proper functioning of all selection and manipulation functions within GUMBO , please disengage the Num-Lock!

Once the GUMBO interface is up, the r67 single blade passage should be in the display window. Click on the BC's button to access the BC's panel; this panel shall contain two lists: Choose One: and Display. The boundary conditions contained within these lists can be referenced in the ONLINE DOCUMENTATION . To place a boundary condition, the block must first be selected. This can be done by placing the arrow over that block in the display area and pressing F11, or the right mouse button. A face can be selected in a similar manner by placing the arrow over the appropriate face on the volumetric representation and pressing F9, or the middle mouse button. The block, or face, should turn red to indicate that it has been selected. Pressing the Grid ID >>>> button will bring that block's indices up in the BCs area. An entire or partial face can then be picked on that block by using the IJK MIN/MAX plane buttons and sliders. Once the appropriate face (or portion of it) has been selected, the boundary condition for it must be picked out of the Choose One: list and the Apply button pressed. This will place the boundary condition on the selected face. That boundary condition can be displayed on the block selected in Grid ID >>>> by picking it in the Display list. If the number placed in that box is 0, then the chosen boundary condition will be displayed on all the blocks to which it has been applied.

When placing boundary conditions, please take into consideration that some boundary conditions automatically set both the MIN and MAX faces at the same time. For example, if a periodic_k boundary condition is set on a KMIN face, GUMBO automatically places that same boundary condition on the KMAX face. If the same boundary condition is applied to a face that already has that boundary condition set, error messages may result. It is always a good idea to check the boundary conditions after all faces have been set by pressing the Check button in the upper right hand corner of the BCs area.

If placing more than one boundary condition on a face, it is usually easiest to accomplish by first setting the boundary condition that takes up the majority of the face. For example, with the r67 case, a periodic_k boundary condition is set on the KMIN face (and thus the KMAX as well). There is a blade within that face with a leading edge at I=21, trailing edge at I=41, and the tip at J=26 (root at J=1). The blade should have a no-slip boundary condition applied to it. This can be done by simply selecting the KMIN button, specifying the leading edge and trailing edge I-indices and the root and tip J-indices, and then pressing Apply . To specify the "lower-bound" of the I or J index, highlight the radio button to the left of the respective slider and then adjust the slider appropriately; to specify the "upper-bound" of the I or J index, highlight the radio button to the right of the respective slider and then adjust the slider appropriately.  This will set a no-slip boundary condition on the blade on the KMIN face and leave the rest of the face a periodic_k boundary condition. The blade's no-slip boundary condition will need to be applied to the KMAX face as well. This is not automatic. Note that there is no "tip surface" at which to apply another no-slip boundary condition.  An example of what the BCs area should look like as well as a picture illustrating where the no-slip boundary conditions were applied are below:
 

Applied No-Slip Boundary Condition
BC's Area

All grid volume faces on the grid boundaries must have one (and only one) boundary condition applied to them.  For this case we seek to employ Isentropic Inlet (isentropic_in) flow for the entire I=1 face and Radial Equilibrium Exit (rad_eq_exit) flow for the entire I=IMAX face.    If at anytime one should improperly define a proposed boundary condition, one need only correctly specify a "new" boundary condition; the other boundary condition shall be overwritten and eliminated.

One may visually verify the correct application of boundary conditions using the Display BC: list in the BCs panel: one or more BC-types may be highlighted in the  GUMBO display (simultaneously) by highlighting the respective BC-types in the Display BC: list (simultaneously).  To "unclutter" the  GUMBO display, one may toggle off display of all BC's within the Display BC: list.

The next step, once the boundary conditions have been set, is to save these boundary conditions in a file called casename.bc. This file saves what boundary conditions were set and where they were set so that later on, if the user wishes to repartition the grid differently, they can do so without having to redefine the boundary conditions for the entire grid. GUMBO will automatically read the boundary conditions from this file when it finds it present in the running directory. To write out casename.bc, go to the Save area. In that area, there will be an option called Case Name. Check the box beside the option and enter the case name of your grid. It is a good idea to put a case name slightly different than the one that was read into GUMBO . This way that file(s) does not get overwritten. Once Save Data has been pressed, GUMBO will write out a grid file with that case name as well as files titled casename.bc, casename.dmap, casename.turbo, and casename.case. In this example, the files written out might be:

It is important that these files be written out before partitioning if it is to be used later on to repartition the grid differently. These files are useful later on for the MSUTurbo locate and merge utilities. These will be discussed in the MERGING OUTPUT FILES section.

Partitioning the Grid

The grid is now ready to be partitioned. After going to area Manip in the GUMBO interface, select the volumetric representation (or "block") to be split. Within the Manip area, the sections that the block should be split into can be selected equally or not. To split the block into equal partitions, simply enter the division sign / , followed by the number of divisions, in the at Index text field, and press Split . To select unequal sized partitions, use the sliders provided to define the size of the blocks and the directions of the splits. Once that is done, pressing the Split button will block up the grid in the manner specified. For this example, ten equal blocks were desired, so /10 was entered in the at Index text field and Split was pressed. This yielded ten equally sized partitions of the grid. For further documentation on partitioning grids, please use the reference material on GUMBO available in the ONLINE DOCUMENTATION .

Saving the Data

After partitioning, the blocks need to be indexed in the proper order (Note: When using sliding interfaces, block indices must increment sequentially in the clockwise [looking downstream] direction, starting with the blocks on the upstream side of the interface) . To do so, it is necessary to select the blocks (using the F11 key as discussed previously) in the sequence they should be numbered (block 1, block 2, block 3, ...). Once they are ALL selected, go to the Info area, select Block ID, and then press Set ID . The blocks will then be renumbered in the proper order. Remember, to do this properly, ALL of the blocks need to be selected at the same time.

Now the partitioned blocks are ready to be written out as GU# files. In the Save area, select Grid File, and type -GU in the text field; ensure that the Case Name selection box is unchecked to avoid overwriting unpartitioned case data with partitioned case data. Pressing Save Data will tell GUMBO to write out the GU# files as well as files called bc.in, dmap.in, and turbo.in. These files are described in detail in the CUSTOMIZATION section under Input Files .

The GUMBO output/ TURBO input data is now ready for use in TURBO .

TURBO

Setting Up Input Parameters


The interface was designed with both the novice and expert user in mind. If the Input Parameters button is pressed, the Parameters area of the GUI will appear. This section contains a "tab" for each namelist section that could be used as input for MSU TURBO. Looking at the image Parameters Area of the Parameters section, the "tabs" are clearly visible at the top with directional arrows for scrolling through them from left to right or vice-versa.
parameters_section.gif pmtrs_soln_section.gif
MSUTurbo: Parameters Tab
MSUTurbo: Solution Parameters Tab

Notice at the bottom of both images that there are colored boxes for "Change Required", " Change Optional", and "Advanced Users ". These colors are to assist in choosing which parameters to change and/or whether they need change. Examples of this can be seen in the image MSUTurbo: Solution Parameters Tab . By referencing the INPUT PARAMETERS in the ONLINE DOCUMENTATION section of this website, the parameters under each tab can be changed for the job being set up. As a value is typed in a text field, if that value conflicts with a value for any related flag, a dialog box will appear to inform the user of the conflict. The appropriate values for that flag will also be displayed in the dialog box. Until the conflict is resolved, the user will not be allowed to proceed.
For this example case (the r67), the input files (input00, input01) are provided for the user. So if the interface is started in the directory where they exist, they will be read in and checked. The images above of the Parameters area are of the interface with the r67 input files. Just to understand how the checking works, try entering -1 in the green text box for num_iter_per_printout . This number is not an option for that flag. An error box explaining the acceptable options will appear until it is changed to a reasonable number.
Once all changes/corrections have been made to the input parameters, the Save button in the TURBO Setup area must be pressed to write the input files out to the working directory. These changes must be saved before a job can be started.

Launching a Job from MSU TURBO

The Launch Solver button on the interface will launch an xterm window from which the job can be started. It is necessary to have a shell script within the working directory that uses your system's queueing system. Several script files (labeled run.#) are provided with MSU TURBO for a PBS Queueing system on various platforms. Your system may or may not use this same queueing system. These are provided as a guide structuring your own scripts. Please contact your system administrator for more information on queueing commands for your particular system.

TURBO's Output Files

Once TURBO has finished running, there will be several pertinent output files in the running directory. Files listed with a # below will be written out for each processor. For example, if three processors were being used, the TURBO.#0.out file would be found in the running directory as TURBO.10.out, TURBO.20.out, and TURBO.30.out . Each output file is listed below with a brief description of its contents:
Note that the number displayed after the q in the files ast.b#.q# is an indication of the cycle number at which the solution file was written, while the number displayed after the b indicates the computational block.

Merging Output Files

MSU TURBO now has a command line tool that eases the complications of post-processing a parallel job. This tool employs two utilities, msuturbo -locate and msuturbo -merge. To start, msuturbo -locate must be used to create the casename.insert and casename.extract files. Once those exist in the working directory, msuturbo -merge is used (with the appropriate flags) to merge the solution files back into the original grid blocking. The flags used with these utilities are listed below for reference:

Flags
Description
Restrictions
-locate Used to relate partitioned grid to original unpartitioned grid.
GU & (VSTAGE/PLOT3D) files must exist in same directory.
Creates casename.insert and casename.extract.
 -case (must be used)
-case Used to read the casename of the original unpartitioned grid into -locate and -merge.
Example: msuturbo -locate -case casename
 Must be used with -locate and -merge
-merge Used to "merge" ast.b#.q# solution files into the number of blocks of the
original unpartitioned grid. Writes out single precision solution and grid files.
All input0#, casename.# files must co-exist in the working directory.
 -case (must be used)
-rel Converts solution data into relative frame. used only with -merge
-old Used if ast.# files are in the old format of
ast.b0#.g and ast.b0#.q# 		used only with -merge
-qid Used to specify which solution files to merge.
The number that should be placed after -qid is the number after the q in solution files to be merged.
Example: msuturbo -merge -case casename -qid 1500 		used only with -merge
-vstage Used if ast files were created from APNASA VSTAGE files. used only with -merge

MSU TURBO Merge and Locate Utility Flags

Now the r67 will be used as an example in walking through how the the locate and merge utilities work. In the two images below the flags num_printouts, num_iter_per_printout, num_iter_per_soln_dump , and num_soln_per_flow_file have been modified. Interpreting these values, a job should run for 200 iterations with 2 printouts (after iterations 100 and 200 respectively). The total number of iterations was computed by multiplying num_printouts and num_iter_per_printout . An initial solution file, called ast.b#.q0, will be written out before anything else is done. A solution will then be written to a file every 25 iterations until there are 4 solutions in a flow file. Thus, at iteration 25 a solution will be written to a file called ast.b#.q25. The subsequent three solutions (at iterations 50, 75, and 100) will be appended to that same file. Next, at iteration 125, the file ast.b#.q125 will be created with the solution at iteration 125 and the next three solutions will be placed in it as well. The solution files written out should look like the following:

ast.b1.q0 ast.b1.q25 ast.b1.q125 Solution Parameters Output Parameters
ast.b2.q0 ast.b2.q25 ast.b2.q125
ast.b3.q0 ast.b3.q25 ast.b3.q125
ast.b4.q0 ast.b4.q25 ast.b4.q125
ast.b5.q0 ast.b5.q25 ast.b5.q125
ast.b6.q0 ast.b6.q25 ast.b6.q125
ast.b7.q0 ast.b7.q25 ast.b7.q125
ast.b8.q0 ast.b8.q25 ast.b8.q125
ast.b9.q0 ast.b9.q25 ast.b9.q125
ast.b10.q0 ast.b10.q25 ast.b10.q125
Example Output Solution Files
Changed Solution Parameters
Changed Output Parameters


The first step to merging these ten solution files back into one is to use msuturbo -locate at the command line followed by the accompanying -merge command:

>>>msuturbo -locate -case r67_withbcs
>>>msuturbo -merge -rel -case r67_withbcs -qid 25
where r67_withbcs is the casename of the files we wrote out earlier in the SETTING THE BOUNDARY CONDITIONS section and the number after -qid is the solution file number. The first command will write out two files called r67_withbcs.insert and r67_withbcs.extract. With these files, the second command will merge the ten partitioned solution files (with solutions starting at iteration 25) into four different solution files named in the following manner: Since there can be more than one solution in each ast.b#.q# solution file, the number directly before the .r4 corresponds to the appropriate solution within each ast.b#.q# file. Please note that the merge utility will also write out an accompanying single precision grid file called r67_withbcs.r1b1.p3d.g.r4

Merging Output Files in Parallel

MSU TURBO also has a tool to merge solutions and grids in parallel. The source code is available to users upon request. To perform the parallel merge, the files casename.insert, casename.extract, input00 , input0x , ast.b#.x, ast.b#.q# , and pmerge.in must exist in the working directory. These files casename.insert , casename.extract are the same as above, obtained through  utilities msuturbo -locate. Files  input00 , input0x are TURBO input parameter files used to generate the simulation results ast.b#.q# and grids ast.b#.x. The  files can be either in PLOT3D format or NASA VSTAGE format (Those formats are controlled by TURBO input parameter "output_format" in file input00 ). The file pmerge.in contains parameters which control the parallel merge process. The total number of processors needed for the parallel merge process must be identical to the number of blocks in the original grids (usually the number of total blade passages in the computational domain).

The control parameters in file pmerge.in are specified as:
Parameters
Description
case_name case_name='r67_withbcs'
This case_name tells the merge process to look for the partition info files r67_withbcs.insert and r67_withbcs.extract .
The case name is also applied as the prefix of the output merged grid and solution files, such as
r67_withbcs.r1b1.p3d.g
r67_withbcs.r1b1.p3d.q25
iter_start
iter_end
iter_step
 These integer parameters specify the merge process over a series of solutions,
starting from iter_start, ending at iter_end, incrementing by iter_step.
 
msu_or_apnasa msu_or_apnasa=1: the merged solutions are in PLOT3D format by MSU normalization. Grids are right-handed
msu_or_apnasa=2: the merged solutions are in PLOT3D format by APNASA normalization. Grids are left-handed
relative_or_abs relative_or_abs=1 : convert solutions into relative frame
relative_or_abs=2:  solutions are in absolute frame
motion_grid motion_grid=F:
Grids are fixed without consideration of motion.
Merged grids are created at the first iteration (iter_start) and named as r67_withbcs.r1b1.p3d.g

motion_grid=T:
Rotor grid is moved to its physical position corresponding to the time step.
Rotor grid files are generated at every iteration and named as r67_withbcs.r1b1.p3d.g####




        Example pmerge.in file:
&PMERGE_PARAMETERS
case_name='r67_withbcs'
iter_start=25
iter_end=50
msu_or_apnasa=2
relative_or_abs=1
motion_grid=T
/

                               


 
 






MULTI BLADE ROW CASES

This tutorial illustrates the running of MSU TURBO for a case with a rotor and stator with time-shift (phase-lag) history data.
Initial grid and solution files used are in APNASA format.

 

UNDERSTANDING THE INTERFACE

Before starting this tutorial, it is suggested that the user try to familiarize him-/herself with the navigation of the MSU TURBO Interface. The figure below has labeled the modules currently supported in MSU TURBO. The MSU TURBO interface came about as an attempt to reduce the complexity of case setup and the associated human error. With the number of parameters available for use, it is not hard to set some parameters in opposition to others. By performing a series of checks on the case input parameter files (input0#), the interface is capable of catching a large quantity of input conflicts and errors. If the input parameter files exist in the working directory, these checks are performed as the interface is started. If a user starts a job from scratch within the MSU TURBO interface, the input parameter files are created in that directory and the input parameters are checked as they are set by the user. For those who prefer to manipulate the input parameter files directly, it is suggested that the files are read into the interface for checking. Please realize that this interface is still under development, and is not guaranteed to catch every conflict or problem. As with any software, user feedback is very helpful in the development process. Please send all comments, questions, or problems to the webmaster .
MSU TURBO Interface

MSU TURBO Graphical User Interface



INPUT FILE NAMING CONVENTION

For initial grid and solution files in APNASA format, a certain naming convention must be adopted for those files to be read in by GUMBO , MSUTurbo 's preprocessor. Files need to be renamed in the manner below for GUMBO to accept them:
where the casename is arbitrary and dependent on the user. The rand b refer to the blade row and blade passage numbers respectively. The string vstage does not change and stands for the VSTAGE format. The letters g and q refer to the grid and solution files. Lastly, the r or b at the end of the filename refers to the whether the files are unformatted single precision/double precision (r4/r8) or binary single precision/double precision (b4/b8).

This tutorial will use a two blade row case that is single precision and has a casename of s37_ts. Following the naming convention described above, the grid and solution files are renamed to the following:

Notice that there are four files and not two. This is because generally there will be a separate grid and solution file for each blade row. Above, you can see that the first two files are the grid and solution for the first blade passage of the first blade row (r1b1) and the second two are for the first blade passage of the second blade row ( r2b1).

OTHER NECESSARY INPUT FILES

In addition to changing the names of APNASA input grid and solution files, it is also convenient to create additional input files that GUMBO will need for setting up the grids and blocking. If these files are not present, GUMBO will prompt the user for additional information.
The first two additional files will have the naming convention casename.r#.info where the number that goes with r corresponds to a particular blade row. For this case of two blade rows, there will be a s37_ts.r1.info and a s37_ts.r2.info. Each one of these two files will contain information about the hub clearance, tip clearance, and the number of time steps stored for time-shift history data for that particular blade row. These info files are available below for your examination and/or use.
Along with the .info files, there are two other files that GUMBO can use for input. These files are placed in the running directory of MSUTurbo if the user decides to use base flow (steady or unsteady). Their naming convention is of the following form:
If the case used for illustration in this tutorial were to use steady exit base flow, a file named cor.exit_steady would be needed in the running directory of MSU TURBO. Note that this file is generated by a preprocessor specifically for MSU TURBO . After it has been generated, the name can be changed, by the above convention, so that GUMBO can read it in. This particular case was actually run with a cor.exit_steady file. If you have no knowledge of the how to generate these files, please check with the webmaster for further information.

The bc.in, dmap.in, and turbo.in files (seen in the list of supplied input files) are generated by GUMBO along with GU# and QU# files. These three files contain information pertaining to the boundary conditions, block connectivity, and the blocks sliding interfaces. These files and the input0# files, along with the GU# and QU# files, are the only input files that the flow solver, TURBO , requires.

RUNNING MSU TURBO

GUMBO

GUMBO has two main options for reading in files from MSU TURBO. Regardless of which starting option is chosen for GUMBO , it should only be pulled up after it has been ascertained that the two .info files and the cor.exit/inlet file (if used) are present in the same running directory as the interface.

GUMBOinputscreen_blank.gif
GUMBO Input Screen
The first option requires clicking the Grid BC's button on the MSU TURBO interface to bring up GUMBO 's input screen. Here, the user can type in the case name (as described above in INPUT FILE NAMING CONVENTION ) in the Case Name text box and press Launch to bring up the GUMBO interface.

To use the second option, the Launch button must be clicked while the Case Name part of the GUMBO input screen remains blank. This option will read files generated from MSU TURBO (in the form of bc.in, dmap.in, turbo.in, GU#, and/or QU# files) directly into GUMBO if they are found in the working directory. The GUMBO interface will appear with these partitioned files in the display window.

About Boundary Conditions for the APNASA Format

Because files in the APNASA VSTAGE format generally already have boundary conditions applied to them, boundary condition application will not be covered in this tutorial. However, if a user wishes to change existing boundary conditions, information and tutorials on changing BC's in GUMBO can be found in the ONLINE DOCUMENTATION . Once changes to the boundary conditions have been made (if any), it is important to save the unpartitioned grid and bc's. If the user wishes to repartition the grid differently, he/she can do so later on from these saved files without having to redefine the boundary conditions for the entire grid. GUMBO will automatically read the boundary conditions from this file when it finds it present in the running directory. To write out these files, go to the Save area. In that area, there will be an option called Case Name. Check the box beside the option and enter the case name of your grid. It is a good idea to put a case name slightly different than the one that was read into GUMBO . This way that file(s) does not get overwritten. Once Save Data has been pressed, GUMBO will write out a grid file with that case name as well as files titled casename.bc, casename.dmap, casename.turbo, and casename.case. In this example, the files written out might be: It is important that this file be written out before partitioning if it is to be used later on to repartition the grid differently. These files are useful later on for the MSUTurbo locate and merge utilities. These will be discussed in the MERGING OUTPUT FILES section.

Partitioning the Grid

With the s37_ts in the display window, repartitioning can begin. Select one of the volumetric representations (or "blocks") for partitioning by placing the arrow over the block and pressing the F11 key, or the right mouse button. The selected block should now be red in color. Partitioning of the block is done in the Manip area.

Within the Manip area, the selected block can be split equally or not. To split the block into equal partitions, simply enter the division sign /, followed by the number of divisions, in the at Index text field, and press Split. To select unequal sized partitions, use the sliders provided to define the size of the blocks and the directions of the splits. Once that is done, pressing the Split button will block up the grid in the manner specified. For this example, three equal partitions were desired from the block representing the first blade row and two equal partitions were desired from the second blade row. To do the partitioning this way, the first block was selected and /3was entered at the at Index text field (in the Manip area). Pressing Split divided the block into three equal sections. The same procedure was followed for the second block except /2 was entered in the at Index text field. The difference between the grid before and after partitioning can be seen in the images below. For further documentation on partitioning grids, please use the reference material on GUMBO available in the ONLINE DOCUMENTATION section.

befores37_ts_sm.gif (121K) afters37_ts_sm.gif (122K)
Before Partitioning
After Partitioning

After partitioning, the new blocks need to be indexed in the proper order. To index the partitions, it is necessary to select the blocks (using the F11 key as discussed previously) in the sequence they should be numbered (block 1, block 2, block 3, ...). Once they are ALL selected, go to the Info area, select Block ID, and then press Set ID. The blocks will then be renumbered in the proper order. Remember, to do this properly, ALL of the blocks need to be selected at the same time.

Now the partitioned blocks are ready to be written out as GU# files with their corresponding QU# files. In the Save area, select Grid File , and type -GU in the text field. Pressing Save Data will tell GUMBO to write out the GU# and QU# files as well as the three .in files.

Note:For users who prefer manually editing the files written out by GUMBO , example files are provided in the CUSTOMIZATION section, under Input Files .

TURBO

Setting Up Input Parameters


The interface was designed with both the novice and expert user in mind. If the Input Parameters button is pressed, the Parameters area of the GUI will appear. This section contains a "tab" for each namelist section that could be used as input for MSU TURBO. Looking at the image Parameters Area of the Parameters section, the "tabs" are clearly visible at the top with directional arrows for scrolling through them from left to right or vice-versa.
parameters_section_V3.gif pmtrs_soln_section.gif
MSUTurbo: Parameters Tab
MSUTurbo: Solution Parameters Tab

Notice at the bottom of both images that there are colored boxes for "Change Required", "Change Optional", and "Advanced Users". These colors are to assist in choosing which parameters to change and/or whether they need change. Examples of this can be seen in the image Parameters Section: Solution . By referencing the INPUT PARAMETERS in the ONLINE DOCUMENTATION section of this website, the parameters under each tab can be changed for the job being set up. As a value is typed in a text field, if that value conflicts with a value for any related flag, a dialog box will appear to tell the user of the conflict. The appropriate values for that flag will also be displayed in the dialog box. Until the conflict is resolved, the user will not be allowed to proceed.
For this example case (the s37_ts), the input files (input00, input01) are provided for the user. So if the interface is started in the directory where they exist, they will be read in and checked. The images above of the Parameters area are of the interface with the s37_ts input files. Just to understand how the checking works, try entering -1 in the green text box for num_iter_per_printout . This number is not an option for that flag. An error box explaining the acceptable options will appear until it is changed to a reasonable number.
Once all changes/corrections have been made to the input parameters, the Save button in the TURBO Setup area must be pressed to write the input files out to the working directory. These changes must be saved before a job can be started.

Launching a Job from MSU TURBO

The Launch Solver button on the interface will launch an xterm window from which the job can be started. It is necessary to have a shell script within the working directory that uses your system's queueing system. Several script files (labeled run.#) are provided with MSU TURBO for a PBS Queueing system on various platforms. Your system may or may not use this same queueing system. These are provided as a guide structuring your own scripts. Please contact your system administrator for more information on queueing commands for your particular system.

MSU TURBO's Output Files

Once MSU TURBO has finished running, there will be several pertinent output files in the running directory. The files listed with a # below will be written out for each processor. For example, if three processors were being used, the TURBO.#.out file would be found in the running directory as TURBO.1.out, TURBO.2.out, and TURBO.3.out. Each output file is listed below with a brief description of its contents:
The following example illustrates more thoroughly how solutions are written out to the q file for each processor. For our example case, five processors are used. The code (MSU TURBO ) will be run for 400 cycles and a solution file containing five solutions (num_iter_per_soln_dump = 20, num_soln_per_flow_file = 5) will be written out every 100 cycles. There will be 5 solution files, with the first file containing the initial/restart solution and the rest containing subsequent solutions. For one processor, they could very well be named the following:
First, we can see from the suffix b3 that these solution files were written out by processor 3. Whatever number is behind the b is the number corresponding to the processor that wrote out the file. The first file ast.b3.q0 was written out after the first cycle, containing only the initial/restart (one) solution. The second file ast.b3.q20 was written out after 20 cycles, and would contain the subsequent 5 solutions (i.e. solutions at iterations 20,40,60,80,100). The file ast.b3.q120 was written out after 120 cycles, and would contain the next 5 solutions. This process would continue until at last, the file ast.b3.q320 was written out after 320 cycles, which would contain the last 5 solutions.

Merging Output Files

MSU TURBO has a command line tool that eases the complications of post-processing a parallel job. This tool employs two utilities, msuturbo -locate and msuturbo -merge. To start, msuturbo -locate must be used to create the casename.insert and casename.extract files. Once those exist in the working directory, msuturbo -merge is used (with the appropriate flags) to merge the solution files back into the original grid blocking. The flags used with these utilities are listed below for reference:

Flags
Description
Restrictions
-locate Used to relate partitioned grid to original unpartitioned grid.
GU & (VSTAGE/PLOT3D) files must exist in same directory.
Creates casename.insert and casename.extract.
 -case (must be used)
-case Used to read the casename of the original unpartitioned grid into -locate and -merge.
Example: msuturbo -locate -case casename
 Must be used with -locate and -merge
-merge Used to "merge" ast.b#.q# solution files into the number of blocks of the
original unpartitioned grid. Writes out single precision solution and grid files.
All input0#, casename.# files must co-exist in the working directory.
 -case (must be used)
-rel Converts solution data into relative frame. used only with -merge
-old Used if ast.# files are in the old format of
ast.b0#.g and ast.b0#.q# 		used only with -merge
-qid Used to specify which solution files to merge.
The number that should be placed after -qid is the number after the q in solution files to be merged.
Example: msuturbo -merge -case casename -qid 1500 		used only with -merge
-vstage Used if ast files were created from APNASA VSTAGE files. used only with -merge

MSU TURBO Merge and Locate Utility Flags

Now the s37_ts will be used as an example in walking through how the the locate and merge utilities work. The example run described in the previous section on TURBO output files will be used.
The first step to merging the ten solution files (written out for each processor) back into one is to use msuturbo -locate at the command line followed by the accompanying -merge command:

>>>msuturbo -locate -case s37_ts_withbcs
>>>msuturbo -merge -rel -case s37_ts_withbcs -qid 25
where s37_ts_withbcs is the casename of the files we wrote out earlier in the ABOUT BOUNDARY CONDITIONS FOR THE APNASA FORMAT section and the number after -qid is the solution file number. The first command will write out two files called s37_ts_withbcs.insert and s37_ts_withbcs.extract. With these files, the second command will merge the ten partitioned solution files (with solutions starting at iteration 20) into eight different solution files named in the following manner: Note that there must be solution files written out for each blade row for each solution. Since there can be more than one solution in each ast.b#.q# solution file, the number directly before the .r4 corresponds to the appropriate solution within each ast.b#.q# file. Please note that the merge utility will also write out two accompanying single precision grid files called s37_ts_withbcs.r1b1.p3d.g.r4 and s37_ts_withbcs.r2b1.p3d.g.r4 .

Merging Output Files in Parallel

MSU TURBO also has a tool to merge solutions and grids in parallel. The source code is available to users upon request. To perform the parallel merge, the files casename.insert, casename.extract, input00 , input0x , ast.b#.x, ast.b#.q#, and pmerge.in must exist in the working directory. These files casename.insert, casename.extract are the same as above and obtained through  utilities msuturbo -locate. Files input00 , input0x are TURBO input parameter files used to generate the simulation results ast.b#.q# and grids ast.b#.x, which can be either in PLOT3D format or NASA VSTAGE format (Those formats are controlled by TURBO input parameter "output_format" in file input00 ). The file pmerge.in contains parameters which control the parallel merge process. The total number of processors needed for the parallel merge process must be identical to the number of blocks in the original grids (usually the number of total blade passages in the computational domain).

The control parameters in file pmerge.in are specified as:

PMERGE_PARAMETERS
Description
case_name case_name='s37_ts_withbcs'
This case_name tells the merge process to look for the partition info files
s37_ts_withbcs.insert
s37_ts_withbcs.extract .
The case name is also applied as the prefix of the output merged grid and solution files, such as
s37_ts_withbcs.r1b1.p3d.g
s37_ts_withbcs.r1b1.p3d.q####
iter_start
iter_end
iter_step
 These integer parameters specify the merge process over a series of solutions,
starting from iter_start, ending at iter_end, incrementing by iter_step.
 
msu_or_apnasa msu_or_apnasa=1: the merged solutions are in PLOT3D format by MSU normalization. Grids are right-handed
msu_or_apnasa=2: the merged solutions are in PLOT3D format by APNASA normalization. Grids are left-handed
relative_or_abs relative_or_abs=1 : convert solutions into relative frame
relative_or_abs=2:  solutions are in absolute frame
motion_grid motion_grid=F:
Grids are fixed without consideration of motion.
Merged grids are created at the first iteration ( iter_start) and named as s37_ts_withbcs.r1b1.p3d.g

motion_grid=T:
Stator grids are fixed; files are generated at the first iteration (iter_start) and named as s37_ts_withbcs.r2b1.p3d.g
Rotor grid is moved to its physical position corresponding to the time step.
Rotor grid files are generated at every iteration and named as s37_ts_withbcs.r1b1.p3d.g####

        Example pmerge.in file:
&PMERGE_PARAMETERS
case_name='s37_ts_withbcs'
iter_start=1
iter_end=20
msu_or_apnasa=2
relative_or_abs=1
motion_grid=T
/

                               


Please note that the examples provided here are just that...examples. So be aware that some modifications of these files and procedures will be necessary for your own cases. Further questions or comments can be directed to the Webmaster .



Last modified: Thu May 09 10:59:11 CDT 2003