ACCEPTED SOLUTION
Accepted Solutions
The main reason you are getting the error is because Prime does not allow to vectorize a comparison operator directly. A workaround is to define a function beforehand which does the comparison and call that function vectorized.
So the vector mp is now calculated as you expected it and could be used afterwards. But the use of a Prime table for doing so is not needed (and does not make much sense IMHO) anyway.
As Fred already wrote a Prime table can only be used to input data vectors manually but is in no way helpful if your goal is to display data.
Prime does not offer a decent way to display data in a nice and clear way. You may create a table by augmenting the data vectors
Or you can get rid of the units in the table and add an (ugly looking) header
Two quick observations:
1) Mathcad is not EXCEL. Tables in Prime are only data entry vehicles. If you copy a range of numbers from an EXCEL spreadsheet and simply paste them into Mathcad, (cntrl-P) you'll create a table--the numbers will appear with two blank place holders at the top of each column. The top placeholder is for a variable name, the one below is for a unit if one is needed. These are now vector variables in Mathcad.
2) Unlike EXCEL you can't put formulas into a table. They are for input only.
But, once you have the variables you can write functions to operate on them or simply define new variables from combinations.
One more observation: there are two types of subscript--literal and index. A literal subscript (ctrl-0) is part of the variable (All of your subscripts appear to be literal.) An index subscript ([) points to one element of a vector variable.
Index subscripts must be integer numbers, but they can be computed numbers.
Proper use of Mathcad can make this much easier to understand.
The main reason you are getting the error is because Prime does not allow to vectorize a comparison operator directly. A workaround is to define a function beforehand which does the comparison and call that function vectorized.
So the vector mp is now calculated as you expected it and could be used afterwards. But the use of a Prime table for doing so is not needed (and does not make much sense IMHO) anyway.
As Fred already wrote a Prime table can only be used to input data vectors manually but is in no way helpful if your goal is to display data.
Prime does not offer a decent way to display data in a nice and clear way. You may create a table by augmenting the data vectors
Or you can get rid of the units in the table and add an (ugly looking) header
Some additional remarks:
The only reason for using the table is the vector T.s.
You could create it much simpler by using
and can then create other vectors depending on it without using a table:
The vectors c, k.c, c'k.c, k.q and rho0 could be created more comfortable of you define the appropriate values as vector elements right from the beginning.
E.g. Instead of defining c.u0:=.... in your collapsed region you could write c[0:=..... where "[" denotes making a matrix index.
That way you can omit the whole table and may create a (less nice looking) table as shown to display the results.
I am not yet sure how your calculation of mp depends on df exactly, but I found a lot of things you could streamline and simplify if you use vectors rigth from the start and not a myriad of variables with a literal index.
For example the 35 values "z.b" can be done in one go like this
Then all 35 values for phi could be calculated as vector like this:
I renamed the four element vector phi you created in the table to phi.table to be able to use the name phi for the 35 element vector created.
Then k.c, etc. etc.
Again note the the subscript "c" of "k" is a literal index (part of the name, nothing you can calculate with) while "idx" is a matrix/vector index.
Thanks Werner
So the value of df effects mp because its essentially an initial guess to where the fixity lies at depth df.
so changing df gets mp closer or further way from mp. the closer to zero the better.
You can see below at the point where the value starts to become a minus kNm answer.
the sum of these answers is dependent on df and changing that will get me closer to zero etc
Still see no iteration, still confused by your many singly created variables. Or are those 35 values just there to find the most appropriate of them? But then most don't depend on d.f ??
BTW, the calculation of rho
Wouldn't
simplify to just
? So We could then, using vector indexed variables, do
Furthermore I wonder if z.b really is meant to be dimensionless. After all all you add the unit meter at all of your subsequent calculations. It would be more convenient if you add that unit right from start. maybe "b" should be dimensionless??
Addition:
Here is a way to define m.p without using a comparison (and so without the need of an auxiliary function) using the "sign" function.
Only difference to your original function is when A.z is zero. This new function now returns 0 in that case.
And if your goal is to find the value of d.f where the sum of m.p yields zero, you have to turn the calculation of those sum into a function of d.f and then either use a solve block or the root function like this:
See if the attached file is of help.
