Hello,
I am trying to build a Mathcad sheet to find pile capacity. The maximum number of soil layers available is nine (9). The user can choose to use all or, some of the layers within this 9. I am trying to build a logic to assign unit weight based on the layers I have subdivided to. The issue is if all layers are not being inputted, then the logic for unit weight says "Array Index invalid". Please help on this issue, my version is Prime 10.
Thanks
ACCEPTED SOLUTION
Accepted Solutions
Hi,
I suggest an input table like this:-
Saves the steps turning input into vectors as the table creates them.
Rows for less or more layers in a problem can be easily adjusted and sheet corresponds to these changes using last()
Assigning depths of the layers is trivial
As is finding the layer the pile stops in
Cheers
Terry
Hi,
Now for the second part getting the value of Gamma.
Setting the water table in the depth of the pile for demonstration.
Gets the following Gamma
Cheers
Terry
Thank you so much, @terryhendicott and @ttokoro for your time and help. I have a question for @terryhendicott . I see you have used the condition as find all indexes using "greater or equal" comparison. I tried with the "eq" comparison but it says "no mathcing values wer forund, even though there was. Can you please expalin why it did this.
Thanks
Hi,
"I see you have used the condition as find all indexes using "greater or equal" comparison. I tried with the "eq" comparison but it says "no matching values were found, even though there was. Can you please explain why it did this."
Cheers
Terry
.I tried with the "eq" comparison but it says "no mathcing values wer forund, even though there was.
That's not true!!
You loop through H.end.pile and are trying to find a match (equal) for every value in H.end.pile in the vector H.
But there are MANY values in H.end.pile which don't have an exact match in vector H, for instance the very first value 1 ft does not occur in vector H and so you will get an error.
There is also another reason why using "eq" (which seems to be the same as omitting the last argument in "match" altogether) may be dangerous. When dealing with float values its never a good idea to ask for exact equality as due to round off errors (which also can occur just by storing the number in memory) there might be tiny differences and Prime would consider the two values as unequal.
While the values in your vectors are integers (in feet), they are stored in SI unit meter and so floating point is used.
Look at the two values of 10 feet in both vectors (index 9 in Hendpile and index 0 in H). We would consider them equal, but Prime says they are not:
Reason is a tiny difference of about 10-15 ft which otherwise sure goes unnoticed
The good news are that the "match" and the "lookup" functions are very "generous" when it comes to evaluating equality (they use the system variable TOL).
In your case matches would be found despite the tiny difference
However, as can be seen from some older threads, this ‘generosity’ was also a source of annoyance when it came to comparing values in ‘small units’ (such as µm or mH) and values were considered equal even though they were not.
For example
All five values are incorrectly considered to be equal to 10.2 mH.
The questioners were often confused because it worked without complaint without units:
The reason was that the generous tolerance is not applied to the values in mH, but to the values in the base unit Henry.
And so even the difference of 10.2 mH to the value 11 mH with 8*10-4 H is still within the tolerance TOL (default value 10-3).
Cure for this problem is either decreasing the value of the system variable TOL (may have undesired effect elsewhere) or use dimensionless unit by dividing by mH
