SSP Vector symbols for slice-indexed values #1222
Conversation
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| ${C_{den}}$ & Proportionality Constant Denominator: expression used to calculate the denominator of the interslice normal to shear force proportionality constant & N | ||
| ${\mathbf{C}_{den}}$ & Proportionality Constant Denominator: expression used to calculate the denominator of the interslice normal to shear force proportionality constant & N |
There was a problem hiding this comment.
As for the previous comment, should we make denominators plural, since it is a sequence of denominators?
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| ${C_{num}}$ & Proportionality Constant Numerator: expression used to calculate the numerator of the interslice normal to shear force proportionality constant & N | ||
| ${\mathbf{C}_{num}}$ & Proportionality Constant Numerator: expression used to calculate the numerator of the interslice normal to shear force proportionality constant & N |
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| @@ -83,89 +81,91 @@ \subsection{Table of Symbols} | |||
| \\ | |||
| ${{F_{S}}^{min}}$ & Minimum Factor of Safety: The minimum factor of safety associated with the critical slip surface & -- | |||
| \\ | |||
| ${{F_{x}}^{G}}$ & Sum of the Interslice Normal Forces: for two adjacent interslice boundaries & N | |||
| ${{\mathbf{F}_{x}}^{G}}$ & Sum of the Interslice Normal Forces: for two adjacent interslice boundaries & N | |||
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| ${{F_{x}}^{H}}$ & Sum of the Interslice Normal Water Forces: for two adjacent interslice boundaries & N | ||
| ${{\mathbf{F}_{x}}^{H}}$ & Sum of the Interslice Normal Water Forces: for two adjacent interslice boundaries & N |
| \\ | ||
| $\mathbf{F}$ & Force: An interaction that tends to produce change in the motion of an object & N | ||
| \\ | ||
| $G$ & Interslice Normal Force: per meter in the z-direction exerted between adjacent slices & $\frac{\text{N}}{\text{m}}$ | ||
| $\mathbf{f}$ & Interslice Normal to Shear Force Ratio Variation Function: function of distance in the x-direction & -- |
There was a problem hiding this comment.
I believe this one is actually a force vector, so we don't need to make anything plural.
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| $H$ & Interslice Normal Water Force: per meter in the z-direction exerted in the x-ordinate direction between adjacent slices & $\frac{\text{N}}{\text{m}}$ | ||
| $\mathbf{H}$ & Interslice Normal Water Force: per meter in the z-direction exerted in the x-ordinate direction between adjacent slices & $\frac{\text{N}}{\text{m}}$ |
There was a problem hiding this comment.
It is unrelated to the current review, but I think this should be x-coordinate. ordinate is the name of a coordinate, usually in the y direction. I don't think x-ordinate is standard terminology.
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| $h$ & Y-Direction Height of a Slice: height in the y-direction from the base of a slice to the slope surface, at the x-direction midpoint of the slice & m | ||
| $\mathbf{h}$ & Y-Direction Height of a Slice: height in the y-direction from the base of a slice to the slope surface, at the x-direction midpoint of the slice & m |
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| ${h^{L}}$ & Height of the Left Side of a Slice: assuming slice surface has negative slope & m | ||
| ${\mathbf{h}^{L}}$ & Height of the Left Side of a Slice: assuming slice surface has negative slope & m |
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| ${h^{R}}$ & Height of the Right Side of a Slice: assuming slice surface has negative slope & m | ||
| ${\mathbf{h}^{R}}$ & Height of the Right Side of a Slice: assuming slice surface has negative slope & m |
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| ${h_{z}}$ & Height of Center of Slice: the height in the y-direction from the base of a slice to the center of the slice & m | ||
| ${\mathbf{h}_{z}}$ & Height of Center of Slice: the height in the y-direction from the base of a slice to the center of the slice & m |
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| ${h_{z,w}}$ & Height Halfway to Water Table: the height in the y-direction from the base of a slice halfway to the water table & m | ||
| ${\mathbf{h}_{z,w}}$ & Height Halfway to Water Table: the height in the y-direction from the base of a slice halfway to the water table & m |
There was a problem hiding this comment.
... the heights in the y-direction ... ?
code/stable/ssp/SRS/SSP_SRS.tex
Outdated
| \\ | ||
| $P$ & Resistive Shear Force: Mohr Coulomb frictional force per meter in the z-direction that describes the limit of mobilized shear force a slice can withstand before failure & $\frac{\text{N}}{\text{m}}$ | ||
| $\mathbf{P}$ & Resistive Shear Force: Mohr Coulomb frictional force per meter in the z-direction that describes the limit of mobilized shear force a slice can withstand before failure & $\frac{\text{N}}{\text{m}}$ |
There was a problem hiding this comment.
Are these forces actually used as vector quantities or are they scalar components of a vector, or the vector's magnitude? I don't have time to check the equations, but I don't think we are using P as a vector, or we would have an equation where we are dividing one vector by another to calculate the factor of safety. Please check each use of force to make sure that it really is the force vector that we are intending to represent.
There was a problem hiding this comment.
I made these vectors for the same reasons that I made the coordinates vectors. The vector does not represent the scalar components, it instead holds the magnitude of the force at each slice. You're right that this "breaks" the equation for factor of safety, because we divide vectors. However, everywhere else P is used it is actually used as a vector (indexed at slice i). Perhaps this warrants creating a separate unital for P and S as scalars, to use in the factor of safety equation, and then using these vector unitals for all of the other equations?
There was a problem hiding this comment.
@bmaclach, I reviewed too quickly. Good to know that the vector is a sequence of scalar forces, with one for each slice.
Being more careful with our "types" is definitely helpful. It is highlighting inconsistencies. In the theoretical model, P is a single resistive shear for the entire slope, but later on, \bf{P} is the sequence of resistive shears for each slice. P_i means something else - the resistive shear of slice i, or the ith component of \bf{P}.
I don't really want the theoretical model to introduce the idea of slices, since the theoretical model is abstract. There are other ways to solve slope stability problems that do not involve slices. We want the same theoretical model to work in other problems.
We could make a distinction between P, \bf{P} and P_i. In the table of symbols we would then have a definition for P and a definition for \bf{P}. This allows for a unique symbol for each unique concept. Could we do this in Drasil? Is the typescript part of the symbol? Actually, it would be better if the typescript is a rendering artifact. What we really want to do is distinguish between something that is a vector, a component of a vector, and not a vector.
Alternatively, we could use a different symbol for P in the theoretical model. This would let us have the resistive shear of a slope versus the resistive shear of a slice, or a sequence of slices.
I'm not sure of the best approach, but I do know that defining the factor of safety as \bf{P} / \bf{S} is wrong. The division of two vectors doesn't make sense.
There was a problem hiding this comment.
The typescript is how we render vectors (I think by typescript you are referring to the \bf{}, correct me if I'm wrong). So yes, we could do what you suggest in Drasil by creating a second Unital which is not a vector. P_i does not exist as a Unital, it just arises when we index P by i in an Expr.
By the way, the way I did this, P_i renders as \bf{P}_i. Is that wrong? Should the P not be rendered as a vector when we index it? I thought it was okay because I read that as "the i th element of the P vector" but I want to be sure that notation isn't wrong.
There was a problem hiding this comment.
Yes, by typescript I'm referring to \bf{}. Using {\bf asdfasdf} will put the text in bold font. I suppose I abused the notation a bit, but I didn't want to have to keep typing \textbf{}. 😄
I agree that P_i should not be unital. As you said, it arises when we index \bf{P}. (You said P, but I think you mean the symbol for the vector.)
It is fairly common notation to represent the ith component of \bf{P} as P_i, but you also see \bf{P}_i. As long as we are consistent, I don't see much of a problem. However, if it is an arbitrary decision on your part, it would be better if we didn't keep the typescript for vectors when we are indexing an individual element. The common notation is shown on the following web-page:
https://en.wikipedia.org/wiki/Index_notation
You can see that the bold face is dropped when referencing a single element.
No matter what notation we use, your interpretation as the "ith element of the vector \bf{P}" is correct.
There was a problem hiding this comment.
You're right, I meant the vector symbol P.
It wasn't an arbitrary decision to use the notation I did, unfortunately. If we wanted the indexed version of the vector P to render without the typescript, we would need P itself to not be a vector. As far as I know, there's no way to tell Drasil to un-vectorize a vector when we index it. Probably this is something we would want to teach Drasil to do? I can create an issue for that, if that sounds good?
There was a problem hiding this comment.
Yes, leave things the way you have done it, and create an issue for rendering the symbol for components of a vector without the vector typeface. What we really want is for decisions like this to be parameterized. It is a display decision, not a scientific decision. The way you have done it is a notation that you see, it just isn't the most common. Ideally a user could customize the recipes in Drasil to render using their typographic conventions.
There was a problem hiding this comment.
@bmaclach, can you please review each of your introductions of the bold-face vector notation. We need to be careful. The descriptions should be different when we are describing the entire sequence versus when we are describing a single element. If we had types, the types are different. I've made some suggestions to pluralize some words, to show that we are talking about the collection of these quantities, not just one.
We also need to be careful because I don't think every force is actually a vector. In some cases we are using a scalar representation of the force. That is, we know the force magnitude, but we don't care about its direction.
… use in factor of safety equation
|
@smiths The latest couple commits fixed the following issues you pointed out:
|
|
So @smiths needs to review that the asked-for changes are indeed made. And master will need to be re-merged too. |
|
The changes look good to me. |
|
Merged master. |
|
I added one last tiny commit because I noticed an issue where we were adding 's' to a word that was already plural (since we've now pluralized the words by default) |
Motivated by discussion in #1083, a lot of the quantities in SSP are really sequences of values, each applying to a single slice. This PR updates all such quantities to be vectors.