FAQs in the v5.6 manual - Revision history

Feiye at 20:18, 23 May 2018

2018-05-23T20:18:22Z

Feiye at 20:16, 23 May 2018

2018-05-23T20:16:57Z

Feiye at 20:15, 23 May 2018

2018-05-23T20:15:35Z

Feiye at 20:14, 23 May 2018

2018-05-23T20:14:59Z

Feiye at 20:10, 23 May 2018

2018-05-23T20:10:55Z

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..."

2018-05-23T20:08:34Z

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..."

New page

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 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'.
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.
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.
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 and not accuracy.
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.
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.
6. How to impose river discharge if the depth is negative there?
See Chapter 5.1.7.
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.
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.
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.

← Older revision		Revision as of 20:18, 23 May 2018
Line 1:		Line 1:
−	~~'''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 the mailing list. Just log in, and select		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'.		'Archive' from the left of the screen, and then on right side of screen select 'Advanced search'.

@@ Line 32: / Line 32: @@
 .  Run crashes with a dry boundary/depth error.
-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 ].
+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 ].
 .  I have large velocity at open boundary

@@ Line 29: / Line 29: @@
 .  How to impose river discharge if the depth is negative there?
-See Chapter 5.1.7.
+See Chapter [http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=88 5.1.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 [http://ccrm.vims.edu/schismweb/SCHISM_v5.6-Manual.pdf#page=88 5.1.7 ].
+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].
 .  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.
+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].
 .  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.

@@ Line 1: / Line 1: @@
-.6 Troubleshooting and FAQ
+'''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 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'.
@@ Line 31: / Line 32: @@
 .  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.
+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 ].
 .  I have large velocity at open boundary

@@ Line 1: / Line 1: @@
 .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 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'.
 .  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.
 .  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.
 .  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
@@ Line 11: / Line 14: @@
 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.
-−
 .  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.
 .  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.
@@ Line 23: / Line 26: @@
 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.
 .  How to impose river discharge if the depth is negative there?
 See Chapter 5.1.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.
 .  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.
 .  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.