http://ccrm.vims.edu/w/api.php?action=feedcontributions&feedformat=atom&user=Feiyeccrmwiki - User contributions [en]2026-05-07T07:59:49ZUser contributionsMediaWiki 1.31.1http://ccrm.vims.edu/w/index.php?title=%22xlsc0%22_(surface_mixing_length_scale_constant)&diff=1217"xlsc0" (surface mixing length scale constant)2018-05-25T14:45:33Z<p>Feiye: </p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) near the free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$\kappa=0.4$ is the von Karman's constant;<br />
<br />
$d_s$ = '''xlsc0''' $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, '''xlsc0''' should take a value between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the spacing between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1216FAQ2018-05-25T14:24:56Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. <br />
<br />
Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...."<br />
<br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
<br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
<br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
<br />
5. My run crashed; how can I find out why? <br />
<br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
<br />
See Manual Chapter 5.1.7.<br />
<br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
<br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Manual Chapter 5.1.7.<br />
<br />
<br />
8. I have large velocity at open boundary <br />
<br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Manual Section 5.4.<br />
<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
<br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
<br />
10. Need more explanations on some of the parameters in param.in? <br />
<br />
Send the request to the schism mailing list. Frequently asked ones will be added below and included into the manual if necessary:<br />
<br />
'''[["xlsc0" (surface mixing length scale constant)]]'''<br />
<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *[23]D.th -> *[23]D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
<br />
The usages of the scripts are described in the beginning lines of the source codes.<br />
<br />
The hotstart conversion script asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=%22xlsc0%22_(surface_mixing_length_scale_constant)&diff=1215"xlsc0" (surface mixing length scale constant)2018-05-25T14:24:20Z<p>Feiye: Created page with "For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) near the free surface is determined as $l=\kappa d_s$ (Zh..."</p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) near the free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$\kappa=0.4$ is the von Karman's constant;<br />
<br />
$d_s$ = '''xlsc0''' $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, '''xlsc0''' should take a value between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1214FAQ2018-05-25T14:24:13Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. <br />
<br />
Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...."<br />
<br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
<br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
<br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
<br />
5. My run crashed; how can I find out why? <br />
<br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
<br />
See Manual Chapter 5.1.7.<br />
<br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
<br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Manual Chapter 5.1.7.<br />
<br />
<br />
8. I have large velocity at open boundary <br />
<br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Manual Section 5.4.<br />
<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
<br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
<br />
10. Need more explanations on some of the parameters in param.in? <br />
<br />
Send the request to the schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[["xlsc0" (surface mixing length scale constant)]]'''<br />
<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *[23]D.th -> *[23]D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
<br />
The usages of the scripts are described in the beginning lines of the source codes.<br />
<br />
The hotstart conversion script asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1213FAQ2018-05-25T14:23:33Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. <br />
<br />
Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...."<br />
<br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
<br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
<br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
<br />
5. My run crashed; how can I find out why? <br />
<br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
<br />
See Manual Chapter 5.1.7.<br />
<br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
<br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Manual Chapter 5.1.7.<br />
<br />
<br />
8. I have large velocity at open boundary <br />
<br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Manual Section 5.4.<br />
<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
<br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
<br />
10. Need more explanations on some of the parameters in param.in? <br />
<br />
Send the request to the schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *[23]D.th -> *[23]D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
<br />
The usages of the scripts are described in the beginning lines of the source codes.<br />
<br />
The hotstart conversion script asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1212FAQ2018-05-25T14:22:57Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. <br />
<br />
Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...."<br />
<br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
<br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
<br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
<br />
5. My run crashed; how can I find out why? <br />
<br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
<br />
See Manual Chapter 5.1.7.<br />
<br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
<br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Manual Chapter 5.1.7.<br />
<br />
<br />
8. I have large velocity at open boundary <br />
<br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Manual Section 5.4.<br />
<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
<br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
<br />
10. Need more explanations on some of the parameters in param.in? <br />
<br />
Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *[23]D.th -> *[23]D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
<br />
The usages of the scripts are described in the beginning lines of the source codes.<br />
<br />
The hotstart conversion script asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1211FAQ2018-05-25T14:21:17Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. <br />
<br />
Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...."<br />
<br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
<br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
<br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
<br />
5. My run crashed; how can I find out why? <br />
<br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
<br />
See Chapter 5.1.7.<br />
<br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
<br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
<br />
8. I have large velocity at open boundary <br />
<br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
<br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
<br />
10. Need more explanations on some of the parameters in param.in? <br />
<br />
Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *[23]D.th -> *[23]D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
<br />
The usages of the scripts are described in the beginning lines of the source codes.<br />
<br />
The hotstart conversion script asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1210FAQ2018-05-25T14:20:42Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. <br />
<br />
Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...."<br />
<br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
<br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
<br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? <br />
<br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
<br />
See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
<br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary <br />
<br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
<br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? <br />
<br />
Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *[23]D.th -> *[23]D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
<br />
The usages of the scripts are described in the beginning lines of the source codes.<br />
<br />
The hotstart conversion script asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1209FAQ2018-05-25T14:18:00Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *[23]D.th -> *[23]D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
<br />
The usages of the scripts are described in the beginning lines of the source codes.<br />
<br />
The hotstart conversion script asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1208FAQ2018-05-25T14:17:40Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *[23]D.th -> *[23]D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
The usages of the scripts are described in the beginning lines of the source codes.<br />
The hotstart conversion script asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1207FAQ2018-05-25T14:15:15Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *3D.th or elev2D.th -> *_3D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
The hotstart conversion script asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1206FAQ2018-05-25T14:14:50Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *3D.th or elev2D.th -> *_3D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
The hotstart scripts asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which generates the grid info but does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1205FAQ2018-05-25T14:14:18Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *3D.th or elev2D.th -> *_3D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90).<br />
The hotstart scripts asks for "ns" (number of sides) as a command line input. The easiest way to find "ns" is to look at the beginning lines of your previous mirror.out, which list grid information; or, run your project with 1 core and "ipre=1" in param.in, which does not require hotstart.in.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1204FAQ2018-05-25T14:09:25Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *3D.th or elev2D.th -> *_3D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90)</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1203FAQ2018-05-25T14:09:15Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D or 2D boudary conditions: *3D.th or elev2D.th -> *_3D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
*hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
*nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90)</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1202FAQ2018-05-25T14:09:00Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
3D or 2D boudary conditions: *3D.th or elev2D.th -> *_3D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90);<br />
hotstart: hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90);<br />
nudging: *_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90)</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1201FAQ2018-05-25T14:06:48Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''<br />
<br />
11. I have some legacy input files in binary format that no longer work for the SCHISM versions after v5.6, do I need to re-write my scripts and generate the inputs in netcdf format?<br />
Not necessarily, here are a list of format conversion scripts in the source code folders:<br />
*3D.th -> *_3D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90)<br />
*2D.th -> *_2D.th.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_3Dth_nc.f90)<br />
hotstart.in -> hotstart.nc (''your_SCHISM_dir''/trunk/src/Utility/Gen_Hotstart/convert_hotstart_nc.f90)<br />
*_nu.in -> *_nu.nc (''your_SCHISM_dir''/trunk/src/Utility/Pre-Processing/convert_nudge_nc.f90)</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Xlsc0_(surface_mixing_length_scale_constant)&diff=1200Xlsc0 (surface mixing length scale constant)2018-05-24T01:45:09Z<p>Feiye: </p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) near the free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$\kappa=0.4$ is the von Karman's constant;<br />
<br />
$d_s$ = '''xlsc0''' $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, '''xlsc0''' should take a value between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Xlsc0_(surface_mixing_length_scale_constant)&diff=1199Xlsc0 (surface mixing length scale constant)2018-05-24T01:43:35Z<p>Feiye: </p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) near the free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$\kappa=0.4$ is the von Karman's constant;<br />
<br />
$d_s$ = xlsc0 $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, xlsc0 should take a value between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Xlsc0_(surface_mixing_length_scale_constant)&diff=1198Xlsc0 (surface mixing length scale constant)2018-05-24T01:43:26Z<p>Feiye: </p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) near the free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$\kappa=0.4$ is the von Karman's constant;<br />
<br />
$d_s$ = xlsc0 $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, xlsc0 take a value between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Xlsc0_(surface_mixing_length_scale_constant)&diff=1197Xlsc0 (surface mixing length scale constant)2018-05-24T01:42:44Z<p>Feiye: </p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) near the free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$\kappa=0.4$ is the von Karman's constant;<br />
<br />
$d_s$ = xlsc0 $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, the value of xlsc0 should be between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1196FAQ2018-05-24T01:41:10Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. Frequently asked ones will be added below and included into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Xlsc0_(surface_mixing_length_scale_constant)&diff=1195Xlsc0 (surface mixing length scale constant)2018-05-23T21:24:09Z<p>Feiye: Created page with "For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is determined as $l=\kappa d_s$ (Zhang an..."</p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$\kappa=0.4$ is the von Karman's constant;<br />
<br />
$d_s$ = xlsc0 $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, the value of xlsc0 should be between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1194FAQ2018-05-23T21:23:31Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. We'll constantly add frequently asked ones below and include them into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1193FAQ2018-05-23T21:22:34Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. We'll constantly add frequently asked ones below and include them into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant) in param.in]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1192FAQ2018-05-23T21:22:14Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. We'll constantly add frequently asked ones below and include them into to the manual if necessary:<br />
<br />
'''[[xlsc0 (surface mixing length scale constant) in param.in]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1191FAQ2018-05-23T21:21:35Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select 'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration.<br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info.<br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and the proportionality constants are defined in param.in: s1_mxnbt = 0.5 s2_mxnbt = 3.5 95 (Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy.<br />
<br />
4. How to do a tidal simulation with SCHISM? The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable.<br />
<br />
5. My run crashed; how can I find out why? The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. Sometimes you want to visualize the problem right before the crash. You cannot use autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs.<br />
<br />
6. How to impose river discharge if the depth is negative there? See Chapter 5.1.7.<br />
<br />
7. Run crashes with a dry boundary/depth error. SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7.<br />
<br />
8. I have large velocity at open boundary In hydrostatic models, the incoming velocity should be specified at open boundary. Over-specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4.<br />
<br />
9. fort.11 indicates “Could not find suitable element in input” This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.<br />
<br />
10. Need more explanations on some of the parameters in param.in? Send the request to schism mailing list. We'll be constantly adding frequently asked ones below and include them into to the manual if necessary:<br />
'''[[xlsc0 (surface mixing length scale constant) in param.in]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Xlsc0_(surface_mixing_length_scale_constant)_in_param.in&diff=1190Xlsc0 (surface mixing length scale constant) in param.in2018-05-23T20:59:04Z<p>Feiye: </p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$\kappa=0.4$ is the von Karman's constant;<br />
<br />
$d_s$ = xlsc0 $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, the value of xlsc0 should be between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Xlsc0_(surface_mixing_length_scale_constant)_in_param.in&diff=1189Xlsc0 (surface mixing length scale constant) in param.in2018-05-23T20:54:40Z<p>Feiye: Created page with "For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is determined as $l=\kappa d_s$ (Zhang an..."</p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$d_s$ = xlsc0 $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, the value of xlsc0 should be between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1188FAQ2018-05-23T20:54:34Z<p>Feiye: </p>
<hr />
<div>'''[[FAQs in the v5.6 manual]]'''<br />
<br />
'''[[xlsc0 (surface mixing length scale constant) in param.in]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1187FAQ2018-05-23T20:54:22Z<p>Feiye: </p>
<hr />
<div>'''[[FAQs in the v5.6 manual]]'''<br />
<br />
'''[[xlsc0 (surface mixing length scale constant)]] in param.in]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1186FAQ2018-05-23T20:54:05Z<p>Feiye: </p>
<hr />
<div>'''[[FAQs in the v5.6 manual]]'''<br />
<br />
'''xlsc0 (surface mixing length scale constant)]] in param.in'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Further_explanations_on_parameters:_xlsc0_(surface_mixing_length_scale_constant)&diff=1185Further explanations on parameters: xlsc0 (surface mixing length scale constant)2018-05-23T20:51:36Z<p>Feiye: Created page with "For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is determined as $l=\kappa d_s$ (Zhang an..."</p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$d_s$ = xlsc0 $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, the value of xlsc0 should be between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1184FAQ2018-05-23T20:51:09Z<p>Feiye: </p>
<hr />
<div>'''[[FAQs in the v5.6 manual]]'''<br />
<br />
'''[[Further explanations on parameters: xlsc0 (surface mixing length scale constant)]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1183FAQ2018-05-23T20:49:14Z<p>Feiye: </p>
<hr />
<div>'''[[FAQs in the v5.6 manual]]'''<br />
<br />
'''[[ xlsc0 (surface mixing length scale constant)]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1182FAQ2018-05-23T20:48:23Z<p>Feiye: </p>
<hr />
<div>'''[[FAQs in the v5.6 manual]]'''<br />
<br />
'''[[ xlsc (surface mixing length scale constant)]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Xlsc_(surface_mixing_length_scale_constant)&diff=1181Xlsc (surface mixing length scale constant)2018-05-23T20:47:26Z<p>Feiye: </p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is determined as<br />
<br />
$l=\kappa d_s$ (Zhang and Baptista, 2008), <br />
<br />
where<br />
<br />
$d_s$ = xlsc0 $\cdot$ ''surface layer thinkness''.<br />
<br />
As a scale constant, the value of xlsc0 should be between 0 and 1. Note that the spatially varying option (xlsc.gr3) is disabled in the latest SCHISM version.<br />
<br />
If wind wave module is invoked, the ''surface layer thickness'' is taken as 0.6$H_s$ (significant wave height) following Terray et al. (1996); otherwise, it is taken as the distance between the top two vertical layers. <br />
<br />
<br />
'''References''':<br />
<br />
Terray, E.A., Donelan, M.A., Agrawal, Y.C., Drennan, W.M., Kahma, K.K., Williams, A.J., Hwang, P.A. and Kitaigorodskii, S.A., 1996. Estimates of kinetic energy dissipation under breaking waves. Journal of Physical Oceanography, 26(5), pp.792-807.<br />
<br />
Umlauf, L. and Burchard, H., 2003. A generic length-scale equation for geophysical turbulence models. Journal of Marine Research, 61(2), pp.235-265.<br />
<br />
Zhang, Y. and Baptista, A.M., 2008. SELFE: a semi-implicit Eulerian–Lagrangian finite-element model for cross-scale ocean circulation. Ocean modelling, 21(3-4), pp.71-96.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=Xlsc_(surface_mixing_length_scale_constant)&diff=1180Xlsc (surface mixing length scale constant)2018-05-23T20:33:08Z<p>Feiye: Created page with "For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is $l=\kappa d_s$, (Zhang and Baptista, 2..."</p>
<hr />
<div>For the Generic Length Scale (GLS) turbulence closure (Umlauf and Burchard, 2003) in SCHISM, the mixing length ($l$) at free surface is<br />
<br />
$l=\kappa d_s$, (Zhang and Baptista, 2008)<br />
<br />
where<br />
<br />
<br />
When wind wave module is not invoked, this parameter scales the surface mixing In the latest SCHISM version (v5.6),</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQs_in_the_v5.6_manual&diff=1179FAQs in the v5.6 manual2018-05-23T20:18:22Z<p>Feiye: </p>
<hr />
<div>Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select <br />
'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency <br />
Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration. <br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." <br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info. <br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those <br />
arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and <br />
the proportionality constants are defined in param.in: <br />
s1_mxnbt = 0.5 <br />
s2_mxnbt = 3.5 95 <br />
(Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy. <br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable. <br />
<br />
5. My run crashed; how can I find out why? <br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. <br />
Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. <br />
Sometimes you want to visualize the problem right before the crash. You cannot use <br />
autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them <br />
FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs. <br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
See Chapter [http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=88 5.1.7]. <br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter [http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=88 5.1.7]. <br />
<br />
8. I have large velocity at open boundary <br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-<br />
specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. <br />
In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section [http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=90 5.4]. <br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQs_in_the_v5.6_manual&diff=1178FAQs in the v5.6 manual2018-05-23T20:16:57Z<p>Feiye: </p>
<hr />
<div>'''5.6 Troubleshooting and FAQ''' <br />
<br />
Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select <br />
'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency <br />
Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration. <br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." <br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info. <br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those <br />
arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and <br />
the proportionality constants are defined in param.in: <br />
s1_mxnbt = 0.5 <br />
s2_mxnbt = 3.5 95 <br />
(Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy. <br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable. <br />
<br />
5. My run crashed; how can I find out why? <br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. <br />
Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. <br />
Sometimes you want to visualize the problem right before the crash. You cannot use <br />
autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them <br />
FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs. <br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
See Chapter [http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=88 5.1.7]. <br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter [http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=88 5.1.7]. <br />
<br />
8. I have large velocity at open boundary <br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-<br />
specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. <br />
In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section [http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=90 5.4]. <br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQs_in_the_v5.6_manual&diff=1177FAQs in the v5.6 manual2018-05-23T20:15:35Z<p>Feiye: </p>
<hr />
<div>'''5.6 Troubleshooting and FAQ''' <br />
<br />
Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select <br />
'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency <br />
Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration. <br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." <br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info. <br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those <br />
arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and <br />
the proportionality constants are defined in param.in: <br />
s1_mxnbt = 0.5 <br />
s2_mxnbt = 3.5 95 <br />
(Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy. <br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable. <br />
<br />
5. My run crashed; how can I find out why? <br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. <br />
Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. <br />
Sometimes you want to visualize the problem right before the crash. You cannot use <br />
autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them <br />
FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs. <br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
See Chapter 5.1.7. <br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter [http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=88 5.1.7 ]. <br />
<br />
8. I have large velocity at open boundary <br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-<br />
specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. <br />
In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4. <br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQs_in_the_v5.6_manual&diff=1176FAQs in the v5.6 manual2018-05-23T20:14:59Z<p>Feiye: </p>
<hr />
<div>'''5.6 Troubleshooting and FAQ''' <br />
<br />
Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select <br />
'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency <br />
Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration. <br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." <br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info. <br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those <br />
arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and <br />
the proportionality constants are defined in param.in: <br />
s1_mxnbt = 0.5 <br />
s2_mxnbt = 3.5 95 <br />
(Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy. <br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable. <br />
<br />
5. My run crashed; how can I find out why? <br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. <br />
Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. <br />
Sometimes you want to visualize the problem right before the crash. You cannot use <br />
autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them <br />
FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs. <br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
See Chapter 5.1.7. <br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter [http://http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=88 5.1.7 ]. <br />
<br />
8. I have large velocity at open boundary <br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-<br />
specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. <br />
In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4. <br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQs_in_the_v5.6_manual&diff=1175FAQs in the v5.6 manual2018-05-23T20:10:55Z<p>Feiye: </p>
<hr />
<div>5.6 Troubleshooting and FAQ <br />
Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select <br />
'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.<br />
<br />
1. My results show platform/compiler/CPU dependency <br />
Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration. <br />
<br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." <br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info. <br />
<br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those <br />
arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and <br />
the proportionality constants are defined in param.in: <br />
s1_mxnbt = 0.5 <br />
s2_mxnbt = 3.5 95 <br />
(Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption but not accuracy. <br />
<br />
4. How to do a tidal simulation with SCHISM? <br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable. <br />
<br />
5. My run crashed; how can I find out why? <br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. <br />
Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. <br />
Sometimes you want to visualize the problem right before the crash. You cannot use <br />
autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them <br />
FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs. <br />
<br />
6. How to impose river discharge if the depth is negative there? <br />
See Chapter 5.1.7. <br />
<br />
7. Run crashes with a dry boundary/depth error. <br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7. <br />
<br />
8. I have large velocity at open boundary <br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-<br />
specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. <br />
In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4. <br />
<br />
9. fort.11 indicates “Could not find suitable element in input” <br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQs_in_the_v5.6_manual&diff=1174FAQs in the v5.6 manual2018-05-23T20:08:34Z<p>Feiye: Created page with "5.6 Troubleshooting and FAQ Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for t..."</p>
<hr />
<div>5.6 Troubleshooting and FAQ <br />
Besides the following info, you may also search archived messages from the SCHISM mailing list on the same web where you registered yourself for the mailing list. Just log in, and select <br />
'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'. <br />
1. My results show platform/compiler/CPU dependency <br />
Due to some intricate differences between different compilers/platforms some minor differences in results are expected. Bit-by-bit match of results using different numbers of CPUs is impossible also. But the differences should be small and should stabilize over time iteration. <br />
2. Run crashed with a fort.11 error message "QUICKSEARCH: no intersecting edge...." <br />
First, you need to viz the results before the crash (e.g. surface velocity) to see if anything is outrageously wrong. If the results look reasonable, contact the developers for more info. <br />
3. Run crashed with a fort.11 error message "bktrk_subs: overflow..." or "MAIN: nbtrk > mxnbt" <br />
The backtracking (ELM) in SCHISM is parallelized across MPI processes, and some arrays need to be allocated to store trajectories that exited the augmented domain. The dimension of those <br />
arrays is defined in mxnbt and mnbt, which are proportional to local # of side and # of levels, and <br />
the proportionality constants are defined in param.in: <br />
s1_mxnbt = 0.5 <br />
s2_mxnbt = 3.5 95 <br />
<br />
<br />
(Gradually) increasing these (to say 1, and 4) will solve the problem. Note that these constants only affect memory consumption and not accuracy. <br />
4. How to do a tidal simulation with SCHISM? <br />
The simplest way is to use SCHISM 2D. If you have to use SCHISM 3D, make sure the vertical grid is reasonable. <br />
5. My run crashed; how can I find out why? <br />
The best way to find out the reason for a crash is to visualize the surface velocity with VisIT. <br />
Usually, you may see some large/noisy velocity somewhere, which may give you some hints on grid or forcing issues etc. <br />
Sometimes you want to visualize the problem right before the crash. You cannot use <br />
autocombine_MPI_elfe.pl as the last stack of output is incomplete. But you can use them <br />
FORTRAN combine script (e.g., combine_output*) to directly combine an incomplete stack. Just follow the instruction in the header of this script to prepare the inputs and run. Then visualize the combined outputs. <br />
6. How to impose river discharge if the depth is negative there? <br />
See Chapter 5.1.7. <br />
7. Run crashes with a dry boundary/depth error. <br />
SCHISM does not allow any open-boundary nodes to become dry at any time; see Chapter 5.1.7. <br />
8. I have large velocity at open boundary <br />
In hydrostatic models, the incoming velocity should be specified at open boundary. Over-<br />
specification i.e. elevation+velocity B.C. there usually avoids the problem, but the two B.C. ’s must be largely consistent with each other. <br />
In reality it's often difficult to find velocity B.C., and so a useful way is to use one-way nesting approach described in Section 5.4. <br />
9. fort.11 indicates “Could not find suitable element in input” <br />
This is likely because your sflux*.nc is not prepared properly: either the grid in .nc does not cover hgrid.ll, or the structured grid in .nc is not ordered counter-clockwise.</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1173FAQ2018-05-23T20:06:28Z<p>Feiye: </p>
<hr />
<div>'''[[FAQs in the v5.6 manual]]'''<br />
<br />
'''[[xlsc (surface mixing length scale constant)]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1172FAQ2018-05-23T19:59:20Z<p>Feiye: </p>
<hr />
<div>'''[[xlsc (surface mixing length scale constant)]]'''</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1171FAQ2018-05-23T19:57:58Z<p>Feiye: </p>
<hr />
<div>[['''xlsc (surface mixing length scale constant)''']]</div>Feiyehttp://ccrm.vims.edu/w/index.php?title=FAQ&diff=1170FAQ2018-05-23T19:57:03Z<p>Feiye: Created page with "xlsc (surface mixing length scale constant)"</p>
<hr />
<div>xlsc (surface mixing length scale constant)</div>Feiye